数据库容灾、复制解决方案全分析(绝对精品)要点
数据库中的数据备份与容灾解决方案
数据库中的数据备份与容灾解决方案数据是现代社会的一项重要资源，对于企业以及个人来说都具有极高的价值。
然而，数据也面临诸多风险，如硬件故障、自然灾害、人工操作失误等，这些都可能导致数据的丢失或不可用性。
为了保障数据的安全和可靠性，数据库中的数据备份与容灾解决方案成为了必不可少的考虑因素。
I. 数据备份方法数据备份是指将数据库中的数据复制到其他介质中，以便在数据遭到破坏或丢失时能够进行恢复。
常见的数据库备份方法包括完全备份、增量备份和差异备份。
1. 完全备份完全备份是指将整个数据库的所有数据和对象都进行备份，通常是在一个特定的时间点进行。
这种备份方法的优点是恢复速度快，但缺点是占用存储空间较大且备份时间较长。
2. 增量备份增量备份是基于完全备份的基础上，只备份自上次增量备份以来的新增或变化部分。
这种备份方法节省了存储空间和备份时间，但在恢复时需要先还原完全备份，再逐个应用增量备份。
3. 差异备份差异备份是基于完全备份的基础上，只备份自上次完全备份以来的修改部分。
与增量备份不同的是，差异备份不会逐个累加，而是只备份与上一次差异备份之间的差异数据。
这种备份方法可以减少备份时间和存储空间，但在恢复时需要还原完全备份和最近一次差异备份。
II. 数据容灾解决方案数据容灾是指当某个灾难性事件发生时，能够保证数据的持续可用性和业务连续运行。
常见的数据容灾解决方案包括冷备、热备、多活架构等。
1. 冷备冷备是指在容灾场景中，备用数据库不处于运行状态，只有在主数据库发生故障时才启动备用数据库并进行切换。
冷备方案通常适用于对业务连续性要求不高的场景，优点是成本低，但切换时间较长。
2. 热备热备是指备用数据库处于运行状态，与主数据库保持数据同步，能够实时接替主数据库的数据处理工作。
热备方案通常适用于对业务连续性要求较高的场景，切换时间短，但成本较高。
3. 多活架构多活架构是指在不同地点或数据中心建立多个数据库节点，并确保数据同步。
数据库容灾与灾备解决方案
数据库容灾与灾备解决方案在现代信息化时代，数据库作为企业重要的数据存储和处理工具，对企业的正常运营至关重要。
然而，数据库系统也面临着各种潜在风险，如系统故障、自然灾害、恶意攻击等，这些风险可能导致数据库数据的丢失和系统的中断。
为了应对这些风险，数据库容灾和灾备解决方案应运而生。
一、数据库容灾的概念和原则数据库容灾是指在数据库系统遭遇故障或灾害时，能够保持数据库系统的可用性和数据的完整性。
容灾的原则是以数据为中心，采取措施确保数据的安全、可靠和高可用的运行。
1.备份与恢复：通过定期备份数据库，以便在发生故障或灾害时进行数据恢复。
备份可以分为完全备份和增量备份，完全备份是指将整个数据库进行备份，增量备份则是在完全备份的基础上，将新增或修改的数据进行备份。
2.冗余与高可用：通过多台服务器或多个数据中心之间的冗余配置，当一台服务器或一个数据中心发生故障时，其他服务器或数据中心仍然可以继续提供服务，确保系统的高可用性。
3.监控与预警：采用监控系统监测数据库的运行状态，及时发现异常并进行预警，以便及时采取措施修复问题，确保数据库系统的稳定运行。
二、数据库容灾解决方案针对数据库容灾，有以下几种解决方案可以选择：1.异地备份与恢复：将数据库备份数据存储在异地的数据中心或云平台上，当主数据中心发生故障时，可以在备份数据的地方进行数据的快速恢复。
这种方式可以大幅降低数据丢失的风险，确保数据的安全性和完整性。
2.主备复制：通过在主数据库与备份数据库之间建立数据库复制机制，将主数据库的变动同步到备份数据库中，当主数据库发生故障时，可以快速切换到备份数据库，实现高可用性的运行。
主备复制可以采用同城复制或异地复制的方式。
3.容器化部署：将数据库系统以容器的方式进行部署，在发生故障时可以快速搭建新的数据库容器并进行恢复，从而实现数据库系统的高可用运行。
容器化部署可以提高数据库系统的灵活性和部署效率。
4.云数据库服务：将数据库系统部署在云平台上，由云服务提供商负责数据的备份、灾备和恢复，用户只需关注数据库的正常使用，大大减少了数据库容灾的工作量和风险。
数据库容灾解决方案
数据同步采用如下策略：
-同步方式：基于数据库日志的数据复制技术，确保数据实时同步。
-同步频率：根据业务特性和数据变化情况，合理设置同步频率，实现数据的一致性。
-同步方向：单向同步，从主数据库向备用数据库传输数据变化。
-同步策略：结合全量同步和增量同步，保障数据的一致性和完整性。
3.容灾切换
2.容灾软件
选用专业可靠的容灾软件，如Symantec Veritas、Dell EMC等，实现数据同步和容灾备，如交换机、路由器等，保证数据传输的稳定性和安全性。
五、实施步骤
1.需求分析：深入了解企业业务特性，评估数据库容灾需求，制定合理的容灾方案。
2.系统设计：根据需求分析结果，设计数据库容灾架构，包括硬件、软件、网络等资源配置。
本方案旨在为企业提供一套合法合规的数据库容灾解决方案，确保数据库的高可用性和数据安全性。在实际应用中，企业需根据自身业务特点和需求，灵活调整和优化方案，以实现最佳效果。
第2篇
数据库容灾解决方案
一、引言
在信息化时代背景下，数据库作为企业关键信息资产的核心载体，其稳定性和安全性对企业的运营至关重要。为了确保数据库在面对各类灾害时仍能保持业务的连续性和数据的完整性，本方案提出了一套全面、专业的数据库容灾解决方案。以下内容将详细阐述容灾策略、技术选型、实施步骤及后期维护等关键环节。
二、目标
1.实现数据库的高可用性，确保在主数据库发生故障时，能够在规定时间内切换至备用数据库，保证业务的连续性。
2.确保数据的完整性、一致性和安全性，防止数据丢失和损坏。
3.降低数据库故障带来的经济损失，提高企业的抗风险能力。
三、方案设计
1.容灾架构设计
本方案采用主-备容灾架构，主要包括以下部分：
数据库容灾解决方案
数据库容灾解决方案1. 简介数据库是现代应用程序中至关重要的组成部分之一。
对于大多数企业而言，数据库的中断或数据丢失都可能带来严重的灾难性后果。
数据库容灾解决方案旨在保证数据库系统的高可用性和数据持久性，以应对各种故障和灾难。
本文将介绍一些常见的数据库容灾解决方案，以及它们的特点、优缺点和适用场景。
希望通过本文的介绍，读者能够在选择数据库容灾解决方案时做出明智的决策。
2. 数据库备份和恢复数据库备份和恢复是一种基本的容灾解决方案。
它通过定期备份数据库，并在发生故障时使用备份数据进行恢复，以保证数据的完整性和可用性。
2.1 特点•简单易用：备份和恢复操作相对简单，不需要复杂的配置和管理。
•低成本：备份和恢复所需的硬件、软件和人力成本相对较低。
•可恢复性高：根据备份的频率和保留时间，可以恢复到不同的时间点。
2.2 优点•易于实施：备份和恢复操作相对简单，适合小规模和简单的数据库系统。
•低成本：备份和恢复所需的硬件、软件和人力成本相对较低。
•快速恢复：在发生故障时，可以迅速使用备份数据进行恢复。
2.3 缺点•数据丢失：备份的频率决定了可恢复的数据范围，可能会丢失最近的数据。
•恢复时间较长：在数据库较大或数据量较多的情况下，恢复时间可能较长，导致业务中断时间加长。
•人为操作风险：由于备份和恢复操作需要人工操作，可能存在错误或遗漏的风险。
2.4 适用场景•小型企业或个人用户，对数据可用性要求不高。
•数据库规模较小，业务中断时间可以承受一定的延迟。
•数据变更频率较低，可以接受一定程度的数据丢失。
3. 数据库主从复制数据库主从复制是一种常见的容灾解决方案。
它通过在主数据库上进行写操作后，自动将数据复制到一个或多个从数据库上，从而实现数据的备份和故障转移。
3.1 特点•实时性高：主数据库上的数据变更会即时同步到从数据库上。
•故障转移快速：当主数据库发生故障时，从数据库可以快速接管数据库服务。
3.2 优点•数据实时备份：从数据库上的数据与主数据库保持一致，可以减少数据丢失风险。
数据库容灾解决方案
数据库容灾解决方案数据库在现代企业中扮演着重要的角色，对于数据的可靠性和安全性要求越来越高。
然而，由于各种原因，例如硬件故障、自然灾害、人为错误等，数据库可能会遭受数据丢失或不可用的风险。
为了应对这些风险，数据库容灾解决方案变得至关重要。
本文将探讨几种常见的数据库容灾解决方案，并分析它们的优缺点。
一、主备复制主备复制是一种常见的数据库容灾解决方案。
它的原理是通过将数据库数据从主服务器复制到备份服务器，实现数据的冗余存储和备份。
当主服务器发生故障时，备份服务器可以快速切换为主服务器，从而保证数据的可用性和连续性。
优点：主备复制方案实施简单，成本相对较低。
备份服务器可以处于热备状态，即时响应故障，提高恢复速度。
缺点：主备复制方案不可避免地存在数据同步延迟问题，因为数据是通过网络传输进行复制的，可能会出现部分丢失的情况。
此外，备份服务器处于待命状态，资源利用率相对较低。
二、数据库镜像数据库镜像是一种高可用性和容灾解决方案，它通过将数据库实例实时复制到多个服务器上来实现数据的冗余存储。
当主服务器发生故障时，镜像服务器可以立即接管主服务器的工作，确保业务的连续性。
优点：数据库镜像方案具有较低的数据同步延迟和较高的数据可用性。
它可以实现实时数据同步，保证数据的完整性和一致性。
另外，镜像服务器可以承担部分主服务器的工作负载，提高资源利用率。
缺点：数据库镜像方案需要较高的硬件和网络设备，成本较高。
镜像服务器需要实时监控主服务器的状态，对系统资源要求较高。
三、数据库集群数据库集群是一种高可用性和高容灾性的解决方案。
它通过将数据库分布在多个服务器上，实现数据的冗余存储和负载均衡。
当某个节点发生故障时，其他节点可以接管工作，确保业务的连续性。
优点：数据库集群方案具有较低的数据同步延迟和较高的数据可用性。
它可以实现实时数据同步，并且具有较高的扩展性，可以随着业务的增长进行水平扩展。
缺点：数据库集群方案实施较为复杂，需要考虑节点之间的同步和通信问题。
数据库容灾、复制解决方案全分析
数据库容灾、复制解决方案全分析引言：数据库是现代企业信息系统的核心组成部分，对数据库的高可用性和容灾备份需求越来越高。
为了保证数据库的稳定运行，数据库容灾和复制解决方案成为重要的技术手段。
本文将对数据库容灾和复制解决方案进行全面分析，包括常见的容灾方案、复制方案及其优缺点。
一、容灾方案1.1 磁盘镜像磁盘镜像是一种常见的数据库容灾方案，它通过将主数据库的数据实时复制到备份数据库的方式来实现容灾。
具体实现方式包括硬件磁盘阵列镜像和软件磁盘镜像。
1.2 数据库备份与恢复数据库备份与恢复是一种常用的容灾方案，它通过定期备份数据库的数据和日志文件，并在主数据库故障时将备份文件恢复到备份数据库中，实现数据库的容灾。
1.3 数据库冷备份数据库冷备份是一种简单高效的容灾方案，它通过停止主数据库的服务，将数据库文件拷贝到备份服务器，并在备份服务器上启动数据库服务，实现容灾。
二、复制方案2.1 主从复制主从复制是一种常见的数据库复制方案，它通过将主数据库的数据实时复制到一个或多个从数据库中，实现数据的冗余备份和读写分离。
主从复制的优点包括数据实时同步、读写分离、扩展性好等。
2.2 多主复制多主复制是一种高可用的数据库复制方案，它通过多个主数据库之间的数据同步，实现数据的冗余备份和高可用性。
多主复制的优点包括数据实时同步、高可用性、负载均衡等。
2.3 分布式复制分布式复制是一种可扩展的数据库复制方案，它通过将数据分布到多个节点上，实现数据的冗余备份和横向扩展。
分布式复制的优点包括数据分散存储、高可用性、扩展性好等。
三、容灾与复制方案的优缺点比较3.1 容灾方案的比较磁盘镜像的优点是实时复制、容灾快速，但成本较高；数据库备份与恢复的优点是简单易用、成本低，但容灾时间较长；数据库冷备份的优点是简单高效，但容灾时间较长。
3.2 复制方案的比较主从复制的优点是数据实时同步、读写分离，但容灾时间较长；多主复制的优点是高可用性、负载均衡，但配置复杂；分布式复制的优点是数据分散存储、扩展性好，但实现复杂。
数据库容灾解决方案
数据库容灾解决方案数据库容灾，是指为了保证数据的可用性和可靠性，在系统遇到灾难性故障时能够快速恢复并继续提供服务的一种解决方案。
它是现代信息系统中非常重要的一环，对于保障系统的稳定运行和数据的安全至关重要。
本文将介绍数据库容灾的常见解决方案。
一、备份与恢复备份与恢复是最基本、最常见的数据库容灾解决方案。
它通过定期将数据库的数据和日志文件备份到独立的存储介质上，以便在系统发生故障时能够从备份中恢复数据。
备份与恢复的流程一般包括以下几个步骤：首先，需要制定备份策略，确定备份的时间点和备份频率；其次，进行数据备份，将数据库的数据和日志文件复制到备份介质中；最后，当数据库发生故障时，可以通过恢复过程将备份中的数据恢复到正常的运行环境中。
备份与恢复的优点是简单、易于实施，而且成本相对较低。
然而，其缺点是备份数据和实时数据之间存在一定的时间差，如果系统在备份之后出现故障，可能会造成一部分数据的丢失。
二、数据库复制数据库复制是一种常用的数据库容灾解决方案，它通过将主数据库的数据同步复制到多个备份数据库中，以保证数据的可用性和可靠性。
数据库复制的原理是通过事先定义的复制规则，将主数据库上的更新操作自动同步到备份数据库中。
当主数据库发生故障时，可以切换到备份数据库继续提供服务，从而实现快速恢复。
数据库复制的优点是数据实时同步，可以做到较小的数据丢失，而且在切换过程中对用户没有明显的中断。
然而，数据库复制需要占用更多的网络带宽和存储空间，并且对数据库的性能会产生一定的影响。
三、集群与负载均衡数据库集群与负载均衡是一种高可用性的容灾解决方案。
它通过将多个数据库服务器组成集群，实现数据的自动分布和负载均衡，从而提高系统的可用性和性能。
数据库集群的原理是将数据划分为多个片段，每个数据库服务器负责管理其中的一部分数据。
当某个服务器发生故障时，其他服务器会自动接管其工作，保证系统的正常运行。
数据库集群的优点是高可用性、高性能和可扩展性。
数据库容灾与灾备的解决方案
数据库容灾与灾备的解决方案对于企业来说，数据库是一个至关重要的组成部分，存储着公司的所有关键数据和信息。
但是如果数据库发生灾难，如硬件故障、自然灾害或人为错误，可能会导致数据丢失、服务中断和业务崩溃等严重后果。
因此，数据库容灾与灾备的解决方案变得非常关键，有助于保护数据的安全性和完整性，同时确保业务连续性。
一、容灾与灾备的概念容灾（Disaster Recovery，简称DR）是指在灾难发生后，通过采取一系列的措施来减轻灾难的影响，尽快恢复业务运行，确保系统和数据的完整性。
灾备（Business Continuity，简称BC），则是指在灾难发生后，为了保证业务的连续运行而采取的一系列措施，包括预防、应对和恢复等方面的策略。
二、灾备与容灾的关系与区别灾备是一个更广泛概念，包括了容灾在内。
容灾是灾备的一部分，主要侧重于处理系统和数据的恢复。
而灾备则更注重确保业务的连续性，包括对业务流程的规划、设备备份、数据保护、备份恢复等方面。
三、数据库容灾与灾备的解决方案1. 数据备份与恢复备份是灾备和容灾的基础，通过定期进行数据库的备份，可以避免数据的丢失。
可以采用完整备份、增量备份或差异备份等备份策略，根据业务需求灵活调整备份频率。
同时，还需要测试恢复流程，确保备份数据的可用性和可恢复性。
2. 冗余部署与负载均衡为了提高系统的稳定性和可用性，可以采用冗余部署，即在不同的地理位置或数据中心部署多个数据库服务器。
通过负载均衡技术，将流量均匀分发到多个服务器上，避免单点故障，提高系统的性能和容错能力。
3. 主备复制与同步通过主备复制技术，将主数据库的数据实时复制到备份数据库上。
这样，在主数据库发生故障时，备份数据库可以快速切换为主数据库，并继续提供服务。
同时，通过同步机制保证数据的一致性，确保备份数据库与主数据库的数据同步。
4. 容器化与虚拟化数据库容器化和虚拟化技术可以提高数据库系统的灵活性和可迁移性。
通过将数据库容器化，可以更方便地进行部署和扩展，同时降低系统的维护成本。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
数据库容灾、复制解决方案全分析（绝对精品）目前，针对oracle数据库的远程复制、容灾主要有以下几种技术或解决方案：（1）基于存储层的容灾复制方案这种技术的复制机制是通过基于SAN的存储局域网进行复制，复制针对每个IO进行，复制的数据量比较大;系统可以实现数据的同步或异步两种方式的复制.对大数据量的系统来说有很大的优势（每天日志量在60G以上）,但是对主机、操作系统、数据库版本等要求一致，且对络环境的要求比较高。
目标系统不需要有主机，只要有存储设备就可以，如果需要目标系统可读，需要额外的配置和设备，比较麻烦。
（2）基于逻辑卷的容灾复制方案这种技术的机制是通过基于TCP/IP的网络环境进行复制，由操作系统进程捕捉逻辑卷的变化进行复制。
其特点与基于存储设备的复制方案比较类似，也可以选择同步或异步两种方式，对主机的软、硬件环境的一致性要求也比较高，对大数据量的应用比较有优势。
其目标系统如果要实现可读，需要创建第三方镜像。
个人认为这种技术和上面提到的基于存储的复制技术比较适合于超大数据量的系统，或者是应用系统的容灾复制。
我一直有一个困惑，存储级的复制，假如是同步的，能保证数据库所有文件一致吗？或者说是保证在异常发生的那一刻有足够的缓冲来保障？也就是说，复制的时候起文件写入顺序和oracle的顺序一致吗？如果不一致就可能有问题，那么是通过什么机制来实现的呢？上次一个存储厂商来讲产品，我问技术工程师这个问题，没有能给出答案我对存储级的复制没有深入的研究过，主要是我自己的一些理解，你们帮我看一下吧……我觉得基于存储的复制应该是捕捉原系统存储上的每一个变化，而不是每隔一段时间去复制一下原系统存储上文件内容的改变结果，所以在任意时刻，如果原系统的文件是一致的，那么目标端也应该是一致的，如果原系统没有一致，那目标端也会一样的。
形象一点说它的原理可能有点像raid 0，就是说它的写入顺序应该和原系统是一样的。
不知道我的理解对不对。
另外，在发生故障的那一刻，如果是类似断电的情况，那么肯定会有缓存中数据的损失，也不能100%保证数据文件的一致。
一般来说是用这种方式做oracle的容灾备份，在发生灾难以后目标系统的数据库一般是只有2/3的机会是可以正常启动的（这是我接触过的很多这方面的技术人员的一种说法，我没有实际测试过）。
我在一个移动运营商那里看到过实际的情况，他们的数据库没有归档，虽然使用了存储级的备份，但是白天却是不做同步的，只有在晚上再将存储同步，到第二天早上，再把存储的同步断掉，然后由另外一台主机来启动目标端存储上的数据库，而且基本上是有1/3的机会目标端数据库是起不来的，需要重新同步。
所以我觉得如果不是数据量大的惊人，其他方式没办法做到同步，或者要同时对数据库和应用进行容灾，存储级的方案是没有什么优势的，尤其是它对网络的环境要求是非常高的，在异地环境中几乎不可能实现。
不知道我的理解对不对，也不知道是不是回答了你的问题，呵呵。
欢迎指正！应该说部分地回答了我的问题，呵呵因为实际上存储设备的写入顺序和oracle 的进程的写入顺序肯定是不一样的，存储设备一定是做过重整的，那不管同步或者异步的拷贝都有可能存在问题的。
所以我一直对这个方案的可靠性不敢完全相信，这样一来，倒不如data guard 可靠了因为很明显，存储设备拷贝过去的数据文件不一致是有很大的概率的你的意思是说即使不考虑目标端，仅在源端的情况下，存储设备的写入顺序也是和Oracle不一致的？这应该是一个原因。
我觉得还有一种可能性就是在忽略存储设备的这种情况下，在主系统当机，发生切换的时候，主系统存储上的数据文件也不一定能保证一致，就算目标系统保持了完全的同步，也一样不能保正目标端数据可可以启动。
不太理解，为什么说存储设备的写入顺序会和oracle进程的写入顺序不一致阿如果说仅在源端情况下，存储设备的写入顺序也是和Oracle进程不一致，那么不考虑异地冗灾，那么是不是意味着即使本地服务器crash，也无法启动存储上的数据文件？我也有这个疑问，以前一直觉得仅考虑主系统的情况下，存储设备的写入顺序应该是和数据库的写入顺序一致的，但我觉得biti_rainy的理解也是有道理的，存储设备毕竟和一般的磁盘不一样，很可能再写入的时候会作重新的组合，不过不知道具体的证据是什么啊？按照这种理解，再写入的某一瞬间，数据库的写入顺序和存储的写入顺序可能是不一致的，但既然存储写入的结果跟oracle的写入结果肯定是一致的，那么我们可以把一个比较长的写入过程分成若干个时间段，在每个时间段的结尾，oracle和存储设备的写入结果都是完全一致的，那么这个时间段的大小是多少呢？呵呵，说得我自己都快晕了，也不知道大家明白我的意思没有……biti_rainy能不能给我们解释一下啊？或者论坛里有没有对存储设备比较了解的兄弟啊？系统上通常不一致没关系是因为还有logfile 的存在，而日志文件通常是被写入了磁盘的，oracle本身是顺序写的，还不需要读，应该是被重整的几率比较小还有存储设备上，比如掉电没关系，是因为存储设备都有足够的短时间供电能力使得cache 中的数据能被写入磁盘，这个如果不能保证那一掉电基本都要出问题的但是在复制的那端，我就不清楚是怎么处理的，比如我要停掉复制，开始用起这数据来，或者说设备掉电了，这个时候是怎么处理的在复制的那端，我感觉是没有经过特殊处理的，因为存储设备完全是物理上的同步，在你停掉复制的时候，他最多只能保证在停止复制或原系统掉电的这一刻所有文件在物理上是和原系统的存储是完全一致的，但他绝对不会去校验或保证oracle的数据文件在逻辑上是否一致，所以会造成复制端在停止复制后有很大几率不能正常启动。
我在客户那的情况就是在原系统正常运行的情况下，停止存储的复制，然后启动目标端数据库，但还是有1/3的几率无法启动，如果是在原系统发生故障或断电的情况下，估计就更不好说了。
我还是比较佩服那个客户的勇气，一个省级移动运营商的数据中心，数据库连归档都没有，一旦系统崩溃，至少要损失当天的数据，同时容灾端的数据库能不能起来还是个问题……还好目前还没有出问题，要是出了问题，不知道他们会怎么办……上次做存储设备的来公司，谈到这个问题的时候说：很多客户就是这么做的我就说：很多人这么做的并不能说就没问题，因为很多人没有出现事故，是因为隐藏的问题没有机会暴露出来。
我需要：1：机制上的可靠保障，这个可能只有非常理解原理的人能回答2：实际系统的测试，要经过在我们自己提供的数据场景下反复测试通过这两点之后我们才敢放心使用同意，确实很多人都是这么用的，也确实都很可能出现问题，所以我一直以为基于存储的数据库容灾方案是有问题的，但在有些环境中好像还只能这么做，例如我们的一个客户，也是一个省级的移动运营商，其数据库每天的日志量达到100G以上，在这种条件下，好像只有这种解决方案比较可行，其他的都会有一些问题，至少那些使用软件实现的逻辑复制方案是不行的，我感觉oracle自己的standby好像也负担不了吧？不过他们的数据库至少还是归档的，还有一点保证。
呵呵。
从ORACLE的角度来衡量基于存储的容灾肯定是有问题的，不可能做到100%可用。
即使是ORACLE的DATA GUARD也不能保证100%没有数据丢失（当前日志组的数据）。
换个思路了，使用基于应用的同步方案吧。
（3）基于oracle redo log的逻辑复制方式使用这种方式的主要有一些第三方的软件，以及oracle自己的DATAGUARD 中的logical Standby。
先介绍一下第三方的软件产品吧……目前，国外已经有了很多比较成熟的产品及成功案例，国内也有类似的产品，但在产品的成熟程度和成功案例上跟国外还有一定的差距。
这类产品的原理基本相同，其工作过程可以分为以下几个流程：使用oracle以外的独立进程，捕捉redo log file 的信息，将其翻译成sql语句，再通过网络传输到目标端数据库，在目标端数据库执行同样的sql。
如果其进程赶不上oracle日志切换，也可以捕捉归档日志中的内容。
也有的产品在源端以事务为单位，当一个事务完成后，再把它传输到目标端。
所有的产品一般都是以表为单位进行复制，同时也支持大部分DDL的复制（主要在oracle9i环境中）。
这种技术的技术特点和优势主要有以下几点：目标端数据库一直是一个可以访问的数据库；能保证两端数据库的事务一致性；因为使用oracle以外的进程进行捕捉，且其优先级低于oracle进程，所以对源系统数据库的性能影响很小；基于其实现原理及多个队列文件的使用，复制环境可以提供网络失败、数据库失败、主机失败的容错能力；因为这类软件复制的只是sql语句或事务，所以他可以完全支持异构环境的复制，硬件的型号，oracle的版本，操作系统的种类、版本等都没有要求。
这种方式还可以支持多种复制方式，比如数据集中、分发、对等复制、或者多层测的复制等。
由于传输的内容只是redolog 或archive log中的一部分，所以对网络资源的占用很小，可以实现不同城市之间的远程复制。
基于redolog的逻辑复制产品有很多的优势，但跟上面提到过的其他方案比较起来，也有一些缺点：数据库的吞吐量太大时，其实据会有较大的延迟，当数据库每天的日量达到60G或更大时，这种方案的可行性交差；实施的过程可能会有一些停机时间，来进行数据的同步和配置的激活；复制环境建立起来以后，对数据库结构上的一些修改需要按照规定的操作流程进行，有一定的维护成本。
不过目前这类产品的发展很快，上面的这些问题，在大部分产品的最新版本中都有很大的改进。
您说的备中心1/3机会不可用，是同步复制还是异步复制的情况？是指同步复制的情况。
这个数字我不敢保证它的准确性，因为我没有做过实际的实验来验证，但从我在客户那里看到的实际情况来说，基本属实。
您能告诉我你的客户用的那一家的产品吗？不管是同步环是异步只要不是在数据库里面做宕机时总应该有数据不一致的情况吧因为数据库写文件是由操作系统来最终完成的，而操作系统本身又有cache，在通过逻辑复制把数据异步或同步复制到其他存储设备上，中间无论哪个环节有问题，远程存储设备的数据都不能同现有数据保持一致，所以我认为biti的怀疑是很有道理的。
到10g oracle可以使用assm，直接同存储设备对话，这样是否能够好一些，不太确定存储是通过快照来记录状态，然后再进行复制进行备份的。
其实最好的方法应该是捕捉redo log file 的信息，将其翻译成sql语句这就是oracle stream 和quest shareplex实现的功能利用oracle 9i的高级复制，加上第三方的管理工具就可以了我对oracle 的高级复制研究较多，觉得这是最好的方法，能够完全保证数据的一致性。