DataGuard数据库灾难防护Word下载.docx

DataGuard数据库灾难防护Word下载.docx

《DataGuard数据库灾难防护Word下载.docx》由会员分享，可在线阅读，更多相关《DataGuard数据库灾难防护Word下载.docx（6页珍藏版）》请在冰点文库上搜索。

假如主（PrimaryDatabase）备（StandbyDatabase）之间的连接中断，Oracle会通过中断主实例的工作来防止主备数据库之间的数据的不一致，保证无数据丢失。

这种模式对数据库性能的影响较大。

Instantprotection：

与Guaranteedprotection模式不同的是当主备数据库之间的连接中断时，允许主备数据库之间的数据的不一致，并当恢复连接后，解决数据不一致的现象。

这种模式对主数据库的性能有较小的影响。

Rapidprotection：

主数据库的修改快速应用在备用数据库上。

会出现数据丢失，但对数据库性能的影响小。

Delayedprotection：

主数据库的修改在延迟一定的时间后应用在备用数据库上。

Rapidprotection和Delayedprotection模式即使在网络连接有效时，也允许主数据库与所有的备用数据库有数据分歧，数据的丢失量等同于主数据库联机重做日志的未归档数。

这种方式对数据库性能的影响小。

如何限制数据的丢失量在primary/standby配置下，所有的归档日志被发送到了standby节点，这使standby节点的数据保持着更新。

但是，如果primary数据库意外关闭，联机的日志将会丢失，因为它们尚未归档并发送到standby节点。

这使得primary和standby数据库之间会有一个差异。

OracleArrayi可以用以下的方法来限制这个差异：

　　DBA可以选择让LGWR在将重做日志数据写到本地磁盘的同时将数据发送到standby数据库。

该功能称为standby零数据丢失（standbyzerodataloss）。

这种方法从本质的角度讲提供了远程重做日志镜像，但带来的问题是会极大地损失性能。

　　设置系统初始化参数ARCHIVE_LAG_TARGET。

该参数是一个日志文件开始使用到被发送到standby数据库的时间间隔。

该参数的推荐值是1800秒（需要注意的是，没有传送到standby数据库的已经提交的事务会丢失，因此长的事务会使standby数据库损失更多的数据）。

OracleArrayiDataGuard数据防护与Oracle8StandbyDatabase的关系OracleStandbyDatabase是最经常使用的最有效的灾难解决方案。

在过去版本的基础上，OracleArrayi又进行了许多改进，使其功能远远超过了基本的灾难恢复要求。

通过将复杂的工作自动化，并对监控、警告、以及控制机制的大规模改进，StandbyDatabase和一些新的模块可以帮助DBA从错误操作、瘫痪、以及其它的灾难中恢复（这些灾难都可能毁掉数据库）。

另外，通过使用OracleArrayiStandbyDatabase，由于硬件和软件升级造成的宕机时间也可以极度缩短。

OracleArrayi将改进过的8版本的StandbyDatabase功能，与几个新增加的防止用户错误和瘫痪的模块合起来称为OracleArrayiDataGuard。

　　Oracle8AutomatedStandbyDatabase提供了创建和自动维护生产数据库拷贝的手段来防止灾难的发生。

Oracle8AutomatedStandbyDatabase具有以下的功能：

　　当primarydatabase产生日志后，系统自动用归档日志更新standbydatabases。

一个primarydatabase可以最多有4个standbydatabases。

这4个standbydatabases是与primarydatabase完全一样的拷贝，它们都可以接管primarydatabase的处理。

Oracle使用标准的恢复方法来将归档日志应用到每个standbydatabases。

这些日志的应用是自动的，DBA也可以人工应用这些日志。

primarydatabase处于打开和活动状态，而standbydatabase处于恢复或者打开只读状态。

大多数的基于Oracle8的灾难保护方案包括一个AutomatedStandbyDatabase。

因为Oracle数据库可以用备份和日志恢复，所以任何应用都可以使用AutomatedStandbyDatabase。

通过OracleNet传输归档日志对primarydatabase的性能影响可以忽略不计。

物理的StandbyDatabase和逻辑的StandbyDatabaseStandbyDatabase可以分为物理的StandbyDatabase和逻辑的StandbyDatabase：

　　物理StandbyDatabase。

物理StandbyDatabase是Oracle8AutomatedStandbyDatabase的OracleArrayi版本。

它们之间只有一个差异：

日志传输服务现在是一个分离的模块，并支持物理standbydatabase和新的逻辑standbydatabase。

　　物理StandbyDatabase的含义是StandbyDatabase在物理上与primarydatabase一样。

因为恢复是使用ROWID一块对一块进行的，StandbyDatabase的数据块与primarydatabase的数据快一样。

数据库模式一定是一样的，且不能以读/写的方式打开。

　　逻辑StandbyDatabase。

逻辑StandbyDatabase是将归档的日志转化为SQL事务，并将它们应用到打开的StandbyDatabase。

因为数据库是打开的，它在物理上与primarydatabase是不一样的。

然而，从逻辑角度讲，StandbyDatabase与primarydatabase是一样的，因此可以接管primarydatabase的处理。

在这种情况下，StandbyDatabase还可以并发地进行其它的工作，例如建立一些与primarydatabase不一样的索引和物化视图，完成决策支持等任务。

