关于压力大的Oracle数据库的同步复制容灾应用

作者：小新时间：04-09-24 08:04

　　有人有兴趣讨论下压力大的数据库的容灾嘛？

　　大家一般实际中用的都是哪种方式的容灾啊？最近做容灾测试，发现存储级的容灾存在缺陷：目前的系统压力不小，每秒3M左右的redo（不是峰值）。主中心和容灾中心采用的是异地存储级的同步。在系统繁忙的时候突然断掉主容中心之间的通讯，发现容灾中心的数据库多数情况下是无法启动的。不知道大家有什么好的建议嘛？

--------------------------------------------------------------------------------

　　作者：biti_rainy时间：04-09-24 09:26

　　突然断掉，很可能容摘灾的存储上文件时间点不一致，具体下来不知道是不是和你们的同步的设置有关。对于数据库这样对文件时间点一致性要求很强的要求，稍不注意可能就有问题。从原理上来讲，很难满足数据库的要求的，理论上来说两端写cache 不一致都很可能造成问题。而做存储的人也始终没有给我一个满意的答复。从事实上来看，据某做存储的人说，数据库能正常open的概率不超过2/3

--------------------------------------------------------------------------------

　　作者：wzy25时间：04-09-24 12:00

　　不建议对数据库做存储记得远程容灾，通过data guard、dsg realsync或者 share plex来做比较好

--------------------------------------------------------------------------------

　　作者：biti_rainy时间：04-09-24 12:05

　　问了问，oracle 有对存储容灾的认证，必须通过oracle认证的存储厂商的存储设备在特定设置要求下，才能得到保证

--------------------------------------------------------------------------------

　　作者：小新时间：04-09-25 19:46

　　请问biti_rainy，是不是通过oracle认证的存储厂商的在特定设置后就不会出现问题呢？在哪里能查的到这些厂商？我记得以前也看到你提过这方面的问题，从原理上讲如何保证存储同步和oracle同步达到一致，有相关的材料吗，谢谢了。

--------------------------------------------------------------------------------

　　作者：小新时间：04-09-25 19:47

　　我的归档量很大，dataguard、dsg realsync和share plex适合吗？

--------------------------------------------------------------------------------

　　作者：Kamus时间：04-09-28 13:57

　　对于DataGuard来说，网络条件比较重要，异步传输几乎不会对主机产生多大影响。只要带宽足够，那么归档量大也不是很大问题。我们的测试，每秒10M以上redo，2M带宽专线，物理备用库，跑的还算稳定。share plex没有测试过，不太清楚。

--------------------------------------------------------------------------------

　　作者：wzy25时间：04-10-08 17:11

　　如果归档量很大的话，通过、dsg realsync的对带宽的要求是最小的，因为它只传输 sql redo,而不传输redo log里面的 sql undo的。采用存储及得容灾消耗带宽最高。

--------------------------------------------------------------------------------

　　作者：HUHU123456时间：04-10-12 18:47

　　其实这方面产品还有GoldenGate，我们测过，比share plex的好用，就是国内应用的案例比较少，dsg realsync现在好像用的人比较多

--------------------------------------------------------------------------------

　　作者：zhyuh时间：04-10-13 12:04

　　小新有没有注意容灾数据库起步来原因是什么？我们那时候transaction忙的时候宕机，灾备数据库起不来都是因为rollback segment有坏块。解决这个问题后灾备数据库能起来，但是涉及到的表里也有坏快。另外oracle存储容灾认证也不一定可信，我们那时的pprc产品就是oracle认证的。个人认为还是data guard比较好。你们采用异地同步方式，肯定走光纤，这对data guard足够了

--------------------------------------------------------------------------------

　　作者：hzy789时间：04-10-15 08:40

　　容灾的基本方式有基于以下几种方式:存储级, 主机级LVM, 应用级三种方式.

