Oracle9i Data Guard的灾难防护

物理的Standby Database和逻辑的Standby Database
　　
　　Standby Database可以分为物理的Standby Database和逻辑的Standby Database：
　　
　　物理 Standby Database。物理 Standby Database是Oracle8 Automated Standby Database的Oracle9i版本。它们之间只有一个差异：日志传输服务现在是一个分离的模块，并支持物理standby database和新的逻辑standby database。
　　
　　物理Standby Database的含义是Standby Database在物理上与primary database 一样。因为恢复是使用 ROWID 一块对一块进行的，Standby Database的数据块与primary database的数据快一样。数据库模式一定是一样的，且不能以读/写的方式打开。
　　
　　逻辑 Standby Database.逻辑 Standby Database是将归档的日志转化为SQL事务，并将它们应用到打开的Standby Database.因为数据库是打开的，它在物理上与primary database是不一样的。然而，从逻辑角度讲，Standby Database与primary database是一样的，因此可以接管primary database的处理。在这种情况下，Standby Database还可以并发地进行其它的工作，例如建立一些与primary database不一样的索引和物化视图，完成决策支持等任务。
　　
　　逻辑 Standby Database 是最重要的数据保护特性。就像物理 standby database一样，它使用归档的日志在standby database上进行处理，在primary database出现问题的情况下也没有问题。
　　
　　当选择使用物理standby database、逻辑standby database、或两者都用时，要考虑以下一系列的因素。
　　
　　逻辑standby database可用于两个目的。当要对逻辑standby database进行改变时，其数据库可以打开。
　　
　　逻辑standby database需要DBA更高的技能。
　　
　　使数据保护极大化的解决方案通常包括逻辑的和物理的standby databases.数据库Failover和Switchover当主数据库发生宕机，且不能及时恢复时，Oracle会丢弃主数据库，将备用数据库转变为主数据库。当 failover之后，备用数据库变成为主数据库，从而丢失了备用数据库的所有能力，也就是说，不能再返回到备用模式。

　　Failover 有以下特点：

　　主数据库offline，备用数据库online，这种操作由系统和软件失败引起。
　　
　　即使在备用数据库上应用重做日志，也可能出现数据丢失的现象，除非备用数据库运行在guaranteed protection模式下。
　　
　　原主数据库重新使用时必须reinstantiated（start instance）。
　　
　　其它的备用数据库也需reinstantiated.
　　
　　在主数据库正常工作时，Oracle 允许 DBA 将主数据库切换到备用数据库，此备用数据库变为主数据库，而原主数据库变为备用数据库。
　　
　　数据库的切换可以从主数据库角色切换到备用数据库角色，也可从备用数据库角色切换到主数据库角色。
　　
　　Switchover 有以下特点：

　　故意将主数据库offline，而将另一备用数据库online.可以如使用Switchover 功能完成系统的平滑升级工作。
　　
　　即使在备用数据库上不应用重做日志，也不会造成数据的丢失。
　　
　　数据库不需reinstantiated.这使主数据库几乎能立即在备用数据库上恢复它的功能，因此可经常进行定期维护而不需中断操作。
　　
　　Oracle9i Data Guard的一些部件日志传输服务（Log Transport Services）
　　
　　Log Transport Services会被物理的和逻辑的standby database 都用到。它提供的功能包括控制不同的日志传输机制、日志传输错误处理和报告、以及在系统失败后获取丢失的日志。使用任何新的日志传输模式，数据的保护都可以得到保证。
　　
　　Oracle9i Data Guard Broker

　　Data Guard broker提供了对日志传输服务的监测、控制、和自动化以及逻辑和物理standby的部件。例如，通过只用一个命令就可以启动 failover，Data Guard broker可被用于控制主要角色从primary到任何一种standby database转移的整个过程。用户可以从2种不同的界面来选择进行角色转换，使standby database 从primary database接管生产数据库的处理。一种选择是使用新的Oracle Enterprise Manager Data Guard Manager。该图形用户界面工具可进行大多的配置工作和操作功能。另一种选择是一个命令行工具，它提供了基本的监测、改变角色需要的所有命令、以及配置和设置Oracle9i Data Guard环境的能力。
　　
　　Data Guard Manager 是Oracle Enterprise Manager的一部分。
　　
　　Oracle9i LogMiner

　　在 Oracle9i中，LogMiner被做了极大的改进。LogMiner是一个关系工具，DBA可以利用这个工具使用SQL进行读、分析、和解释日志文件。LogMiner可以查看联机的和归档的重做日志文件。
　　
　　LogMiner技术提供了逻辑standby database用到的基础结构。新的Oracle Enterprise Manager应用Oracle9i LogMiner Viewer 对已经存在的命令行界面增加了一个图形操作界面。
　　
　　灾难恢复服务器（Disaster Recovery Server）和DRMON

　　在当今的电子商务世界中，在互连网上做生意的公司必须有一套一旦出现问题恢复应用和数据库的策略。每个DBA都应考虑灾难恢复以及计划好的或意外的failover。Disaster Recovery (DR) Server 是帮助DBA达到更高系统可用性的产品的一部分。
　　
　　Disaster Recovery (DR) Server 从根本上说是一系列松散连接的节点组成。这些节点将物理的和逻辑的standby 方案组合成了一个单独的易管理的灾难恢复解决方案。Disaster Recovery (DR) Server节点在物理分布上是松散的，是通过网络连接到一起的。每个 DR Server 节点可能是一个简单的实例，或是一个复杂的系统（例如一个 fail safe cluster）。DR Server 将这些节点作为一个单独的分布计算系统来管理，从而其可用性会高于单独的节点。
　　
　　DR Server 是通过将数据在节点间复制来实现其 failover 系统的。数据库管理员是这样来配置服务器的：数据库和应用在每个节点都激活。其中，一个节点设计成primary节点，其数据库对应用来说是完全可用的，且其数据以日志的形式复制到其它的节点。其它的节点对primary节点来说是standby节点，它们接收从primary节点发来的日志并改变（从物理上或逻辑上）其数据库拷贝。
　　
　　DR Server的standby节点是随时准备好在primary节点出现问题时进行接管的，从而在primary 节点出现灾难后数据和应用对用户来说仍然可用。

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

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

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

查看本文来源