逻辑StandbyDatabase是最重要的数据保护特性。

就像物理standbydatabase一样，它使用归档的日志在standbydatabase上进行处理，在primarydatabase出现问题的情况下也没有问题。

当选择使用物理standbydatabase、逻辑standbydatabase、或两者都用时，要考虑以下一系列的因素。

　　逻辑standbydatabase可用于两个目的。

当要对逻辑standbydatabase进行改变时，其数据库可以打开。

逻辑standbydatabase需要DBA更高的技能。

使数据保护极大化的解决方案通常包括逻辑的和物理的standbydatabases。

数据库Failover和Switchover当主数据库发生宕机，且不能及时恢复时，Oracle会丢弃主数据库，将备用数据库转变为主数据库。

当failover之后，备用数据库变成为主数据库，从而丢失了备用数据库的所有能力，也就是说，不能再返回到备用模式。

　　Failover有以下特点：

　　主数据库offline，备用数据库online，这种操作由系统和软件失败引起。

　　即使在备用数据库上应用重做日志，也可能出现数据丢失的现象，除非备

　　用数据库运行在guaranteedprotection模式下。

　　原主数据库重新使用时必须reinstantiated（startinstance）。

　　其它的备用数据库也需reinstantiated。

　　在主数据库正常工作时，Oracle允许DBA将主数据库切换到备用数据库，此备用数据库变为主数据库，而原主数据库变为备用数据库。

　　数据库的切换可以从主数据库角色切换到备用数据库角色，也可从备用数据库角色切换到主数据库角色。

　　Switchover有以下特点：

　　故意将主数据库offline，而将另一备用数据库online。

可以如使用Switchover功能完成系统的平滑升级工作。

　　即使在备用数据库上不应用重做日志，也不会造成数据的丢失。

　　数据库不需reinstantiated。

这使主数据库几乎能立即在备用数据库上恢复它的功能，因此可经常进行定期维护而不需中断操作。

　　OracleArrayiDataGuard的一些部件

　　日志传输服务（LogTransportServices）

　　LogTransportServices会被物理的和逻辑的standbydatabase都用到。

它提供的功能包括控制不同的日志传输机制、日志传输错误处理和报告、以及在系统失败后获取丢失的日志。

使用任何新的日志传输模式，数据的保护都可以得到保证。

　　OracleArrayiDataGuardBroker

　　DataGuardbroker提供了对日志传输服务的监测、控制、和自动化以及逻辑和物理standby的部件。

例如，通过只用一个命令就可以启动failover，DataGuardbroker可被用于控制主要角色从primary到任何一种standbydatabase转移的整个过程。

用户可以从2种不同的界面来选择进行角色转换，使standbydatabase从primarydatabase接管生产数据库的处理。

一种选择是使用新的OracleEnterpriseManagerDataGuardManager。

该图形用户界面工具可进行大多的配置工作和操作功能。

另一种选择是一个命令行工具，它提供了基本的监测、改变角色需要的所有命令、以及配置和设置OracleArrayiDataGuard环境的能力。

DataGuardManager是OracleEnterpriseManager的一部分。

　　OracleArrayiLogMiner

　　在OracleArrayi中，LogMiner被做了极大的改进。

LogMiner是一个关系工具，DBA可以利用这个工具使用SQL进行读、分析、和解释日志文件。

LogMiner可以查看联机的和归档的重做日志文件。

　　LogMiner技术提供了逻辑standbydatabase用到的基础结构。

新的OracleEnterpriseManager应用OracleArrayiLogMinerViewer对已经存在的命令行界面增加了一个图形操作界面。

　　灾难恢复服务器（DisasterRecoveryServer）和DRMON

　　在当今的电子商务世界中，在互连网上做生意的公司必须有一套一旦出现问题恢复应用和数据库的策略。

每个DBA都应考虑灾难恢复以及计划好的或意外的failover。

DisasterRecovery（DR）Server是帮助DBA达到更高系统可用性的产品的一部分。

　　DisasterRecovery（DR）Server从根本上说是一系列松散连接的节点组成。

这些节点将物理的和逻辑的standby方案组合成了一个单独的易管理的灾难恢复解决方案。

DisasterRecovery（DR）Server节点在物理分布上是松散的，是通过网络连接到一起的。

每个DRServer节点可能是一个简单的实例，或是一个复杂的系统（例如一个failsafecluster）。

DRServer将这些节点作为一个单独的分布计算系统来管理，从而其可用性会高于单独的节点。

　　DRServer是通过将数据在节点间复制来实现其failover系统的。

数据库管理员是这样来配置服务器的：

数据库和应用在每个节点都激活。

其中，一个节点设计成primary节点，其数据库对应用来说是完全可用的，且其数据以日志的形式复制到其它的节点。

其它的节点对primary节点来说是standby节点，它们接收从primary节点发来的日志并改变（从物理上或逻辑上）其数据库拷贝。

　　DRServer的standby节点是随时准备好在primary节点出现问题时进行接管的，从而在primary节点出现灾难后数据和应用对用户来说仍然可用。

　　DRServer结构给DBA主要提供了两点重要功能：

　　它提供了DBA从逻辑上配置一个failover资源组来达到高可用性的方法。

　　它指定了组成DRServer本身的基础计算框架。