　　对于存储级来说,需要有一定的配置经验,异地的存储阵列必须是同一厂家,它的效率比较高,当然它的成本也较高,目前EMC,IBM,hitch 均有相关产品,从使用稳定性来讲,最好的当数EMC SRDF + BCV ,{有兴趣,可以发邮件细谈 email_shy@263.net},为了保证数据库数据的一致性,建议容灾采用同步方式。

　　对于主机LVM的容灾方式,它的比较灵活,异地之间的存储可以是不同厂家的,比如,Virtas LVM

　　第三种就是应用级,1,Dsg RealSync, 2, Quest SharePlex 当然这两种东西都是针对ORACLE开发的,还有Data Guard

--------------------------------------------------------------------------------

　　作者：hzy789时间：04-10-15 08:43

　　对上述几家的产品,均有研究,考虑容灾要从,效率,投资以及RPO,RTO等不同方面进行考虑,各个厂家的产品都有一定的特点......

--------------------------------------------------------------------------------

　　作者：wzy25时间：04-10-18 10:18

　　可以考虑通过stream来做的，目前可能不太稳定，但是到10g应该功能完善了

--------------------------------------------------------------------------------

　　作者：eagle_fan时间：04-10-18 21:15

　　我知道的是HP的EVA存储系列产品是通过oracle认证的

　　为什么能做到可以启动，我听HP的人讲是说。例如oracle写主存储中心的次序是block 1,2,3,4,5的话，那么在备份存储中心写的次序也是1，2，3，4，5，不会打乱次序。

　　另外DR有同步和异步的方式，同步的话如果备份存储中心没有拷贝到数据的话，主存储中心不会给出已经接受的信号给服务器。同步是下面的流程：

　　1. 服务器写入主存储中心data block

　　2. 主存储中心将这个被修改的block复制到备份存储中心

　　3.备份存储中心回复确认信号给主存储中心

　　4.主存储中心回复确认信号给服务器

　　异步的流程如下：

　　1. 服务器写入主存储中心data block

　　2.主存储中心回复确认信号给服务器

　　3.主存储中心将该data block（这个动作是有次序的，就是保证在这之前写入主存储中心的block已经全部拷贝到了备份存储中心上，而之后的block都没有写，也就是上面所说的次序不会打乱）复制到备份存储中心

　　4.备份存储中心将回复确认信号给服务器

--------------------------------------------------------------------------------

　　作者：Kamus时间：04-11-03 15:48

　　目前我们的Dataguard的测试已经结束了。Veritas的Volume Replicator也已经测试完毕，基本上算是pass掉了，基于卷的复制仍然不是很适合与数据库系统。即将测试Quest的Shareplex。已经跟Quest的技术人员作过交流，感觉shareplex支持异构平台，并且网络传输量少这几个特点比较吸引人。希望听到更多关于Dsg RealSync和Goldengate的评测感受。

--------------------------------------------------------------------------------

　　作者：Kamus时间：04-11-03 15:59

　　目前DSG的同步复制软件应该是叫 RealSync？刚刚看了DSG的站点，对他们对自己的产品了解了一些。

--------------------------------------------------------------------------------

　　作者：Kamus时间：04-11-03 16:10

　　其实现在各大厂商的基于block级别的复制软件都是同样的这个机制，都提供同步和异步方式。

　　最主要的是对于Oracle这种一致性要求特别高的数据库，就有可能block 1,2,3,4,5必须全部复制到远程，数据库才可以打开，如果是只复制了1,2,3网络就因为故障停止了，怎么办？

　　还有就是对于基于磁盘block或者卷级别的复制，对于存储在buffer cache中或者磁盘缓存中的数据自然就无法同步了，那么在网络故障或者主机故障时，是不是可能就会丢失更多数据？

--------------------------------------------------------------------------------

　　作者：eagle_fan时间：04-11-06 00:54

　　我觉得网络故障这些在远端来看就相当于本地的shudown abort的情形。数据库文件不一致，需要instance recovery，不过大部分的情形是可以开起来的

