datagrid dds产品灾备平台介绍

DataGrid DDS产品灾备平台1. 引言在企业信息化进程不断加快的今天，保持业务的持续性是企业用户进行数据存储时必须考虑的重要方面。灾难的出现， 可能导致生产停顿、客户满意度降低，企业的竞争力会因此大打折扣。震惊世界的“9.11” 事件发生后，全世界都看到了金融、电信等行业用户在灾难中的巨大损失。这样，在灾难后如何快速、正确地恢复业务系统就成为摆在企业面前的一个难题。证券行业是国民经济的重要环节，同样面临着如何应对灾难，以求防患于未然。今天，中国的证券行业正在面临业务模式的重大变革，在业务日新月异的今天，证券的交易模式也从分散向集中过渡，同时，券商之间的不断兼并和激烈的竞争，也使得信息技术部门格外看重集中交易系统的数据保护。试想一下，如果哪个券商的集中交易系统遭遇灾难而不能恢复的话，那么整个公司将不得不面临被兼并或倒闭的命运。因此，集中交易系统的安全性和抗灾难能力直接关系到券商和股民的切身利益、企业形象。所以尽可能地保证系统的安全是必须重点考虑的。一个先进的、完善的灾备系统将全力的保护集中交易系统的稳定运行，让券商在业务飞速发展的同时没有后顾之忧。现在，我们很欣喜的看到，很多优秀的证券企业在整合业务的同时就考虑了灾备平台的建设，在思路和行动上都领先于同行业的竞争对手。与此同时，随着业务的不断深入以及市场竞争的需要，数据应用成为另一个业内的热点，如何高效的利用交易数据，快速的查询、分析数据成为各公司CTO关注的问题。本文根据集中交易系统的现状和灾备方面的规划需要，着重考虑合理地设计和建设一体化数据复制容备保护系统，同时优化数据中心的应用结构，以DataGrid DDS产品灾备平台为核心构建企业的第二数据中心和查询应用平台。形成技术方案建议书，供证券公司各级领导及技术人员参考。2. DataGrid DDS产品介绍2.1. 概述:DataGrid DDS是基于分析oracle redo log技术的Oracle实时复制工具，具有简单灵活、高性能低成本的特点，部署和使用非常容易，对系统资源和运行环境的要求也非常低。DataGrid DDS能够帮助用户在复杂的应用环境下完成容灾备份、异构迁移、业务数据分发、基础数据整合集中等工作。l DataGrid DDS能做什么？DataGrid DDS能够满足用户多种业务需求，主要有：提高系统整体可用性DataGrid DDS能够帮助用户提高Oracle数据库的可用性，无论是执行计划内停机（如系统升级、备份）还是遇到故障引起的非计划宕机（例如硬件故障、灾难、人为错误等），DataGrid DDS都能尽量减少宕机时间。提高可用性能够最大限度地减少数据丢失、经济损失和生产力的降低。逻辑灾备和灾难恢复对于大部分公司而言，灾备是一项巨大的工程，意味着高额的资金投入和人力成本。受到传统复制技术的限制，灾备必须拥有专用的硬件支持和专用的光纤传输链路，灾备距离和系统平台还有诸多的限制。此外，由于传统灾备系统的数据库不能随时打开使用，不但风险不能评估，而且巨大的投入也得不到回报。 DataGrid DDS使用逻辑数据复制技术，传递的是交易信息，因此传输数据量很小，保证了在低带宽环境下实现低延迟的Oracle数据异步复制，软件同时支持实时复制容灾和定时复制备份功能，是一种高效且低成本的数据库灾备方式。DataGrid DDS使用标准的IP网络进行通讯，灾备端的Oracle数据库可以部署在本地或远程容灾中心，距离没有限制。此外，由于复制的目的端数据库始终处于打开状态，因此，当生产数据库遇到计划内或非计划停机时，DataGrid DDS能够支持前端应用程序快速、无缝的切换到灾备数据库。与其它基于磁盘或文件系统的物理复制技术相比，不但省略了漫长的数据库recovery和启动时间，而且能够保证100%的切换成功率。分担数据库负载DataGrid DDS逻辑交易复制技术保证了目的端数据库始终处于可用状态，因此对于实时交易处理之外的只读应用，例如批量查询、报表处理、数据备份、统计分析等都可以交给复制的数据库处理。多种应用也不必在同一个交易数据库上争夺资源和时间窗口。生产系统运行和维护的压力得以释放，提高了稳定性，而不同的应用在分布的数据库上也可以得到分别的优化。业务数据分发DataGrid DDS能够完成企业范围内数据分发，从交易数据生产库实时复制到一个或多个本地或异地的数据库。DataGrid DDS支持多种数据分发拓扑结构，一对多，多对一，级联复制等。数据分发是一种典型的通过部署多服务器、多数据库来分担负载，提高响应速度的企业应用模式。跨平台数据迁移DataGrid DDS支持跨平台的数据传输，复制的源和目的系统可以在AIX、HP-UX、Solaris、Linux之间任意选择。DataGrid DDS同时支持Oracle 9i和Oracle 10g。对于用户来说，不但硬件平台的选择有很大的灵活性，也可以用DataGrid DDS来完成异构平台的数据库同步和迁移工作。实时复制和批量复制应用的需求影响着用户使用复制工具的模式，对于容灾和查询应用，连续的实时复制保证目的端数据库拥有和生产系统完全一样的数据状态；而对于定时备份、系统升级和定时分析等应用，用户则希望复制软件做到定时或周期性的批量数据迁移。在DataGrid DDS中批量复制和实时复制是相互独立又紧密结合的两个部分，通过管理员的操作控制，DataGrid DDS完全满足用户在多种应用条件下的需求。交易统计DataGrid DDS在完成实时数据复制的同时，也跟踪到了数据库交易数量的变化，通过GUI界面，DBA可以随时查询到生产数据库在指定时间段的交易统计结果，通过分析这些数据，DBA能够量化生产数据库压力的变化，从而为数据库的扩容和升级提供了依据。增强分析工具DataGrid DDS提供了简单实用的数据库工具包，包括日志分析工具、文件分析工具、导入导出工具等，工具包能帮助有经验的DBA更深入的分析处理数据库的问题。2.2. DataGrid DDS技术原理2.2.1. DataGrid DDS和Oracle Redo Logs l 基于日志分析的实时复制技术DataGrid DDS通过分析Oracle redo log获得实时交易信息，完成schema或table级别的数据复制。区别于早期的日志分析技术，DataGrid DDS对日志的整合和传输以交易为单位，使用该技术，在拥有高性能的同时还能更好的保证数据传输的一致性和完整性。对生产数据库也不会增加负载。DataGrid DDS从Oracle redo logs里面获取所有的数据库改变信息。通过对信息的分析整合，DataGrid DDS将完整的交易信息复制到目的端。DataGrid DDS不是等待Oracle redo log文件写满之后再处理，而是随时读取其数据块内容，间隔时间可以用参数指定，一般是秒级。DataGrid DDS也不会复制Oracle redo log的全部内容到目的端数据库，除指定复制对象（数据表）相关的DML/DDL操作之外，其他的信息将丢弃处理。为了避免可能出现的复制错误，用户需要打开数据库的supplemental logging 和force logging参数以便DataGrid DDS能获取完整的数据信息。 置于裸设备或文件系统（包括ocfs）中的Oracle redo log可以被DataGrid DDS正常读取。如果用户使用的是Oracle 10g，并且将redo log保存在ASM（一种新的Oracle存储格式）中，则需要在裸设备或文件系统上手动创建一组与原有日志同步的redo log member，供DataGrid DDS复制使用。l Online 和 Archived Redo LogsOracle有两种类型的日志：在线日志和归档日志。一般情况下，DataGrid DDS从一组在线日志读取信息，因此，不要求Oracle数据库必须打开归档日志。但在某些特殊情况下，online redo log没来得及分析就被覆盖，此时，如果Oracle是归档模式，则DataGrid DDS将从归档日志读取需要的信息。2.2.2. 复制对象和数据定位l 复制对象的指定DataGrid DDS支持两种级别的复制：1.用户（schema）级复制；2.表级复制。用户级复制表示源端数据库指定用户（schema）下的所有表、视图、索引、过程、函数、包、序列等数据对象全部复制到目标端数据库指定的用户下。表级复制表示源端数据库指定用户（schema）下的单个表复制到目标端数据库指定用户下的单个表。在使用DataGrid DDS时，用户通过编辑配置文件指定源端和目的端复制对象的映射关系，包括源端对象名，目的端对象名，目的主机编号等。源端和目的端对象名称可以不同，但结构必须一致。软件运行过程中，复制对象的映射参数会驻留内存，DataGrid DDS通过日志分析过滤，只处理指定复制对象有关的交易，其它用户或表的操作信息则被丢弃。l Rowid mapping早期的数据库逻辑复制软件要求被复制的数据表有主键索引，通过where子句查询的方式来定位DML操作的目标行。这种方法在数据修改较多或者表内行数较多的应用环境，特别是Update操作频繁的情况下，效率较低。为了满足海量数据系统的应用要求，DataGrid DDS以Oracle内部rowid为参照进行复制数据定位。系统在初始化过程中会自动创建源端数据行和目的端数据行的rowid mapping映射表，为二进制格式，系统根据该映射关系找到DML操作的目标行。Rowid定位技术在海量数据环境下处理Update和Delete操作具有较大的性能优势。2.2.3. 分级存储和交易队列DataGrid DDS在数据传输部分使用了分级存储机制，在遇到系统错误引起的复制中断时，例如硬件故障、数据库故障、网络中断或延迟，分级存储机制能完好的保存已经合成的交易信息，避免数据丢失。这些数据以二进制文件格式存储在文件系统的缓存目录下，直到系统故障解决。恢复从缓存文件传输的中断点开始。l 源端和目的端分级存储DataGrid DDS的分级存储分为两级：第一级在复制源端，第二级在复制的目的端。Redo log里边的交易的信息被整合成缓存文件后，首先存放到源端的一级缓存目录；然后经过网络通讯进程处理被发送到目的端系统下的二级缓存目录保存；最后由装载进程负责装载到目的端数据库中。在网络传输出现中断或大量延迟的情况下，DataGrid DDS在源端仍然继续读取并分析数据库日志产生的交易信息，这些信息暂时不能发送到目标端系统，不断地积累在源端的缓存目录下，直到通讯恢复。源端缓存保证了故障情况下复制数据的完整性。目的端的缓存目录将保存交易信息文件直到它们正确的装载到目的端的数据库内，如果因为目的数据库的故障或关闭，装载不能进行，从源端传送过来的数据文件将在目的端缓存目录下保存。数据库恢复后，缓存文件会严格按照交易时间顺序进行装载。l 文件的格式和大小交易信息以文件为单位进行传输、缓存和装载，该文件为DataGrid独有的二进制格式，其内部的表达方式与Oracle内部处理方式相类似，避免了很多复杂的信息转换，因此具有很高的效率。缓存文件的总量为源端实际产生redo log日志量的1/31/4左右。DataGrid DDS不设置缓存空间控制机制，用户可以根据每天交易产生的Oracle redo log日志量和以上比例计算需要预留的缓存空间。l 内存管理和大交易处理DataGrid DDS启动后，将在源端和目的端系统上开辟多个内存区供各进程使用，用来驻留参数、传递消息信号、缓存分析交易的中间信息等。内存区的大小由系统参数指定，目的是防止无限制的使用内存引起系统资源紧张或系统崩溃。在复制源端，如果遇到数据库产生非常大的交易，DataGrid DDS会连续分析直到整个交易提交，其间产生的中间信息可能达到GB级。在这种情况下，DataGrid DDS会自动将这些信息缓存在磁盘上等待处理，磁盘缓存由后台进程自动处理，容量没有限制。l 交易队列DataGrid DDS严格按照Oracle数据库内部SCN顺序执行交易的复制和装载，保证复制数据的绝对一致性。DataGrid DDS在跟踪redo log过程中，每隔一个固定的时间（通常是秒级）读取一次日志文件，分析出本次读出数据的内容，同时记录下该段数据的起始和终止SCN号。下一次读取redo log时，从上一次获取的终止SCN位置开始。多个实例的RAC模式下，则以SCN为参考给每个实例执行的交易进行排队，然后按照排队顺序形成缓存文件。缓存文件也严格按照交易的顺序进行编号、传递。所有的交易在目的端装载的顺序与它们在源端产生的顺序完全相同，这是保证数据完整性和一致性的关键。2.2.4. 使用和部署DataGrid DDSl 在线部署DataGrid DDS的安装非常简单，不需要特殊的软硬件支持，软件本身完全在Oracle数据库的外部，不需要在Oracle中增加表空间，不需要在复制的表上添加索引和主键，也不需要停机做基础数据同步工作。整个安装过程可以在线进行，甚至可以在数据库正常执行交易的过程中执行，因为DataGrid DDS不用借助任何第三方工具就可以进行在线的批量数据初始化工作，初始化结束后，无缝切换到增量数据复制过程。这样的功能对于一些需要7*24连续运行的系统来说非常重要，因为在安装维护过程中，频繁的停机会给生产系统带来很大的安全隐患和工作难度。l 跨平台支持和兼容性使用逻辑复制技术的DataGrid DDS，其跨平台能力是用户非常欢迎的。DataGrid DDS能够支持不同版本Unix/Linux系统下的混合复制，对于具有复杂硬件环境的企业系统来说，异构能力可以节省大量的资源和成本，旧设备得到充分的利用。不同Oracle版本的支持能力也非常有价值，对于一些7*24运行的Oracle9i数据库来说，DataGrid DDS可以帮助它们在线的升级到Oracle 10g。操作系统数据库版本数据类型数据对象AIXOracle9iNUMBER TableHPUXOracle9i RACCHARViewHPUX（IA64）Oracle10gVARCHAR/VARCHAR2PackageSolarisOracle10g RACDATEPackage bodyLinuxTIMESTAMPIndexBLOB/CLOBSequenceRAW/LONG RAWProcedureROWIDFunctionTrigger表1：DataGrid DDS支持的系统及对象l 多种复制模式DataGrid DDS支持一对一，一对多，多对一，以及级联复制等多种复制模式。无论在哪种模式下，复制的源和目的系统都是独立的部分，可以单独的使用、维护和优化，这也是逻辑复制技术受到用户青睐的重要原因之一。一对一的复制常见于灾备应用。1. DataGrid DDS数据复制系统建设方案1.1. 需求分析我国证券企业的数据保护系统建设目前还处在起步阶段，大多只拥有简单的备份手段，而且目前的备份手段多是基于应用开发，对业务交易系统影响较大，只能提供数据库表级别的备份和恢复，在手段上比较单一。因此，目前的证券企业对交易系统的数据保护需求是非常迫切的，尤其是在普遍采用集中交易模式之后，数据丢失的风险和可能带来的经济损失进一步的增加。而最重要的交易数据就存在于后台系统。对核心数据库和系统的数据保护将成为整个灾备系统建设需求的重点。1.2. DataGrid DDS 数据复制方案在此，我们提出灾备统一的数据复制保护方案。推荐使用具有国际领先技术的DataGrid DDS数据库远程灾备产品，能够支持跨平台远程的Oracle数据实时复制。能够预防自然灾害、系统宕机等物理故障，快速实施系统切换。满足当前和未来证券公司对灾备的需要。1.2.1. 软件部署DataGrid DDS同时支持实时复制和定时复制两种工作模式，实时复制一般用于容灾，定时复制一般用于备份。一般情况下，本地建立一套定时复制系统，远程建立一套实时容灾系统，采用一对多的复制拓扑结构，由两个系统完成统一的灾备部署。如果有多套Oracle生产数据库，例如基金公司主要有4个系统，则可以使用多对一的复制模式，用一个灾备库存储所有生产系统的数据，进行集中灾备。每个应用系统的数据与灾备库的数据以schema为单位一一对应。1.2.2. 拓扑结构1.2.3. 软件安装配置DataGrid DDS复制软件分为Source和Target两个部分，Source模块安装在复制的源端；Target模块安装在复制的目标端。源端和目标端互相对应。为了实现数据复制，首先需要安装和配置DataGrid DDS软件：软件安装包括数据源端和复制目标端的软件安装，二者在安装时都不会对系统的运行产生影响，从而无需业务中断。同时，DataGrid DDS的参数配置也非常简单，只需要配置所有参加复制的服务器IP地址和port号，以及参加复制的database的参数等。复制关系的映射有两种方式：1、以表为单位；2、以用户为单位。对于那些数据库中拥有大量数据表(table)的系统，采用DataGrid DDS 以“USER”为复制单位的配置复制关系比较简单。1.2.4. 初始化复制环境、进行初始数据同步复制环境的建立，首先需要将生产系统中的已有数据初始化同步到目标系统上，同时记录各种系统状态和映射关系等。因此如何快速、有效的建立复制的初始化环境是每个复制系统都非常关心的问题。在传统办法中，数据首次同步过程大都采用Oracle的EXP/IMP工具，将源端数据库数据抽取出来，通过网络传输至目标端数据库进行加载。或者是借助第三方的备份软件工具，将源端的数据进行备份，再通过磁带运输至目的地，将磁带数据恢复到目标数据库，从而达到首次数据同步的目的。这种方式存在大量的问题：1. 性能低下：通过Export/Import方式，最大的问题在于性能很慢，对于一个几十GB的数据库，进行一次export/import，则大约费时810小时以上。2. 完全需要手工干预：数据的导出（Export），传输和装载（Import）等过程都需要手工干预和执行。3. 业务必需停止：在执行export/imp过程中，业务一般需要中断。4. 易出错：尤其在Import过程中，由于表之间的关联性存在，往往出现由于违反参照完整性规则而导致装载中断，非常难于操作。而DATAGRID DDS在数据的一致性同步方面有着非常好的解决方案，这是其它方案所不具备的。DataGrid DDS集成有数据的一致性同步工具，能够自动化的进行数据的首次同步和出现差异情况下进行一致性同步的工作，无需人工干预，维护工作量小，且大大提高了工作效率：1. 速度快：对于几十GB的数据量，在系统正常且带宽充足的情况下，只需要1小时左右完成初始数据同步。2. 完全自动化：采用DataGrid DDS只需要条命令就完成系统的初始化工作，系统自动进行导出、传输和装载任务，完全无需人为干预，减少出错机会。3. 不中断业务：在DataGrid DDS在进行首次数据同步时，无需停止交易生产业务，实现不停机的系统初始化；1.2.5. 实时复制当对系统的初始化环境工作结束后，DataGrid DDS自动进入实时复制状态，无需手工干预。1.2.6. 灾难后的数据恢复在业务数据库系统发生灾难的情况下，此时可使用灾备数据库首先接管业务，然后进行数据的反向恢复。具体步骤为： 1. 数据库发生灾难，业务交易业务停止； 2. 修改TNS的指向，将业务指向灾备的数据库，接管业务； 3. 应用系统重新连接灾备数据库，完成业务接管； 4. 停止DataGrid DDS复制进程； 5. 排除系统故障； 6. 恢复原业务系统的Oracle数据库 7. 启动DataGrid DDS进程 8. 将数据反向批量同步到原系统上，此过程中灾备数据库继续进行业务处理，无需中断9. 数据重新同步结束后，停止灾备数据库的业务 10. 修改TNS指向，将业务指向原来的（已经恢复的）数据库 11. 应用系统重新连接集中交易数据库，完成业务回切 12. 配置DataGrid DDS进行正向复制以上过程是利用灾备中心的系统首先接管业务后，再进行生产中心的修复和数据的反向复制，因此不会造成长时间的业务中断。1.3. 复制系统的有效性1.3.1. 数据丢失情况DataGrid DDS解决方案在一般性灾难发生时不存在数据丢失。这些一般灾难包括数据库失败、操作系统失败等等。对于一些极端的情况下，掉电、站点失败时，DataGrid DDS也作了大量测试不会出现数据丢失（但从理论上讲这些极端情况无法100%避免数据丢失，因为这种情况可能造成了系统的严重破坏）。l 网络失败：网络恢复时继续复制，没有数据损失。l 数据库关闭：数据库恢复时从断点继续复制，没有数据损失。l 操作系统重起：重新启动复制软件，从断点处继续复制，没有数据损失。l 掉电：DataGrid Replication也作了大量测试不会出现数据丢失（但从理论上讲这些极端情况无法100%避免数据丢失，因为这种情况可能造成了系统的严重破坏）。不过对于重要的生产系统一般通过UPS预防断电情况,发生概率非常小.。l 站点失败：由于目标系统在线可用，不存在任何数据风险。但对于还没来得及传输到目标系统的数据可能出现丢失。1.3.2. 数据延迟DataGrid DDS是一种异步准实时的复制技术，其数据延迟非常小。数据延迟的周期可以设置，在生产系统中，数据延迟和源系统复制事物的多少，事物的处理方式有关，以及跟设置的log数据轮询周期有关。在复制数据量正常的OLTP系统中，数据延迟一般在几秒钟。1.3.3. 复制环境的健壮性DataGrid DDS方案具备足够的健壮性。源系统和目标系统的任何故障都不会影响到复制环境。在以下故障发生时，DataGrid DDS故障处理方法如下：l 源系统主机故障：源系统主机故障修复后，当Oracle数据库和操作系统重新启动后，DataGrid DDS自动重试连接数据库，并从断点继续进行复制工作。l 数据库故障：当源系统数据库故障修复后，当Oracle数据库重新启动后，可以从断点继续进行复制工作。l 复制软件故障：当复制软件的进程遇到问题时，可以自动重起相关进程。如果不能自动重启，也可手工重启进程。进程的重启不会对复制数据产生影响。l 网络故障：当网络恢复后可以自动从断点进行复制工作。l 目标系统的主机故障：数据存储在目标系统队列中，当目标系统主机故障修复后，从断点继续进行复制工作。l 数据库故障：数据存储在目标系统队列中，当目标系统数据库修复后，从断点继续进行复制工作。1.3.4. 事物的完整性和可用性DataGrid DDS是一个数据库级的软件解决方案，其复制的基本单位就是一个事务(Transaction)，DataGrid DDS在从oracle log中读取到交易数据后，根据交易的关系，将属于一个事务的所以操作组合在一起，以一个基本单位发送给目标端，目标端在执行时也严格按照交易进行，因此严格保证了交易的完整性。对于事务与事务之间的顺序，DataGrid DDS严格按照ORACLE 的SCN标记进行排序。确保事务之间的先后秩序。1.3.5. 复制系统资源占用1.3.5.1. 对源系统性能的影响与其它类型的复制产品比较，DataGrid DDS要求的整体系统资源很少。无须采购指定型号的硬件，如磁盘阵列；不需要特殊基础软件配合，如专用文件系统；也不需要应用软件支持，完全无关。对于单个系统的资源使用，平均的CPU利用率为5%左右，内存使用小于100MB，在没有交易处理工作的时候，不占用系统资源。这样的资源使用基本不会对数据库的运行产生任何影响。同时，DataGrid DDS在安装调试过程不会改动数据库，也不涉及文件系统、操作系统和数据卷。完全能够在业务系统不停机甚至工作状态下实施安装、调试。而其他的解决方案可能需要停机，甚至改动软硬件的配置。对生产系统将会产生较大的影响。1.3.5.2. 对网络资源的使用DataGrid DDS方案所需网络带宽很少，能够在有限传输带宽上保证复制工作不延迟。因为DataGrid DDS复制操作只是读取操作系统的日志文件，同时通过TCP/IP方式而不是采用中间件方式传输只发生改变的数据也使网络负载降至最低。通常情况下DataGrid DDS传输的数据量只相当于日志的三分之一，而且传输过程中还有压缩机制。1.3.5.3. 对系统扩容的影响DataGrid DDS解决方案对今后的扩容没有任何影响。使用DataGrid DDS，源数据库和目标数据库可以运行在不同类型的操作系统和同一Oracle数据库的不同版本上。同时，也能够支持不同类型的磁盘阵列。这不仅能够满足目前异构环境，还能适应未来的扩展需求。随着业务量规模的不断扩大，在硬件升级时，新旧硬件产品可以随意调换，不受限制。1. 数据查询应用平台方案1.1. 构建企业的第二数据中心在基于DataGrid DDS产品实现灾备架构中，不仅能够实现集中交易系统的灾备功能，实现0时间的数据库切换。同时在该架构基础上还能够为外部系统接口提供了更具扩展力的数据基础管理平台。利用灾备系统对应用进行重新部署。图：利用灾备系统加载业务功能因为传统应用部署都是以生产数据库中心为核心的，所有的外围系统数据都直接来源于生产系统，但随着业务变化的逐步深入，外围系统越来越复杂时，这种架构为企业应用部署带来了新的挑战：l 可扩展性较差，生产系统性能无法满足大量的外部系统延伸；l 生产系统功能单一，系统建设难度加大，系统建设失败率升高；l 生产系统稳定性差，大量的新增外围系统的部署要求生产系统处于不断变化之中。生产系统的稳定性和连续性受到很大影响。DataGrid DDS支持应用系统部署的优化。将部署架构从传统的“以生产中心为基础”的模式转向为“以灾备系统为基础”的架构。将外围系统如：测试系统、归档系统、统计查询系统、决策支持系统等建立在灾备数据库基础上，在与生产数据库隔离的情况下任意扩展外围系统，而不会对生产系统产生任何影响。通过DataGrid DDS建立的灾备系统可提供业务连续性支持，更可以实现生产系统信息的流通与共享，提升生产系统价值。实现灾备、数据共享一体化数据管理架构。1.2. 统一查询平台的优势1.2.1. 数据集中复制查询DataGrid DDS支持多对一的复制部署，即可以将多个数据库的数据同时复制到一个目的端数据库。1.2.2. 提高查询的实时性目前很多查询方案都是定时地从生产数据库手工抽取数据进行应用，数据的实时性得不到保证。而证券行业交易的特点是突发性和随机性高，对于数据分析来讲，数据的实时性得不到保证无疑是耽误了分析决策的最佳时机。DataGrid DDS能够自动的实时将数据复制到查询数据库，将查询数据的延迟由以“天”为单位降低到以“秒”为单位，根本性的提高了数据应用的有效性和及时性。1.2.3. 减少对生产系统的资源占用未来的大量并发查询请求的出现，将对生产交易系统的资源争用非常严重，从而导致查询业务非常缓慢，同时也导致生产业务性能大幅度下降。所以将查询数据库分离出来后，能够减轻生产系统的压力。1.2.4. 查询性能的优化通过将查询系统独立可以提高查询的性能。查询数据库与生产数据库完全独立，可以按照OLAP系统的标准进行单独优化，如修改数据库存储及内存参数，增加索引等工作能大幅提高查询性能。1.2.5. 提供后续业务的支撑通过独立的查询系统，除了满足基本的查询功能外，还可在该平台上提供各种报表、统计分析和数据应用的接口功能，进而发展成为企业内部的统一数