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