　　最近对EMC的两跳功能比较感兴趣，就是先做同步再做异步，好像是EMC独有的，稍后给大家的评测报告

--------------------------------------------------------------------------------

　　作者：Kamus时间：04-11-08 02:04

　　shutdown abort后所有需要的recovery数据都在本机的redo中。只要数据文件，redo不损坏，数据库就可以打开。但是并不一定这些redo就会同步到远程，那么远程就有可能启动不了数据库。

--------------------------------------------------------------------------------

　　作者：wzy25时间：04-11-09 10:24

　　share plex不错，我们测试过，若且性能很好，延迟非常低。即将测试stream。

--------------------------------------------------------------------------------

　　作者：eagle_fan时间：04-11-11 08:26

　　上面讲到，如果是同步的话，远端没有接受到数据块，local就不会认为数据已经写入本地硬盘，所以在网络断开的情况下，没有一致性的问题

　　如果是异步的话，在存储级别看的话，不管是数据文件还是redo log或是control file都是一样的异步机制。如果是实现了数据块的传输次序和local 硬盘写入的次序一样的话，应该可以认为是远端的shutdown abort吧，举个例子：例如网络是下午3点10分断的，此时local的数据块写入到了3点10分，远端传输的数据块是3点9分的。只要保证3点9分前的数据块（包括数据文件和redo log，control file等等，存储级别不管这些）全部写入，3点九分后的数据块全部没有写入（也就是上面提到的异步按照local的写入次序写入远端）。这和local端三点9分shutdown abort不是一样的吗

　　我是这样理解的，大家讨论讨论吧

--------------------------------------------------------------------------------

　　作者：Kamus时间：04-11-11 10:44

　　问题在于你如何保证这个SCN点的所有block改变都全部传到了远程？

　　假设我们认为一个checkpoint之后，所有的数据文件全部同步了，OK，现在改变了100个block，这100个block的改变被同步软件获得了，开始往远程传，一个极端的环境下，传到50个block改变的时候，网络中断了，此时你认为远程的数据库一定可以正常启动吗？

--------------------------------------------------------------------------------

　　作者：Kamus时间：04-11-19 21:50

　　希望能够在机制上说明一下为什么Dsg RealSync会好于shareplex？感觉两个都是从oracle的redo中提取SQL，而shareplex的效率已经是很高了。

　　Dsg RealSync这样的软件正是因为只提取相关对象的SQL，所以网络传输量很少。而且因为是在Primary端已经提取完了SQL（？），所以比Oracle的Logic Standby效率要高

　　但是这也导致了一个问题，我们设想一下这种情况：

　　我们在Dsg RealSync中设置允许传播DDL语句。在Primary端，我们执行create table a as select * from dba_objects; 这样这条SQL会被传播到备用端。但是备用端的对象很可能是跟主库不一样的，这样就导致这两张表在数据上的不相同，甚至由于数据库版本的差别还会导致表结构的不同。然后，对于此表的进一步DML操作，可能在备用端都会失败

--------------------------------------------------------------------------------

　　作者：eagle_fan时间：04-11-24 01:38

　　这还是相当于shutdown abort的情形啊。相当于就是local端在做checkpoint的时候，写入50个block掉电了。但是由于网络传输的原因，导致远端的几率大一点，但是现在做DR的网络带宽也是不小的。

 

 

eygle_fan,你咋转不过来呢?无论本地怎么坏，只要redo在都好办。问题是启用远程的时候，基本上就是本地用不了了，那么就可能会有需要恢复的数据没有传过去。而在本地不会有这种情况，无论是在redo里，实在数据文件里，是在回滚段里，只要这些东西都完好，数据库就可以起来

--------------------------------------------------------------------------------

　　作者：silverwang    时间：04-11-26 16:32

