下载文档原格式
数据库容灾的常用方法近年来，随着企业数据规模的不断增大和对数据可用性的要求越来越高，数据库容灾问题备受关注。
数据库容灾指的是在数据库系统发生故障或灾难情况下，能够快速、可靠地恢复数据库的可用状态，确保数据的安全性和连续性。
现针对数据库容灾常用的方法进行探讨，包括物理备份、逻辑备份、数据库复制和数据库集群。
一、物理备份物理备份指的是将数据库的物理文件复制到备份设备上，实现对整个数据库的完全复制。
它包括全量备份和增量备份两种形式。
1.全量备份：全量备份是指对数据库所有数据和日志进行备份，一般在数据库初始建立之后进行一次全量备份，以后每隔一段时间进行一次。
全量备份具有备份速度快、恢复速度相对较慢的特点。
2.增量备份：增量备份是在全量备份的基础上，备份数据库发生变动的部分数据和日志。
增量备份能够减少备份数据量和备份时间，但在恢复时需要结合全量备份和增量备份进行数据的恢复。
物理备份适用于大规模数据库和重要数据的备份，具有数据完整性高、恢复速度快的优点。
但也存在备份数据量大、恢复时对数据库的停机时间长的缺点。
二、逻辑备份逻辑备份是在逻辑层面对数据库进行备份，通常以SQL语句或数据导出方式进行。
逻辑备份不复制数据库的物理文件，而是将数据库中的数据和逻辑结构导出为可读的脚本或文件。
逻辑备份具有跨平台的优势，可以实现不同数据库之间的数据迁移和转换。
同时，逻辑备份也方便对数据库中的数据进行选择性恢复和数据导入。
但相比于物理备份，逻辑备份速度较慢，备份文件较大，对数据库的负载较高。
三、数据库复制数据库复制是将主数据库的数据和操作同步到备份服务器的过程。
它是通过将主数据库的事务日志复制到备份服务器并在备份服务器上执行，从而实现主备数据库的同步。
数据库复制具有实时性好、恢复速度快的优点，能够提供几乎无延迟的备份和灾难恢复能力。
常见的数据库复制方法包括MySQL的主从复制、Oracle的Data Guard和SQL Server的数据库镜像。
数据中心容灾方案一、容灾的重要性。
你想啊，数据中心就像是一个超级大脑，里面存着各种各样重要的东西，要是这个大脑突然出问题了，那可就乱套了。
比如说公司的财务数据、客户信息、重要的业务文档啥的，一旦没了或者损坏了，就像一个人突然失忆了一样，公司可能就会陷入大麻烦。
所以啊，容灾方案就像是给这个超级大脑买的一份保险，关键时刻能救命呢！二、容灾方案的类型。
1. 本地备份。
这就好比是在家里多准备了几个存钱罐。
我们可以在数据中心内部设置额外的存储设备，定期把重要数据备份到这些设备上。
比如说每天晚上，大家都下班了，数据中心就开始自动把当天新产生的数据和修改过的数据备份到本地的另一块大硬盘或者存储阵列里。
这样的话，如果主存储设备突然抽风了，比如说某个硬盘突然坏了，我们还能从本地备份里把数据找回来，就像从存钱罐里拿备用的钱一样方便。
2. 异地容灾。
这个可就更厉害了，就像是在另一个城市给公司又开了一个小办公室，专门用来放重要东西的副本。
我们在离主数据中心比较远的地方再建一个数据中心，这个距离要足够远哦，比如说几百公里以外。
这样即使主数据中心所在的地方发生了自然灾害，像地震啦、洪水啦，异地的数据中心还能安然无恙。
然后通过网络把主数据中心的数据实时或者定时地同步到异地数据中心。
这就像是你在两个地方都有一模一样的宝贝，不管哪个地方出问题了，另一个地方都能顶上。
三、容灾方案的具体实施。
1. 硬件设备选择。
对于本地备份来说，我们得挑个靠谱的存储设备。
不能太抠门，得选那种质量好、容量大的硬盘或者存储阵列。
比如说，要是公司数据量很大，就不能选那种小容量的普通硬盘，得选企业级的大容量硬盘，像那种能装下好多好多电影（当然我们存的是数据啦，打个比方）的硬盘。
对于异地容灾的数据中心硬件，那更是要高标准严要求，服务器、网络设备都得是质量杠杠的，因为它可是要在关键时刻挑大梁的呢。
2. 网络连接。
异地容灾的话，网络连接可太重要了。
这就像是两座城市之间的高速公路，要保证数据能快速、稳定地在主数据中心和异地数据中心之间传输。
金融数据中心容灾解决方案在当今数字化的金融时代，数据已成为金融机构的核心资产。
金融数据中心作为存储和处理这些关键数据的枢纽，其稳定性和可靠性至关重要。
一旦数据中心遭遇灾难，如自然灾害、硬件故障、网络攻击或人为错误等，可能导致业务中断、数据丢失，进而给金融机构带来巨大的经济损失和声誉损害。
因此，构建一套有效的容灾解决方案是金融机构保障业务连续性的关键举措。
一、容灾的重要性金融行业的特点决定了其对数据的高度依赖和对业务连续性的严格要求。
金融交易需要实时处理，客户信息必须准确无误地保存，任何数据的丢失或业务的中断都可能引发信任危机，导致客户流失，甚至面临监管处罚。
例如，银行系统的瘫痪可能导致客户无法进行存取款、转账等操作；证券交易所的数据丢失可能影响交易的准确性和公正性，引发市场混乱。
二、容灾解决方案的类型（一）数据备份与恢复这是最基础的容灾手段。
通过定期将数据备份到磁带、磁盘或云端等存储介质中，当主数据中心发生故障时，可以利用备份数据进行恢复。
但需要注意备份的频率和完整性，以及恢复的时间和效率。
（二）异地容灾在地理位置上远离主数据中心的地方建立备份数据中心。
当主数据中心遭受灾难无法正常运行时，业务可以迅速切换到异地数据中心，保证业务的连续性。
异地容灾需要考虑数据同步的实时性、网络带宽和延迟等因素。
（三）双活数据中心主数据中心和备份数据中心同时运行，共同承担业务负载。
这种方式可以提高资源利用率，减少业务切换的时间，但技术实现难度较大，需要保证两个数据中心之间的数据一致性和业务的无缝切换。
（四）云容灾利用云计算服务提供商的基础设施和技术，将数据备份到云端或在云端建立容灾环境。
云容灾具有灵活扩展、成本较低等优点，但需要关注数据安全和合规性问题。
三、容灾解决方案的实施步骤（一）风险评估首先，对金融数据中心可能面临的风险进行全面评估，包括自然灾害、人为因素、技术故障等。
了解每种风险发生的可能性和可能造成的影响，为后续的容灾规划提供依据。
数据库异地容灾的最佳实践与问题分析一、引言数据库是现代企业中至关重要的数据存储和管理工具。
然而，由于自然灾害、硬件故障、人为错误等风险的存在，数据库面临着数据丢失的风险。
为了避免数据的损失，数据库异地容灾备份已经成为数据库管理中必不可少的一环。
本文将探讨数据库异地容灾的最佳实践，并分析在实施过程中可能面临的问题。
二、数据库异地容灾的最佳实践1. 数据库备份与恢复策略为确保数据库的可靠性和数据的完整性，数据库异地容灾应采用定期备份和恢复的策略。
定期进行全量备份和增量备份可以最大程度减少数据丢失的风险。
备份数据应存储在远离源数据的地理位置，以防止同一地区灾害对数据的影响。
2. 异地复制和同步策略通过异地复制和同步策略，可以实现对数据库的实时复制和同步。
在出现灾难时，可以迅速切换到备份的数据库中，确保业务流程的连续性。
异地复制和同步策略还可以提供数据的高可用性和快速恢复能力。
3. 监控和自动化管理通过实时监控数据库的运行状态，可以及时发现潜在的问题并采取相应的措施。
自动化管理可以减少人为错误的风险，并提高数据库的稳定性和可靠性。
监控和自动化管理的结合可以大大提升数据库异地容灾的效果。
4. 安全策略和访问控制在数据库异地容灾中，安全策略和访问控制是至关重要的。
合理的访问控制可以防止未经授权的访问和数据泄露。
加密和身份验证技术可以提供数据库的安全性。
此外，定期进行安全审计也是必不可少的。
三、数据库异地容灾可能面临的问题1. 数据一致性的问题数据库异地容灾涉及到多地的数据复制和同步，因此可能面临数据一致性的问题。
当主数据库和备份数据库之间的同步出现延迟或错误时，可能导致数据的不一致性。
解决这个问题的方法包括增量备份的频率增加、加快数据同步速度等。
2. 网络传输过程中的延迟和故障在数据库异地容灾中，主数据库和备份数据库之间通过网络进行数据复制和同步。
然而，网络传输过程中可能会出现延迟和故障，导致数据同步受阻。
智慧城市数据中心容灾解决方案在当今数字化快速发展的时代，智慧城市的建设已成为城市发展的重要趋势。
而智慧城市的核心支撑——数据中心，其稳定运行和数据安全至关重要。
一旦数据中心遭遇灾难，如火灾、水灾、电力故障、网络攻击等，可能导致城市的各项关键服务瘫痪，给居民生活和城市运行带来极大的困扰和损失。
因此，构建一套有效的智慧城市数据中心容灾解决方案是保障城市可持续发展的关键。
一、智慧城市数据中心面临的灾难风险1、自然灾害地震、洪水、飓风等自然灾害可能直接损坏数据中心的物理设施，导致电力中断、网络中断和设备损坏。
2、人为灾害火灾、爆炸、恐怖袭击等人为灾害也会对数据中心造成毁灭性的影响。
3、技术故障硬件故障、软件错误、系统崩溃等技术问题可能导致数据丢失或服务中断。
4、网络攻击黑客攻击、病毒感染、数据泄露等网络安全威胁日益严重，可能使数据中心陷入瘫痪。
二、容灾解决方案的目标和原则1、目标确保在发生灾难时，数据中心能够迅速恢复关键业务的运行，减少数据丢失和业务中断的时间，保障城市服务的连续性。
2、原则（1）全面性：考虑到各种可能的灾难场景，制定综合性的应对策略。
（2）及时性：在最短的时间内恢复业务运行，减少损失。
（3）可靠性：容灾方案要经过充分的测试和验证，确保其在关键时刻能够可靠运行。
（4）经济性：在满足容灾需求的前提下，控制成本，提高资源利用率。
三、容灾解决方案的技术手段1、数据备份与恢复（1）定期进行全量和增量数据备份，将数据存储在异地的备份设施中。
（2）采用磁带、磁盘、云端等多种备份介质，提高备份的灵活性和可靠性。
（3）建立快速的数据恢复机制，确保在灾难发生后能够迅速恢复数据。
2、冗余设计（1）网络冗余：构建多条网络链路，采用冗余的路由器和交换机，确保网络的可靠性。
（2）电力冗余：配备多路市电接入、UPS（不间断电源）和备用发电机，保证电力供应的连续性。
（3）服务器冗余：采用集群技术、负载均衡等手段，确保服务器的高可用性。
数据库容灾与备份方案的实施与验证分析随着信息化的发展，数据库已经成为企业数据存储和管理的关键组成部分。
然而，数据库系统的稳定性和安全性对于企业的正常运营至关重要。
为了应对各种意外情况，保障数据库系统的可用性和数据的完整性，实施有效的容灾与备份方案是必不可少的。
一、容灾方案的实施与验证容灾是指在灾难发生时能够迅速将系统的关键部分切换到备份系统，从而保障业务的正常运行。
下面将就容灾方案的实施与验证进行详细分析。
1. 实施容灾方案的步骤（1）需求分析：根据企业的业务需求和数据库规模，确定容灾方案的基本要求，包括容灾目标、容灾系统容量和容灾时间等。
（2）选取容灾方案：根据需求分析结果，评估各种容灾方案的适用性和可行性。
常见的容灾方案包括备份数据中心、异地灾备、冷备份等。
（3）规划网络架构：对应灾备系统与主系统之间的网络架构进行规划，确保数据传输的安全性和稳定性。
（4）部署容灾系统：依据选取的容灾方案，对备份服务器、备份存储设备等进行部署和配置。
（5）数据同步与备份：通过实时数据同步或定时备份的方式，将主系统中的数据同步到灾备系统中，确保数据的一致性。
（6）容灾系统的监控与管理：建立灾备系统的监控系统，及时发现和解决潜在问题，保障容灾系统的正常运行。
2. 容灾方案验证的方法和步骤（1）制定容灾验证测试计划：明确验证测试的内容、测试环境和周期，制定详细的测试方案和指导。
（2）实际测试：根据容灾验证测试计划，进行容灾方案的测试，验证系统能否在灾难发生时按预期进行数据切换和恢复。
（3）问题反馈与改进：根据测试结果，及时反馈测试过程中的问题，并进行改进和调整，确保容灾方案的有效性和可靠性。
（4）定期演练和更新：定期进行容灾演练，检验容灾方案的可行性和实用性，同时及时更新方案中的相关参数和配置。
二、备份方案的实施与验证备份是指将整个数据库或者部分关键数据复制到安全的存储介质中，以防止数据丢失或损坏。
下面将就备份方案的实施与验证进行详细分析。
数据库容灾解决方案数据库在现代企业中扮演着重要的角色，对于数据的可靠性和安全性要求越来越高。
然而，由于各种原因，例如硬件故障、自然灾害、人为错误等，数据库可能会遭受数据丢失或不可用的风险。
为了应对这些风险，数据库容灾解决方案变得至关重要。
本文将探讨几种常见的数据库容灾解决方案，并分析它们的优缺点。
一、主备复制主备复制是一种常见的数据库容灾解决方案。
它的原理是通过将数据库数据从主服务器复制到备份服务器，实现数据的冗余存储和备份。
当主服务器发生故障时，备份服务器可以快速切换为主服务器，从而保证数据的可用性和连续性。
优点：主备复制方案实施简单，成本相对较低。
备份服务器可以处于热备状态，即时响应故障，提高恢复速度。
缺点：主备复制方案不可避免地存在数据同步延迟问题，因为数据是通过网络传输进行复制的，可能会出现部分丢失的情况。
此外，备份服务器处于待命状态，资源利用率相对较低。
二、数据库镜像数据库镜像是一种高可用性和容灾解决方案，它通过将数据库实例实时复制到多个服务器上来实现数据的冗余存储。
当主服务器发生故障时，镜像服务器可以立即接管主服务器的工作，确保业务的连续性。
优点：数据库镜像方案具有较低的数据同步延迟和较高的数据可用性。
它可以实现实时数据同步，保证数据的完整性和一致性。
另外，镜像服务器可以承担部分主服务器的工作负载，提高资源利用率。
缺点：数据库镜像方案需要较高的硬件和网络设备，成本较高。
镜像服务器需要实时监控主服务器的状态，对系统资源要求较高。
三、数据库集群数据库集群是一种高可用性和高容灾性的解决方案。
它通过将数据库分布在多个服务器上，实现数据的冗余存储和负载均衡。
当某个节点发生故障时，其他节点可以接管工作，确保业务的连续性。
优点：数据库集群方案具有较低的数据同步延迟和较高的数据可用性。
它可以实现实时数据同步，并且具有较高的扩展性，可以随着业务的增长进行水平扩展。
缺点：数据库集群方案实施较为复杂，需要考虑节点之间的同步和通信问题。
数据库容灾与灾备方案设计随着信息化水平的不断提高，数据库在企业中扮演着越来越重要的角色。
然而，数据库也面临着各种潜在的风险，例如自然灾害、硬件故障、人为错误等，这些风险可能导致数据库服务不可用，进而影响企业的正常运营。
为了应对这些风险，数据库容灾与灾备方案设计显得尤为重要。
一、容灾与灾备的基本概念容灾（Disaster Recovery，简称DR）是指在数据库发生意外灾害后，能够尽快地恢复数据库服务，确保数据的完整性和可用性。
而灾备（Business Continuity Plan，简称BCP）则是指在数据库发生灾害后，能够继续提供服务，并在短时间内恢复到灾害前的正常运行状态。
二、灾备方案设计的要点1. 单机灾备方案单机灾备方案是灾备的基础，它包括备份与恢复策略、数据冗余和备份介质的选择。
首先，需要制定完善的备份策略，包括全量备份和增量备份，以保证数据的可靠性和恢复速度。
其次，数据冗余技术是确保数据的持久性和可用性的关键，可以采用镜像技术或者RAID存储技术。
最后，备份介质的选择也是非常重要的，可以选择磁带备份、云备份或者硬盘备份等。
2. 异地备份方案为了进一步提高数据库的容灾能力，可以选择异地备份方案。
异地备份是指将数据库的备份数据存储在离主数据库较远的地方，以防止单一地域的灾害对数据库造成影响。
可以选择跨城市、跨区域的数据中心进行备份，或者采用云备份等方式。
同时，需要保证异地备份的数据安全性，可以采用数据加密等技术。
三、容灾与灾备方案的测试与优化容灾与灾备方案设计完成后，需要进行测试以验证其可行性和有效性。
可以进行模拟灾难恢复测试，例如关闭主数据库，切换到备份数据库进行运行，检查整个恢复过程的时间、数据完整性和可用性。
测试结果将指导优化方案，例如缩短恢复时间、提高数据备份的频率等。
四、应对特定灾害的方案设计不同的灾害风险需要采取不同的应对措施，例如自然灾害、网络攻击和硬件故障。
针对自然灾害，可以选择多个异地备份点，避免单一灾害点的影响。
数据库容灾方案随着企业业务的数字化和数据的快速增长，数据库成为了企业信息系统中不可或缺的重要组成部分。
为了保证业务的连续性和数据的安全性，企业需要采取一系列的容灾方案来应对可能发生的灾难性情况，例如硬件故障、自然灾害或人为错误等。
本文将介绍几种常见的数据库容灾方案。
一、本地备份与恢复本地备份是最基本也是最常见的数据库容灾方案之一。
通过定期备份数据库的数据和日志文件，可以在系统崩溃或数据损坏时恢复数据。
备份可以使用数据库自带的工具，如Oracle的Export/Import工具，或使用第三方的备份软件。
备份的频率可以根据业务的需求和数据变化的频率而定。
此外，备份数据的存储也需要注意安全性和可靠性，可以将备份数据存储在不同地点以避免单点故障。
二、热备份和冷备份热备份和冷备份是针对关键系统而设计的高可用性数据库容灾方案。
热备份是指将实时数据同步到备份系统中，以保证数据的一致性。
常见的热备份技术有数据库复制和数据库集群。
数据库复制将实时数据复制到备份数据库中，可以实现高可用性和读写分离。
数据库集群则是多个数据库服务器共同提供服务，一台服务器发生故障时，其他服务器自动接管服务。
冷备份是在备份系统中定期将数据和日志文件复制到备份设备中，通常需要停机维护数据库。
三、异地备份与恢复异地备份是指将备份数据存储在与生产环境隔离的地理位置，以应对区域性灾难造成的数据丢失。
常见的异地备份方案有远程复制和云备份。
远程复制可以通过网络将备份数据复制到异地服务器或存储设备中，以实现数据的异地备份和恢复。
云备份则是将备份数据存储在云平台上，具有高可用性和弹性扩展的优势。
需要注意的是，异地备份需要考虑带宽和网络延迟等因素，以确保备份和恢复的效率。
四、容灾演练与监控容灾演练和监控是数据库容灾方案的重要组成部分。
容灾演练可以定期模拟灾难场景，测试备份和恢复的过程和效果，发现和解决潜在的问题，以提高容灾的可靠性和效果。
监控数据库的运行状态和备份的完整性也是非常重要的，及时发现故障并采取相应的措施可以有效减少数据丢失和系统停机的风险。
数据库中的数据备份与容灾解决方案案例随着互联网和信息技术的快速发展，数据库成为了现代企业中重要的数据存储和管理手段。
然而，由于各种原因，数据库面临着数据丢失和系统故障等风险。
为了保障数据的安全和业务的连续性，数据库备份与容灾解决方案成为了不可或缺的一环。
本文将介绍几个数据库备份与容灾解决方案的成功案例。
案例一：阿里巴巴云数据库RDS阿里巴巴云数据库RDS（Relational Database Service）是阿里云推出的一种全托管的自服务云数据库。
RDS支持多种数据库引擎，如MySQL、SQL Server、PostgreSQL等，可提供高可用性和高可靠性的数据库服务。
在RDS中，数据备份是一个重要的环节。
RDS提供了数据备份功能，用户可以通过定时备份和手动备份两种方式对数据库进行备份。
备份数据存储在分布式存储系统中，确保了数据的安全性和可靠性。
除了数据备份，RDS还提供了容灾解决方案。
RDS的主从复制功能可以自动将主库的数据同步到备库，实现了数据的实时同步和灾备能力。
在主库宕机或故障时，系统可以自动切换到备库，保证了业务的连续性。
案例二：华为FusionSphere云平台华为FusionSphere云平台是华为推出的一种虚拟化平台，用于构建和管理云计算环境。
该平台提供了数据库备份与容灾解决方案，可以帮助企业实现数据的安全备份和灾备能力。
在FusionSphere云平台中，可以通过虚拟机备份功能对数据库进行定期备份。
备份数据存储在分布式存储系统中，保证了备份数据的安全性和可靠性。
此外，FusionSphere云平台还提供了容灾解决方案。
通过搭建主备模式和冷备模式的数据库系统，可以实现数据的持续同步和故障切换。
当主库故障时，系统会自动切换到备库，确保了业务的连续性。
案例三：腾讯云数据库TDSQL腾讯云数据库TDSQL（TencentDB for MySQL）是腾讯云推出的一种高性能、可扩展的云数据库。
数据库容灾、复制解决方案全分析（绝对精品）目前，针对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 的高级复制研究较多，觉得这是最好的方法，能够完全保证数据的一致性。