　　其实说白了，就是存储级的容灾做不出事务级的存储(比如，我要求N个按顺序传向不阵列或者同阵列不同光纤通道的多个数据块要么同时存储成功，要么同时失败).因此，窃以为将来的趋势还是依赖于数据库自身的事务将容灾集合起来更可靠.(就如Dataguard)

--------------------------------------------------------------------------------

　　作者：eagle_fan    时间：04-11-27 23:07

　　回滚段是在数据文件里面的吧。redo也是在日志文件里面的。远端也是同样有数据文件,redo log的吧？"就可能会有需要恢复的数据没有传过去。"这句话如何理解呢

--------------------------------------------------------------------------------

　　作者：biti_rainy    时间：04-11-28 10:42

　　如果你总是能保证传输的顺序和 oracle 写顺序一致，或者一起，那肯定没有问题的。至少也要保证日志和归档是率先传过去的。根据我了解的情况，在同步传输的时候，本地会冻结存储cache使得无法做任何写入，同步完毕才可以做写入。这样对于文件系统可能就有一个新的问题，那就是 OS 还有cache，这部分数据可能就麻烦了,兴许只有 raw device 才是安全的。

--------------------------------------------------------------------------------

　　作者：Kamus    时间：04-11-28 23:47

　　我曾经对于磁盘cache的问题咨询过veritas的工程师。回答曰：这个是没有办法保证的。

　　意思就是如果磁盘的block不发生变化，基于存储级别的同步软件都无法保证传输。但是我倒是觉得应对磁盘cache的技术对于veritas等厂商应该还是应该考虑到的

--------------------------------------------------------------------------------

　　作者：wolfgroup    时间：04-12-06 23:03

DSG has:
DSG RealSync
DSG SmartE
DSG SnapAssure
DSG SnapGuard
DSG SnapShare
never has 'DSG Snapshop'.

--------------------------------------------------------------------------------

　　作者：dx6340    时间：04-12-07 11:01

　　我现在用shareplex的在数据同步中，1天处理archive log 在 200G，DSG没有用过，但是听客户说还能处理得更多（PS: 只是听说，我没有测试过）

--------------------------------------------------------------------------------

　　作者：huanghongjie    时间：04-12-07 11:07

　　其实现在任何一种灾备都不是零风险的，需要从多个方面考虑的。无论是同步还是异步，无论是用dataguard还是存储级别冗灾，我想都有可能丢数据。所以在讨论灾备的时候，还应该考虑从应用系统完善和灾备技术结合上总体考虑，我想一些灾备的能力就可能提高了。

--------------------------------------------------------------------------------

　　作者：Kamus    时间：04-12-08 02:26

　　我听一个实际测试过shareplex的人说当一天的日志量达到60G以上的时候，shareplex就应付的比较吃力了。你的系统一天归档有200G？

--------------------------------------------------------------------------------

　　作者：Kamus    时间：04-12-08 02:31

　　所以我们的方案会有一个最后1分钟数据的拯救功能，根据我们自己系统的业务log来作。如果使用dataguard，那么就设置归档的lag是1分钟，这样可以保证没有数据丢失。

　　但是我自己心中也有些打鼓，这个一分钟归档一次是不是有些过于频繁了。

--------------------------------------------------------------------------------

　　作者：eagle_fan    时间：04-12-08 10:14

　　hi biti：

　　oracle使用os的cache吗？oracle是采用synchronous writes的方式立即写入硬盘

　　下面这篇文章取自ixora

　　Oracle Internals Notes

　　Buffered I/O
    
    Most file system I/O is buffered by the operating system in its file system buffer cache. The idea of buffering is that if a process attempts to read data that is already in the cache, then that data can be returned immediately without waiting for a physical I/O operation. This is called a cache hit. The opposite is called a cache miss. When a cache miss occurs, the data is read from disk and placed into the cache. Old data may have to be removed from the cache to make room for the new data. If so, buffers are reused according to a least recently used algorithm in an attempt to maximize the number of cache hits.

    The file system buffer cache is also used for write operations. When a process writes data, the modified buffer goes into the cache. If the process has explicitly requested the synchronous completion of writes (synchronous writes) then the data is written to disk immediately and the process waits until the operation has completed. However, by default delayed writes are used. User processes do not wait for delayed writes to complete. The data is just copied into the buffer cache, and the operating system has a background task that periodically flushes delayed write buffers to disk. Delayed writes allow multiple changes to hot blocks to be combined into fewer physical writes, and they allow physical writes to be optimally ordered and grouped.

    Delayed writes can be lost if a system failure occurs while some delayed writes are still pending. Some file systems support a write behind mount option that minimizes the delay before the flushing of delayed write buffers begins. This minimizes the risk of data loss, but reduces the benefit of delayed write caching. It also reduces the risk and severity of delayed write backlogs.

    Because delayed writes involve a risk of data loss, Oracle never uses them. Oracle insists on the synchronous completion of writes for all buffered I/O to database files. This is done by using the O_DSYNC flag when opening database files. This means that the data itself must be written synchronously, but that delayed writes may be used for updates to the file access and modification times recorded by the file system.

    Do not confuse delayed writes with asynchronous writes. User processes do not wait for the completion of either type of writes. But, they are notified or learn when asynchronous writes have been completed, whereas there is no notification of the completion of delayed writes. It is just assumed that delayed writes will be completed. Thus delayed writes involve a risk of data loss, but asynchronous writes do not.

--------------------------------------------------------------------------------

　　作者：biti_rainy    时间：04-12-08 11:16

　　关于这个问题我倒确实不大清楚。以往的现象是当使用文件系统的时候会使用比较多的 file cache，这么说来，难道是读的时候cache了？读的时候cache了要有效的话，写的时候需要那这些file cache里面的block 抹去？或者说我们如何完整地解释这个问题

--------------------------------------------------------------------------------

　　作者：dx6340    时间：04-12-08 13:12

　　我做的一个电信客户，高峰期一天200个G。shareplex在某一段高峰时间有些延迟，但是总体上来看还是能满足客户的需求。

--------------------------------------------------------------------------------

　　作者：huanghongjie    时间：04-12-09 11:37

　　看到大家都提到shareplex这个产品，我想问问:这个产品在国内有成功案例吗？能列举一些吗？大概是个什么样的价格？上面有人提到数据库的日志有200G，好像据我所知这个产品能够定制很细的策略，比如到表的字段，也就是说数据库的日志很大，但是不一定让shareplex传输的数据量很多，这个好像要跟客户的灾备要求有关吧，比如只是需要把详单表的变化传过去，就没必要传帐单表的变化了。我想问问如果是异地灾备（1千公里以上），现在电信能够提供的传输带宽和线路类型是什么？

--------------------------------------------------------------------------------

　　作者：dx6340    时间：04-12-09 12:58

　　在国内有成功案例，具体可致电Quest Software 在中国的分公司。的确，shareplex只把自己需要把定制好要复制表的数据和DDL传递。电信提供的方式很多，具体咨询当地的电信部门。

--------------------------------------------------------------------------------

　　作者：biti_rainy    时间：04-12-10 17:30

　　这个问题，参考 http://218.94.123.17/viewthread.php?tid=39750。这里做了进一步探讨。steve 说的没错，但进一步控制权还在os自身上

--------------------------------------------------------------------------------

　　作者：eagle_fan    时间：04-12-12 13:46

　　关于这个还是有点不同的意见，发在上面这篇文章上。

　　不过关于同步和异步的问题，倒让我联想到了oracle的slave IO虚拟异步的机制

　　如果操作系统不支持异步IO，oracle采用slave IO实现Asynchronous I/O。因为oracle总是会向系统申请操作，需要等到操作系统说“OK,已经写好了”。如果没有slave IO,DBWR总是处于write/wait/write/wait的状态。所以DBWR会通过slave IO实行IO操作，只需要slave IO回报说“OK，已经写好了，DBWR就继续写。DBWR处于write/write/write...

　　可以提高性能

　　和这个主题无关，只是随便想到了

--------------------------------------------------------------------------------

　　作者：cyr1974    时间：04-12-12 15:32

　　我认为最安全的方式还是在数据库这个级别做到基于事务的容灾

--------------------------------------------------------------------------------

　　作者：dx6340    时间：04-12-15 17:08

　　具体的延迟因素很多1）2边ORACLE的当前负载 2）数据库间的网路带宽 3）复制数据的动作，就是DML动作 4）复制数据的属性，有无唯一INDEX等等。需要整体评估

 

--------------------------------------------------------------------------------

　　作者：fengda    时间：04-12-17 13:29

　　我们是dsg realsync的用户，感觉他们的产品还不错，特别是在首次同步的时候，不用停业务，实施起来省了很多麻烦，测试下来效率要高一些，另外能提供本地化服务，这是俺们最需要的....

容灾备份异地容灾数据容灾容灾系统数据同步复制采集归档检索集中分发容灾方案异地容灾备份远程容灾容灾技术异地容灾方案oracle容灾容灾方案异地容灾数据容灾容灾是什么容灾系统异地容灾备份oracle容灾容灾备份数据容灾系统异构容灾方案下载EMCSRDF容灾技术和业务连续性服务方案,IBMPPRC,HPBusinessCopy,HDSTrueCopy,VERITASVVR；DSGRealSync,QuestSharePlex等,HDS数据中心容灾解决方案,飞康公司的持续数据保护(CDP)抽取共享升级迁移优化灾难恢复备份恢复数据保护器FalconStorCDP,StoreAge容灾方案,SEPATON容灾解决方案oracle数据库备份oracle自动备份oracle数据备份oracle冷备份oracle备份表证券税务财政社保公安电力交通保险银行工商石化电信联通移动网通企业管理金宏钱金税金关金财金卡和金审社会金盾金保金农金质和金水热备异构热容灾方案备份软件工具方案技术磁盘磁带oracle备份与恢复oracle定时备份oracle备份命令oracle热备份oracle的备份与恢复oracle如何备份oracle备份还原oracle备份方式oracle逻辑备份oracle9i备份oracle联机备份DSG公司DSGRealSync数据库复制容灾软件抽取共享升级迁移优化灾难恢复备份恢复oracleexp备份oracle备份rmanoracle的备份oracle远程备份oracle的rman备份oracle备份方案oracle备份脚本oracle数据备份语句oracle备份工具oracle增量备份oracle备份技术oracle物理备份oracle冷备份脚本异地容灾备份oracle备份表空间SnapAssure高速备份恢复软件pb备份oracle数据库oracle备份级别oracle容灾备份oracle容灾方案oracle容灾技术招标oracle容灾备份oracle容灾dataguardoracle容灾产品电信级容灾系统建设boss容灾系统分布式数据容灾系统数据同步复制采集归档检索集中分发容灾系统的实现原理数据库容灾系统上海移动boss容灾系统证券税务财政社保公安电力交通保险银行工商石化电信联通移动网通企业管理金宏钱金税金关金财金卡和金审社会金盾金保金农金质和金水热备异构热容灾方案备份软件工具方案技术磁盘磁带RealMigrates数据库异构平台实时迁移软件建设银行容灾系统异地容灾系统结构pptvvr容灾系统容灾系统级异地容灾方案veritas异地容灾方案远程容灾方案vvr容灾方案iscsi容灾方案oracle容灾方案应用级容灾方案数据同步复制采集归档检索集中分发数据容灾方案远程异地容灾方案电信容灾方案数据备份方案双机热备份方案数据库备份方案服务器备份方案oracle备份方案oracle数据库备份方案异地备份方案异地容灾备份veritas备份方案doc磁带机备份方案企业数据备份方案案企业数据备份方案北京天津河北山西内蒙辽宁吉林黑龙江上海江苏浙江安徽福建江西山东河南湖北湖南广东广西海南四川 重庆贵州云南西藏陕西甘肃青海宁夏新疆大连厦门青岛苏州应急平台容灾中心查询平台OLTP VS OLAP数据抽取复制报表分离负载均衡数据集中数据广播应用数据实时同步实时数据仓库及决策支持系统应用

容灾备份异地容灾数据容灾容灾系统数据同步复制采集归档检索集中分发容灾方案异地容灾备份远程容灾容灾技术异地容灾方案oracle容灾容灾方案异地容灾数据容灾容灾是什么容灾系统异地容灾备份oracle容灾容灾备份数据容灾系统异构容灾方案下载EMCSRDF容灾技术和业务连续性服务方案,IBMPPRC,HPBusinessCopy,HDSTrueCopy,VERITASVVR；DSGRealSync,QuestSharePlex等,HDS数据中心容灾解决方案,飞康公司的持续数据保护(CDP)抽取共享升级迁移优化灾难恢复备份恢复数据保护器FalconStorCDP,StoreAge容灾方案,SEPATON容灾解决方案oracle数据库备份oracle自动备份oracle数据备份oracle冷备份oracle备份表证券税务财政社保公安电力交通保险银行工商石化电信联通移动网通企业管理金宏钱金税金关金财金卡和金审社会金盾金保金农金质和金水热备异构热容灾方案备份软件工具方案技术磁盘磁带oracle备份与恢复oracle定时备份oracle备份命令oracle热备份oracle的备份与恢复oracle如何备份oracle备份还原oracle备份方式oracle逻辑备份oracle9i备份oracle联机备份DSG公司DSGRealSync数据库复制容灾软件抽取共享升级迁移优化灾难恢复备份恢复oracleexp备份oracle备份rmanoracle的备份oracle远程备份oracle的rman备份oracle备份方案oracle备份脚本oracle数据备份语句oracle备份工具oracle增量备份oracle备份技术oracle物理备份oracle冷备份脚本异地容灾备份oracle备份表空间SnapAssure高速备份恢复软件pb备份oracle数据库oracle备份级别oracle容灾备份oracle容灾方案oracle容灾技术招标oracle容灾备份oracle容灾dataguardoracle容灾产品电信级容灾系统建设boss容灾系统分布式数据容灾系统数据同步复制采集归档检索集中分发容灾系统的实现原理数据库容灾系统上海移动boss容灾系统证券税务财政社保公安电力交通保险银行工商石化电信联通移动网通企业管理金宏钱金税金关金财金卡和金审社会金盾金保金农金质和金水热备异构热容灾方案备份软件工具方案技术磁盘磁带RealMigrates数据库异构平台实时迁移软件建设银行容灾系统异地容灾系统结构pptvvr容灾系统容灾系统级异地容灾方案veritas异地容灾方案远程容灾方案vvr容灾方案iscsi容灾方案oracle容灾方案应用级容灾方案数据同步复制采集归档检索集中分发数据容灾方案远程异地容灾方案电信容灾方案数据备份方案双机热备份方案数据库备份方案服务器备份方案oracle备份方案oracle数据库备份方案异地备份方案异地容灾备份veritas备份方案doc磁带机备份方案企业数据备份方案案企业数据备份方案北京天津河北山西内蒙辽宁吉林黑龙江上海江苏浙江安徽福建江西山东河南湖北湖南广东广西海南四川 重庆贵州云南西藏陕西甘肃青海宁夏新疆大连厦门青岛苏州应急平台容灾中心查询平台OLTP VS OLAP数据抽取复制报表分离负载均衡数据集中数据广播应用数据实时同步实时数据仓库及决策支持系统应用