数据库容灾的设计与实现（1）【网络安全安全管理入门必知必会】

前言

这是龙哥给粉丝盆友们整理的数据安全阶段第4篇。

喜欢的朋友们，记得给龙哥点赞支持和收藏一下，关注我，学习黑客技术。

一、绪论

（一）背景

随着信息技术的飞速发展，现代企业对计算机的依赖性严重增强，信息数据逐渐成为企业赖以生存的基础，数据损坏或丢失将给企业带来巨大的损失。由于黑客、病毒、硬件设备的失效以及火灾、地震等自然灾害的原因，使系统和数据信息遭到破坏甚至毁灭，如果不及时地进行恢复，将对企业造成巨大的损失，所以容灾技术显得尤为重要。尤其，9.11等事件造成的灾难性后果使人们更加深刻地认识到数据信息的价值和意义，日益重视数据的保护。

在以前对数据有高可靠性要求的行业总是那些视数据为生命的大行业，如银行业、保险业等，这类企业的日常生产经营中对高可用性的依赖程度很高，任何数据的丢失或损坏都会对企业造成灾难性的损失。而现在，随着信息技术的发展，很多公司开始大量使用信息系统对业务进行日常管理和工作，比如使用 ERP，CRM, O********A等应用系统，这些系统的后台都运行着不同的数据库作为业务支撑，数据成为企业的一种极具价值的资产。数据库又是企业信息系统的核心，如何保证企业的数据库系统正常运行，保证企业核心数据的安全，保障企业的业务连续性，迅速恢复数据业务，成为所有企业面临的挑战之一。

为了保障数据的安全，必须使用容灾系统。一旦发生数据灾难，造成大量数据丢失，容灾系统将能保证业务尽快恢复，甚至可以保证业务不间断运行。在选择容灾方案前，企业一定要结合自身的条件，从实际业务出发，利用现有硬件资源，然后再选择合适企业自身的容灾系统，这样才能增强系统的抗灾能力，最大限度地减少损失。目前主要的容灾方案分为：数据级和应用级。数据级容灾侧重于数据级别的保护，而应用级容灾是在数据级容灾的基础上，再构建一套相应的支撑系统，相比数据级其高昂的投入也是无法避免的。

为了满足某油田核心数据级容灾的紧迫需要，本文作者参考了各类数据级容灾方案的基础上，通过对比分析，选择了基于Oracle Data Guard数据库复制技术的数据级容灾系统。利用Oracle Data Guard的技术，对油田核心的开发业务数据库进行了数据级容灾部署，采用Data Guard Broker容灾管理平台，利用FSFO技术实现数据库灾难的自动切换。为保证用户的业务不受数据库日常维护切换及灾难切换的影响，在数据库端添加触发器，在用户端或应用服务器端采用TAF技术实现用户的透明故障转移，为业务的连续性提供可靠保证。

（二）研究内容

本论文主要研究数据级容灾系统的建设，文章结构如下：

第一章为绪论，主要介绍了论文研究的背景、意义及本人所做工作。第二章主要介绍了数据级容灾技术的分类和对比分析，在此基础选择了性价比高又能满足油田业务需要的基于数据库复制技术的数据级容灾系统，给出了油田数据级容灾系统的基本框架。从第三章到第五章为油田数据级容灾系统的实施过程，第三章论述了基于Data Guard的数据库容灾技术原理，详细说明不影响生产库运行的情况下，基于Data Guard的Standy备库的实施过程；第四章主要论述了如何基于Data Guard Broker的FSFO技术实现数据库的故障自动切换；第五章主要论述了利用服务器端触发器和TAF技术实现客户端的透明故障转移。第六章主要是对Data Guard数据级容灾系统进行应用评估。第七章是总结和展望，在总结已有成果的基础上，提出了容灾系统建设是一项系统工程，用户可以根据业务需要进一步提升容灾能力。

二、数据库容灾的设计

（一）设计原则

油田开发数据的容灾系统是一个具备数据安全与快速恢复的能力，还具备高度向下兼容与扩展能力系统。它既能支持油气田生产业务的正常运营，更要求系统具有高度的稳定性和安全性。

要达到安全的数据级容灾系统的建设要求，实现数据级容灾系统的总体目标， 在整个数据级容灾系统设计上要满足以下几个原则****😗***

（1）开放兼容原则：系统符合开放性设计原则，具备优良的可扩展性、可升级性和灵活性，对现有技术具有普适能力，可以广泛支持开放系统平台，运行于现有或即将成为标准的各种相关技术标准上；随着油田业务的不断发展，信息系统数量会快速增加，系统设计应充分考虑将来有更多的信息系统会纳入到容灾系统中；系统应具有较强的升级扩容能力。

（2）安全稳定原则：确保应用系统的安全运行和故障恢复机制；要保证系统的稳定性和可行性，使系统的运行风险降至最低；

（3）高可用原则：容灾系统要确保备份数据的完整性和一致性。一方面，容灾系统应具备稳定的、成熟的先进技术，对各种可能出现的情况做出相应的保护设计和热备份设计；另一方面，由于系统要求较高的运行可靠性，系统设计要考虑到应急方案，且应急操作安全、快捷。系统出现故障时，能够在比较短的时间内恢复系统到备库运行。

（4）易管理易原则：可以对系统进行集中管理和监控；系统维护简单，日常维护工作尽可能轻，所有日常维护工作要求基本不停机在线式操作，

（5）先进性原则：选用代表当今IT发展方向的先进设备、软件和技术；

（二）据级容灾技术

1. 网络备份管理软件

网络数据存储管理软件是指在分布式网络环境下，通过专业的数据存储管理软件，结合相应的硬件和存储设备，来对全网络的数据备份进行集中管理，从而实现自动化的备份、文件归档、数据分级存储以及灾难恢复等。

为在整个网络系统内实现全自动的数据存储管理，备份服务器、备份管理软件与智能存储设备的有机结合是这一目标实现的基础。

网络数据存储管理系统的工作原理是在网络上选择一台服务器作为网络数据存储管理服务器，安装网络数据存储管理服务器端软件，作为整个网络的备份服务器。在备份服务器上连接一台大容量存储设备（磁带库、磁盘存储设备、虚拟磁带库）。在网络中其他需要进行数据备份管理的服务器上安装备份客户端软件，通过网络将数据集中备份管理到与备份服务器连接的存储设备上。

网络数据存储管理系统的核心是备份管理软件，通过备份软件的计划功能,可为整个企业建立一个完善的备份计划及策略,并可借助备份时的呼叫功能,让所有的需要备份客户端都能在按计划进行。备份软件也提供完善的灾难恢复手段，能够将备份硬件的优良特性完全发挥出来,使备份和灾难恢复时间大大缩短，实现网络数据备份的全自动智能化管理。

目前在数据存储领域可以完成网络数据备份管理的软件产品主要有EMC的Legato NetWorker、IBM的Tivoli Storage Manager、SYMANTEC的NetBackup、CommVault的Simpana等，它们都支持包括AIX、Solaris、Windows、Linux 等所有的主流操作系统平台，不仅支持一般的数据文件和操作系统备份，而且还支持Oracle、Informix、Sybase、SQL、Exchange、DB2等数据库的在线备份及虚拟化环境中虚拟机的备份。

2. 数据库复制

利用Oracle、Sybase、DB2等数据库系统自身的日志复制功能，在灾备中心建立用户业务系统数据库的备份数据库，通过数据通信网络，将用户数据库系统产生的日志实时传送到灾备中心，利用日志向备份数据库追加数据，保持备份数据与生产数据同步或异步。

数据库日志的在线传输是基于应用层、高效快捷的数据备份方案，支持多种系统平台，包括windows、AIX、Solaris等操作系统；支持多种数据库系统，包括Oracle、DB2、Sybase、Sql server等大型数据库.

数据库复制技术有Oracle的Data Guard 、Oracle GoldenGate、IBM DB2的HADR 、SYBASE的RS、DSG的RealSync、QUEST的SharePlex等。

3. 卷复制

通过在物理磁盘上建立多个或一个逻辑卷(Volume)，以裸设备的方式使用卷，或在卷上建立文件系统。将数据，特别是需要进行远程复制的相关文件系统、数据库存放在卷上。由于数据复制是基于卷的，所以，Volume 是进行复制的基础。

卷复制基于采用各平台专用的复制软件，通过网络建立交互中心与用户电脑中心主机系统之间的备份通路，在复制软件的管理下，完成用户数据的复制。软件方式是基于操作系统、数据库系统级的复制技术，对用户应用系统透明，支持异构的存储和操作系统，支持同步和异步复制，实现数据的连续保护，。

常用的基于卷复制技术的软件有Symantec Storage Foundation 的VERITAS Volume Volume Replicator、IBM的HACMP/XD（利用AIX操作系统的卷镜像功能提供数据的远程复制）等。

4.存储复制

存储容灾技术采用先进的磁盘镜像软件，通过光纤直连、SDH、ATM、DDN/FR或IP网络等在灾备中心与生产中心建立磁盘镜像连接，实现用户数据的7×24小时远程实时备份。

存储镜像数据备份系统采用基于存储控制的复制技术，通过存储系统微码提供的数据镜像功能，将源存储数据复制至目标存储。存储镜像技术与主机平台无关，可实现不同操作系统环境下的数据远程同步及异步备份。

根据用户灾难备份的需求以及用户的硬件配置，可灵活采用不同存储系统的镜像技术，如EMC的SRDF、HDS的TrueCopy、IBM的PPRC[8]等，选择合适的通信网络及相关设备，来实现远程数据复制，这种基于存储的复制要求配置同一厂家的存储系统，也就是同构的存储系统。

基于存储虚拟化的有IBM基于存储虚拟化SAN Volume Controller、EMC的vplex等，这种技术支持异构的存储和操作系统。

（三）数据库容灾技术的设计

在构建容灾系统时，先考虑的是结合实际业务情况选择合理的数据复制技术。在选择合理的数据复制技术时主要考虑以下因素：

灾难承受程度：明确计算机系统需要承受的灾难类型，系统故障、通信故障、长时间断电、火灾及地震等各种意外情况所采用的备份、保护方案不尽相同。

业务影响程度：必须明确当计算机系统发生意外无法工作时，导致业务停顿所造成的损失程度，也就是定义用户对于计算机系统发生故障的最大容忍时间。这是设计备份方案的重要技术指标。

数据保护程度：是否要求数据库恢复所有提交的交易，并且要求实时同步，保证数据的连续性和一致性，这是备份方案复杂程度的重要依据。

****备份软件：****采用备份软件的方案较少受距离的限制，能较好地保证数据的完整性，实现起来比较容易。但这种方式对主机系统的资源消耗会相应增大，同时对网络的带宽要求比较高，投入成本较高，需要购购置备份软件，数据存储介质如磁带库或存储设备，为了提高备份效率，不影响本地网络，在本地部署时都采取了基于光纤SAN（存储区网络）的数据备份。

****卷复制：****采用卷复制的方案同较少受距离的限制，能较好地保证数据的完整性和一致性，这种方式对主机系统的资源消耗也很大，同时对网络的带宽要求比较高，投入成本较高，需要购购置卷管理软件和卷复制软件。

****数据库复制：****基于数据库复制的技术可以快速备份业务的基于数据库的核心数据，建立初期要复制全库，建成后仅传输日志数据，相当于仅做数据库的增量备份，传送数据量少，数据同步的速度快，对网络带宽要求低。数据库复制技术一般集成在数据库系统软件中，如Oracle Data Guard是Oracle企业版的一个特性，用户不需要花费任何费用就可以完成数据库的同步或异步备份，同时还可以利用数据库的闪回技术来保证对逻辑错误的恢复。

****存储复制：****采用智能存储的方案具有高效快速的特点，对网络带宽要求不高，能很好地保证数据的完整性和一致性，数据的复制备份过程不占主机资源，操作控制比较简单。同时方案整体可靠性和可维护性较高，可以极大降低后期运营回护的工作量和难度。但是基于存储的复制方案要求两端必须采用同一厂家相近级别的存储设备，一般都是高端的存储设备，如IBM DS8000系列[8]，实施费用及其昂贵，只有对数据库实时性要求极高的单位才采用这种容灾方案，如银行、电信、证劵。

基于上面方案的对比分析，结合油田的业务情况，选择基于数据库复制技术的数据级容灾方案。鉴于油田生产业务和经营综合管理业务都采用了Oracle数据库平台，最后决定采用基于Oracle Data Guard的容灾方案，能够满足设计的目标和原则，也可以满足油田业务数据的安全保护需要。

（四）容灾系统软硬件需求

结合生产业务的需要，根据容灾方案的需求决定采用Oracle的Data Guard作为数据库容灾的方案。Data Guard通过在远端保存与原数据库事务一致的数据库备份，来提供有效的灾难恢复解决方案，并且选择物理类型的备库。

图3-1给出了Data Guard的系统架构

1. 硬件需求

根据Data Guard的硬件环境要求，同一个Data Guard配置环境中，所有的Oracle数据库必须运行于相同硬件架构的平台上。比如Intel架构下的32位Linux系统_可以与Intel架构下的32位Linux系统组成—组Data Guard。不同服务器的硬件配置可以不同，但是必须确保Standby数据库服务器有足够的磁盘空间用来接收及应用Redo数据。根据现有数据库的部署情况，这里我们的数据库硬件平台采用了IBM Power系列服务器。

2. 软件需求

（1）数据库系统软件

数据库采用Oracle的10GR2企业版。Data Guard是Oracle企业版的一个特性，Primary数据库必须运行于归档模式，并且务必确保在Primary数据库上打开FORCE LOGGING,以避免用户通过nologging等方式写Redo造成对应的操作无法传输到Standby数据库，使用具有sysdba系统权限的用户管理Primary和Standby数据库。

（2）操作系统

操作系统采用AIX6.1。Primary数据库和Standby数据库的操作系统必须一致，操作系统版本可以略有差异。Primary数据库和Standby数据库的目录结构也可以不同，这里我们在主库P590和备库P720的上采用目录结构。

（3）Data Guard还提供了一个分布式管理框架，称为Data Guard Observer[2],Broker集成在Observer中，这种架构不但自动化了 Data Guard配置的创建、维护和监控，并对这些操作进行统一管理。管理员可以使用Oracle Enterprise Manager图形管理界面或Broker自己的专用命令行界面 (DGMGRL)来利用Broker的管理功能。更重要的是利用Broker的Fast-Failover 技术可以实现故障的自动切换及数据的零丢失，使得Data Guard更加可靠安全。管理架构见下图：

3.备库类型的选择

选择物理备库作为Standby备用库，物理备份数据库通过存储介质的恢复来 实现Primary数据库的REDO应用，以达到与Primary数据库保持一致的目的。物理备份数据库的优点主要有以下几个方面：

（1）灾难恢复及高可用性。物理Standby提供了一个健全、高效的灾难恢复，以及高可用性的解决方案。更加易于管理switchover（日常维护切换）/failover（故障切换）角色转换及在更短的计划内或计划外停机时间。

（2）数据保护。使用物理Standby数据库，Data Guard能够确保即使面对无法预料的灾害也能够不丢失数据。物理Standby是基于块对块的复制，因此与对象、语句无关， Primary数据库有什么，物理Standby数据库端也会有什么。

（3）分担Primary数据库压力。通过将一些备份任务、仅查询的需求转移到物理Standby数据库，可以有效节省Primary数据库的CPU及I/O资源。

（4）提升性能。物理Standby所使用的REDO应用技术使用最底层的恢复机制，这种机制能够绕过SQL级代码层，因此效率最高。

Data Guard包含一个Primary数据库即被大部分应用访问的生产数据库，该库既可以是单实例数据库，也可以是RAC。同一个Data Guard中可以最多创建9 个Standby数据库。一旦创建完成，Data Guard通过应用Primary数据库的Redo自动维护每一个Standby数据库。

（五）容灾系统物理架构

在中心机房，采用基于AIX系统的服务器P590部署Oracle主数据库，P720服务器部署Oracle备库，通过Data Guard实现主数据库和备数据库的实时同步，用户在数据库中提交的事务在主数据库和备数据库都完成提交后，才反馈给用户结果，保证中心机房主数据库和开发事业部机房备数据库的一致性，实现提交业务数据的零丢失。

中心机房的主数据库发生故障后，通过FSFO技术对备数据库进行自动灾难切换，迅速恢复对用户的数据库服务。针对人为的逻辑错误情况，通过Oracle的Flashback技术完成对数据库逻辑错误的快速恢复。

三、Data Guard的实施过程

（一）Oracle Data Guard基础

Oracle Data Guard是Oracle企业版自带的数据复制功能，基本原理是将日志文件从原数据库传输到目标数据库，然后在目标数据库上应用这些日志文件，从而使目标数据库与源数据库保持同步，是一种数据库级别的容容灾份方案。

Data Guard可以提供Oracle数据库的冗灾、数据保护、故障恢复等，实现数据库快速切换与灾难性恢复。在生产数据库的保证"事务一致性"时，使用生产库的物理全备份创建备库，备库会通过生产库传输过来的归档日志自动维护Standby数据库。

1. Data Guard配置

Data Guard 是一个集合，由一个primary 数据库或者叫生产数据库及一个或多个standby 数据库(最多9个)组成。组成Data Guard 的数据库通过Oracle Net连接，并且有可能分布于不同地域。只要各库之间可以相互通信，它们的物理位置并没有什么限制，你即可以通过命令行方式管理primary 数据库或standby 数据库，也可以通过Data Guard broker 提供的专用命令行界面(DGMGRL)，或者通过OEM 图形化界面管理。

（1）Primary数据库

本文中的描述中称Primary数据库为主库或生产数据库。Data Guard 包含一个primary 数据库即被大部分应用访问的生产数据库，该库即可以是单实例数据库，也可以是RAC。

（2）Standby数据库

文中又称为备库。Standby数据库是primary数据库的复制，事务上保持一致。在同一个Data Guard 中你可以最多创建9个standby数据库。一旦创建完成，Data Guard 通过应用primary 数据库的redo自动维护每一个standby 数据库。Standby数据库同样即可以是单实例数据库，也可以是Oracle的RAC结构(Real Application Clusters)。关于standby 数据库，通常分两类逻辑standby和物理standby，为了提高可维护性，采用物理standby书库。

2. Data Guard使用的服务

（1）重做传输服务(Redo Transport Services)。控制redo数据的传输到一个或多个归档目的地。

（2）日志应用服务(Log Apply Services) 。应用redo数据到standby数据库，以保持与primary数据库的事务一致。redo数据即可以从standby数据库的归档文件读取，也可直接应用备用日志文件读取。

（3）角色转换服务(Role Transitions) 。Data Guard中有两种角色primary和standby。角色转换就是让数据库在这两个角色中切换，切换分两种switchover和failover 。Switchover一般在日常维护中使用，switchover可以确保不会丢失数据；Failover主库故障时采用，当primary数据库出现故障并且不能被及时恢复时，会调用failover将一个standby数据库转换为新的primary数据库。在最大保护模式或最高可用性模式下，failover可以保证不会丢失数据。

3. Data Guard保护模式

对于Data Guard 而言，由于它提供了三种数据保护的模式。

（1）最大保护(Maximum protection)

这种模式能够确保绝无数据丢失。要实现这一步当然是有代价的，它要求所有的事务在提交前其redo不仅被写入到本地的online redo log，还要同时提交到standby 数据库的standby redo log，并确认redo 数据至少在一个standby 数据库可用(如果有多个的话)，然后才会在primary 数据库上提交。如果出现了什么故障导致standby数据库不可用的话，primary数据库会被shutdown，导致数据业务的停顿。

（2）最高性能(Maximum performance)

这种模式提供在不影响primary 数据库性能前提下最高级别的数据保护策略。事务可以随时提交，当前primary 数据库的redo 数据也需要至少写入一个standby 数据库，不过这种写入可以是不同步的。如果网络条件理想的话，这种模式能够提供类似最高可用性的数据保护而仅对primary 数据库有轻微的性能影响。

（3）最高可用性(Maximum availability)

这种模式提供在不影响primary 数据库可用前提下最高级别的数据保护策略。其实现方式与最大保护模式类似，也是要求所有事务在提交前必须保障redo 数据至少在一个standby数据库可用，不过与最大保护模式不同的是，如果出现故障导入无法同时写入standby 数据库redo log，primary 数据库并不会shutdown，而是自动转为最高性能模式，等standby 数据库恢复正常之后，它又会再自动转换成最高可用性模式。

最大保护及最高可用性需要至少一个standby 数据库redo 数据被同步写入。三种模式都需要指定LOG_ARCHIVE_DEST_n 初始化参数。

4. Standby 之 REDO传输服务

关于redo 传输服务(Redo Transport Services)，它不仅控制着传输redo 数据到其它数据库，同时还管理着解决由于网络中断造成的归档文件未接收的过程。

在primary 数据库，Data Guard可以使用归档进程(ARCn)或者日志写进程(LGWR)收集redo数据并传输到standby，不管你选择归档进程也好，日志写进程也好，都由一个核心参数来控制，它就是LOG_ARCHIVE_DEST_n(n从1到10)定义redo文件路径。该参数定义必须通过location 或service 指明归档文件路径。location 表示本地路径，service 通常是net service name，即接收redo数据的standby 数据库。

下表中描述了不同保护模式下LOG_ARCHIVE_DEST_n 参数应该设置的属性：

最大保护	最髙可用	最高性能
REDO写进程	LGWR	LGWR	LGWR 或 ARCH
网络传输模式	SYNC	SYNC	LGWR 进程时 SYNC 或 ASYNC, ARCH 进程时 SYNC
磁盘写操作	AFFIRM	AFFIRM	AFFIRM或 NOAFFIRM
是否需要Standby Redo logs	YES	YES	可没有，但推荐有

1）使用ARCn归档redo数据

默认情况下，redo 传输服务使用ARCn 进程归档redo 日志。不过ARCn 归档进程只支持最高性能的保护模式。如果standby数据库处于其它类型的保护模式，那你必须使用LGWR 传输redo数据。下图描述传送过程。

在上图中，primary 数据库日志发生切换时就会启动归档。在primary 数据库假设有2 个归档进程，一旦ARC0 进程完成redolog 的归档，ARC1 进程即开始传输归档到standby 数据库的指定路径。

在standby数据库，RFS进程轮流将redo数据写入standby redo log，再由standby 数据库中的ARCn 进程将其写入归档，然后通过REDO应用或SQL 应用将数据应用到standby 数据库。

2）使用LGWR归档redo数据

使用LGWR 进程与使用ARCn 进程有明显不同，LGWR 无须等待日志切换及完成归档。Standby 数据库的LGWR进程会先选择一个standby redo log文件映射primary 数据库当前redolog 的sequence(以及文件大小)，一旦primary 数据库有redo数据产生，根据LOG_ARCHIVE_DEST_n 初始化参数中sync 或async 属性设置，以同步或非同步方式传输到standby 数据库。

LGWR 归档进程密切相关的LOG_ARCHIVE_DEST_n 几个参数的属性，如果选择LGWR归档redo数据，那么在LOG_ARCHIVE_DEST_n中必须指定SERVICE 和LGWR属性以允许日志传输服务使用LGWR 进程来传送redo 数据到远程归档目的地。我们还需要指定SYNC(同步)还是ASYNC(异步)的传输方式，如果指定SYNC 属性(如果不明确指定的话，默认是SYNC)，则primary数据库任何会产生redo 操作都会同步触发网络I/O，并且等到网络I/O 全部完成才会继续下面的提交，而如果指定了ASYNC 属性，则会primary 数据库的操作会先记录online redologs，然后再传输到standby。

（1）LGWR 同步归档的流程，例如初始化参数中有如下设置：

LOG_ARCHIVE_DEST_1='LOCATION=E:ora10goradatajssweb ’

LOG_ARCHIVE_DEST_2=‘SERVICE=jsspdg LGWR SYNC NET_TIMEOUT=30’

LOG_ARCHIVE_DEST_STATE_1=ENABLE

LOG_ARCHIVE_DEST_STATE_2=ENABLE

如果设置LOG_ARCHIVE_DEST_n 初始化参数SYNC 属性，建议同时设置NET_TIMEOUT 属性，该属性控制网络连接的超时时间，如果超时仍无响应，则会返回错误信息。

（2）LGWR 不同步归档的流程，例如初始化参数中有如下设置：

LOG_ARCHIVE_DEST_1='LOCATION=E:ora10goradatajssweb ’

LOG_ARCHIVE_DEST_2=‘SERVICE=jsspdg LGWR ASYNC’

LOG_ARCHIVE_DEST_STATE_1=ENABLE

LOG_ARCHIVE_DEST_STATE_2=ENABLE

ASYNC 方式归档就不需要再指定NET_TIMEOUT 了，因为LGWR 与LNSn 之间已无关联，所以指定不指定NET_TIMEOUT 就都没任何影响了，因此对于异步传输而言，即使网络出现故障造成primary与standby 之间通信中断，也并不会影响到primary 数据库的提交。

下图为Data Guard使用LGWR同步传输REDO的过程。

上图中展示了primary数据库LGWR写online redologs的同时，同步传输redo数据到standby 数据库的过程。在primary 数据库，LGWR 提交redo 数据到LNSn(LGWR Network Server process)进程(n>0)，LNSn 启动网络传输。standby 数据库的RFS(Remote File Server)将接收到的redo数据写入standby redolog。特别注意，在此期间，primary 数据库的事务会一直保持，直到所有所有含LGWR SYNC 属性的LOG_ARCHIVE_DEST_n 指定路径均已完成接收。

一旦primary 数据库执行日志切换，就会级联触发standby的ARCn将standby redo 写入归档，然后通过redo 应用MRP进程或sql 应用LSP 进程读取归档文件将数据应用standby 数据库。如果启用了实时应用的话，MRP/LSP 会直接读取standby redolog 并应用到standby 数据库，无须再等待归档。

下图为Data Guard使用LGWR异步传输REDO的过程

上图展示了LNSn 进程异步传输redo 数据到standby 数据库RFS 进程的过程。大致步骤与同步传输相同，差别只在LNSn 进程这里，LGWR 写数据到online redolog，LNSn 进程访问online redolog 并传输数据到远程standby的RFS而不再与本地LGWR 之间有联系。standby 数据库方面的处理逻辑仍然不变。

（二）Data Guard的实施过程

目前油田的单台Unix服务器或Windows服务器都运行着Oracle数据库的多个实例，下面以两台Aix服务器P590和P720为例，数据库采用Oracle10GR2，实施Data Guard。两台服务器的位置可分别位于油田中心机房和开发事业部机房。

Oracle主库位于服务器P590上，上面运行着三个实例的数据库，分别是开发数据库ora7、经营数据库orajy及天然气数据库tlmtrq1，正常情况下由主库P590对外提供数据库服务。

我们要做的工作是在P720上安装Oracle10GR2，运行在归档模式下。对三个实例的数据库采用物理standby分别实施Data Guard，实现数据库的容灾。

为了不影响生产业务的运行，我这里采用不关闭数据库的方法进行Data Guard的部署，这种部署方法可以充分保障现有的生产数据业务不受影响，保证业务的连续性。

1. 数据库目录结构及服务地址

根据物理standby的要求，P720的目录文件物理结构要和P590保持一致。Oracle操作系统的用户ora10g，主目录为/home/ora10g，Oracle的环境变量放在这里。

在P720的卷组oravg上创建文件系统如下，和p590目录结构保持一致：

序号	逻辑卷	挂载点	大小	用途描述
1	/dev/fslv00	/oradata/orajy	100G	实例orajy数据文件目录
2	/dev/fslv01	/oradata/ora7	100G	实例ora7数据文件目录
3	/dev/fslv02	/oradata/tlmtrq1	100G	实例tlmtrq1数据文件目录
4	/dev/fslv03	/oraarch	400G	归档日志目录

Oralce 10GR2数据库的安装过程不再叙述。上表中挂载点分别为三个数据库数据文件的目录，/oraarch为三个数据库的归档目录。

由于要求每个实例对外提供服务的IP保持不变，所以在主库和备库之间发生互相切换的时候，对外提供服务的IP也要随之切换，要求对外提供服务的IP总是在主库服务器上，IP规划如下：

主机	IP地址	说明
P590	10.79.20.51	服务器P590物理IP
P720	10.79.20.54	服务器P720物理IP
主库服务器	10.79.20.43	实例orajy对外提供服务IP
	10.79.20.50	实例ora7对外提供服务IP
	10.79.20.67	实例tlmtrq1对外提供服务IP

在两台主机P590、P720 目录/home/ora10g/script下创建脚本add_ip.sh和del_ip.sh,脚本内容如下：

add_ip.sh增加IP脚本：

ifconfig en1 10.79.20.43 netmask 255.255.254.0 alias

ifconfig en1 10.79.20.50 netmask 255.255.254.0 alias

ifconfig en1 10.79.20.67 netmask 255.255.254.0 alias

del_ip.sh删除IP脚本：

ifconfig en1 10.79.20.43 netmask 255.255.254.0 delete

ifconfig en1 10.79.20.50 netmask 255.255.254.0 delete

ifconfig en1 10.79.20.67 netmask 255.255.254.0 delete

一般服务器都有多个网卡，为提高IO性能，建议在将IP地址配置在不同的网络端口上。本文配置在一块网卡卡，增加多个IP地址。

2. ORACLE网络配置

（1）监听配置

由于主库对外提供服务，与备库相比，多出3个对外提供服务的IP，因此主库和备库的监听配置[3]不同，配置文件均位于$ORACLE_HOME/network/admin/,文件名为listener.ora。监听配置完成之后，需要重新启动监听进程。

现有主库的监听文件listener.ora内容：

SID_LIST_LISTENER =

(SID_LIST =

(SID_DESC =

  (SID_NAME = orajy)

  (ORACLE_HOME = /app/oracle/product/10.2.0/db)

)

(SID_DESC =

  (SID_NAME = ora7)

  (ORACLE_HOME = /app/oracle/product/10.2.0/db)

)

 (SID_DESC =

  (SID_NAME = tlmtrq1)

  (ORACLE_HOME = /app/oracle/product/10.2.0/db)

)

)

LISTENER =

(DESCRIPTION_LIST =

(DESCRIPTION =

 (ADDRESS = (PROTOCOL = TCP)(HOST = 10.79.20.51)(PORT = 1521))

 (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC0))

)

(DESCRIPTION =

 (ADDRESS = (PROTOCOL = TCP)(HOST = 10.79.20.43)(PORT = 1521))

 (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC2))

 )

(DESCRIPTION =

 (ADDRESS = (PROTOCOL = TCP)(HOST = 10.79.20.67)(PORT = 1521))

 (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC3))

 )

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = 10.79.20.50)(PORT = 1521))

 (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC4))

 )

)

在P720上完成Oracle数据库10gr2的安装后，使用任何文本编辑器建立备库监听文件listener.ora，内容如下：

SID_LIST_LISTENER =

(SID_LIST =

(SID_DESC =

  (SID_NAME = orajy)

  (ORACLE_HOME = /app/oracle/product/10.2.0/db)

)

(SID_DESC =

  (SID_NAME = ora7)

  (ORACLE_HOME = /app/oracle/product/10.2.0/db)

)

(SID_DESC =

  (SID_NAME = tlmtrq1)

  (ORACLE_HOME = /app/oracle/product/10.2.0/db)

)

)

LISTENER =

(DESCRIPTION_LIST =

(DESCRIPTION =

 (ADDRESS = (PROTOCOL = TCP)(HOST = 10.79.20.54)(PORT = 1521))

 (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC0))

(2)TNS配置

主库和备库的tnsnames.ora文件内容一致，均位于$ORACLE_HOME/network/admin/，需要增加以下内容：

orajy =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = 10.79.20.51)(PORT = 1521))

(CONNECT_DATA =

  (SERVER = DEDICATED)

  (SERVICE_NAME = orajy)

)

)

orajy_std =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = 10.79.20.54)(PORT = 1521))

(CONNECT_DATA =

  (SERVER = DEDICATED)

  (SERVICE_NAME = orajy)

)

)

ora7 =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = 10.79.20.51)(PORT = 1521))

(CONNECT_DATA =

  (SERVER = DEDICATED)

  (SERVICE_NAME = ora7)

)

)

ora7_std =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = 10.79.20.54)(PORT = 1521))

(CONNECT_DATA =

  (SERVER = DEDICATED)

  (SERVICE_NAME = ora7)

)

)

tlmtrq1 = (DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = 10.79.20.51)(PORT = 1521))

(CONNECT_DATA =

  (SERVER = DEDICATED)

  (SERVICE_NAME = tlmtrq1)

)

)

tlmtrq1_std =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = 10.79.20.54)(PORT = 1521))

(CONNECT_DATA =

  (SERVER = DEDICATED)

  (SERVICE_NAME = tlmtrq1)

)

3. 物理Standby库的建立

下面以orajy的物理Standby库的建立为例，详细描述在主库不停机的情况的实施过程。假设主库与备库orajy物理存储结构如下：

数据库主目录为/app/oracle/product/10.2.0/db/；

数据库的名称DB_NAME为orajy;

主库的参数DB_UNIQUE_NAME为orajy, 备库的参数DB_UNIQUE_NAME为orajy_std;

数据文件、在线日志文件及standby日志文件目录为 /oradata/orajy；

控制文件目录 /app/oracle/oradata/orajy；

当前Primary数据库处于归档模式，归档日志目录为 /oraarch/orajy/；

参数与口令文件位于默认/$ORACLE_HOME/dbs/目录下；

RMAN数据备份 /oraarch/orajy/fullbk****/。****

(1)在备库P720上安装Oracle数据库系统，创建数据文件和归档日志的目录并进行用户授权。有关操作系统的命令请参阅AIX系统管理的相关书籍[14]。以下针对Oracle数据库的操作需要用户具有sysdba权限，请参阅Oracle数据库管理的资料[15]。

$mkdir /oradata/orajy

$mkdir /oraarch/orajy

$mkdir /oraarch/orajy/fullbk

$mkdir /app/oracle/admin/orajy

$cd /app/oracle/admin/orajy

$mkdir adump bdump cdump dpdump pfile udump

使用root用户授权

#chown -R ora10g /oradata

#chown -R ora10g /oraarch

#chown –R ora10g /app

#chgrp –R dba /oradata

#chgrp –R dba /oraarch

#chgrp –R dba /app

(2)、在主库P590上，修改主库处于force logging模式

SQL> ALTER DATABASE FORCE LOGGING;

如果口令文件不存在通过下列命令创建

orapwd file=’$ORACLE_HOME/dbs/orapworajy’ password=shift001

(3)、在主库P590上，配置主库的Standby Redo log。

配置之前，检查主库orajy的在线归档日志ORL有3组，每组2个文件，根据Oracle文档中的建议，需要建立(3+1)*2=8个Standby Redo log文件，而且文件大小要和SRL中的文件大小保持一致。

$export ORACLE_SID=orajy

$sqlplus ‘/as sysdba’

SQL>alter database force logging;

SQL> alter database add standby logfile Group 4 (‘/oradata/orajy/redo41.log’,‘/oradata/orajy/redo42.log’) size 50M;

SQL> alter database add standby logfile Group 5 (‘/oradata/orajy/redo51.log’,‘/oradata/orajy/redo52.log’) size 50M;

SQL> alter database add standby logfile Group 6 (‘/oradata/orajy/redo61.log’,‘/oradata/orajy/redo62.log’) size 50M;

SQL> alter database add standby logfile Group 7 (‘/oradata/orajy/redo71.log’,‘/oradata/orajy/redo72.log’) size 50M;

(4)、在主库P590上，修改主库的参数文件

SQL>alter system set LOG_ARCHIVE_CONFIG=‘DG_CONFIG=(orajy,orajy_std)’;

SQL> alter system set LOG_ARCHIVE_DEST_1=‘LOCATION=/oradata/orajy/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=orajy_std’;

SQL>alter system set LOG_ARCHIVE_DEST_2=‘SERVICE=orajy_std LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=orajy_std’;

SQL> alter system set LOG_ARCHIVE_DEST_STATE_1=ENABLE;

SQL>alter system set FAL_SERVER=orajy_std;

SQL>alter system set FAL_CLIENT=orajy;

如果文件目录不一样，设置参数DB_FILE_NAME_CONVERT及LOG_FILE_NAME_CONVERT;

(5)、在主库P590上，使用RMAN[16]工具进行全备份

$rman target /

$rman >

Run {

allocate channel c1 type disk;

allocate channel c2 type disk;

backup database format ‘/oraarch/orajy/fullbk/%U’

plus archivelog format ‘/oraarch/orajy/fullbk/%U’;

backup current controlfile for standby format ‘/oraarch/orajy/fullbk/%U’;

}

(6)、在主库P590上，为备库创建参数文件

SQL>create pfile='/oraarch/orajy/fullbk/orajysb.ora’ from spfile;

(7)、在主库P590上，将口令文件orapworajy传送到备库的/$ORACLE_HOME/dbs目录中；将RMAN备份的文件 /oraarch/orajy/fullbk/* 及归档文件/oraarch/orajy/*.arc 到备库P720的相同目录中。

(8)、在备库P720上，按照上一节中所述，创建备库的监听文件listener.ora及服务别名文件tnsnames.ora,并使用tnsping测试，保证连接畅通。

$ tnsping orajy

TNS Ping Utility for IBM/AIX RISC System/6000: Version 10.2.0.1.0 - Production o

n 03-OCT-2013 18:51:32

Copyright © 1997, 2005, Oracle. All rights reserved.

Used parameter files:

Used TNSNAMES adapter to resolve the alias

Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = 10.79.20.45)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = orajy__)))__

OK (0 msec)

(9)、在备库P720上，修改备库的参数文件orajysb.ora

db_name=orajy

db_unique_name=orajy_std

log_archive_config=‘DG_CONFIG=(orajy,orajy_std)’

log_archive_dest_1=‘LOCATION=/oraarch/orajy/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=orajy_std’

log_archive_dest_2=‘SERVICE=orajy LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=orajy’

log_archive_dest_state_1=ENABLE

REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE

standby_archive_dest=‘/oraarch/orajy/’

standby_file_management=AUTO

fal_client=orajy_std

fal_server=orajy

如果操作系统的版本不一样，可能会要求修改sga_target的大小

(10)、在备库P720上，启动数据库到no mount状态

$export ORACLE_SID=orajy

$sqlplus ‘/as sysdba’

$SQL> create spfile from pfile=’/oraarch/orajy/fullbk/orajysb.ora’;

$SQL>startup nomount

(11)、在备库P720上，使用RMAN duplicate命令创建standby数据库[11]。

$rman target sys/shift001@orajy auxiliary /

Recovery Manager: Release 10.2.0.1.0 - Production on Thu Mar 5 12:30:56 2009 Copyright © 1982, 2005, Oracle. All rights reserved.

connected to target database: orajy (DBID=3971986030)
connected to auxiliary database: orajy (DBID=3971986030, not open)

RMAN> duplicate target database for standby dorecover nofilenamecheck;

对于目录结构和文件名一样的必须加参数nofilenamecheck

(12)、在备库P720上，创建SRL

SQL> alter database add standby logfile Group 4 (‘/oradata/orajy/redo41.log’,‘/oradata/orajy/redo42.log’) size 50M;

SQL> alter database add standby logfile Group 5 (‘/oradata/orajy/redo51.log’,‘/oradata/orajy/redo52.log’) size 50M;

SQL> alter database add standby logfile Group 6 (‘/oradata/orajy/redo61.log’,‘/oradata/orajy/redo62.log’) size 50M;

SQL> alter database add standby logfile Group 7 (‘/oradata/orajy/redo71.log’,‘/oradata/orajy/redo72.log’) size 50M;

(13)、在备库P720上，启动MRP（managed recovery process）

SQL> select name,db_unique_name,database_role from v$database;

NAME DB_UNIQUE_NAME DATABASE_ROLE

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

ORAJY STDBY PHYSICAL Standby

SQL> alter database recover managed standby database disconnect;

(14)、在主库p590上，设置 the log_archive_dest_2参数，启动日志文件的传输。

SQL>alter system set log_archive_dest_state_2=enable;

(15)、在备库P720上，检查是否与主库同步

SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;

SEQUENCE# FIRST_TIME NEXT_TIME

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

    __84 28-SEP-13    28-SEP-13__

    __85 28-SEP-13    28-SEP-13__

    __86 28-SEP-13    28-SEP-13__

    __87 28-SEP-13    28-SEP-13__

    __88 28-SEP-13    28-SEP-13__

    __89 28-SEP-13    28-SEP-13__

    __90 28-SEP-13    28-SEP-13__

    __91 28-SEP-13    28-SEP-13__

    __92 28-SEP-13    30-SEP-13__

    __93 30-SEP-13    01-OCT-13__

    __94 01-OCT-13    02-OCT-13__

SEQUENCE# FIRST_TIME NEXT_TIME

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

    __95 02-OCT-13    03-OCT-13__

12 rows selected.

在主库P590上，进行日志切换

SQL> ALTER SYSTEM SWITCH LOGFILE;

在备库P720上，进行检查

SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;

SEQUENCE# FIRST_TIME NEXT_TIME

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

    __84 28-SEP-13    28-SEP-13__

    __85 28-SEP-13    28-SEP-13__

    __86 28-SEP-13    28-SEP-13__

    __87 28-SEP-13    28-SEP-13__

    __88 28-SEP-13    28-SEP-13__

    __89 28-SEP-13    28-SEP-13__

    __90 28-SEP-13    28-SEP-13__

    __91 28-SEP-13    28-SEP-13__

    __92 28-SEP-13    30-SEP-13__

    __93 30-SEP-13    01-OCT-13__

    __94 01-OCT-13    02-OCT-13__

SEQUENCE# FIRST_TIME NEXT_TIME

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

    __95 02-OCT-13    03-OCT-13__

    __96 03-OCT-13    03-OCT-13__

13 rows selected.

我们看到日志文件已经传输过来。

SQL> select sequence#,applied from v$archived_log order by sequence#;
SEQUENCE# APP

---------- —

    __84 NO__

    __85 NO__

    __86 NO__

    __87 NO__

    __88 NO__

    __89 YES__

    __90 YES__

    __91 YES__

    __92 YES__

    __93 YES__

    __94 YES__

SEQUENCE# APP

---------- —

    __95 YES__

    __96 YES__

13 rows selected.

可以看出，日志已经在备库应用。

(16)7实现数据的同步

要说明的是，为了保证主库的正常服务，我们在主库设置log_archive_dest_2参数的时候，使用LGWR ASYNC的选项，也就是说主库到备库采用了日志写进程LGWR的异步传输。如果采用同步传输，备库的错误，可能会影响主库的正常服务。待备库成功建成后。我们可以根据需要，重新设置log_archive_dest_2的参数，调整Data Guard的保护模式，满足数据级容灾的需要。

采用上述方法建立备库后，Data Guard的保护模式为最高性能模式。为了容灾的需要，一般我们设置为最高可用性模式，要启用最高可用性模式，必须启用LGWR同步写REDO数据的方式，之前配置的 LOG_ARCHIVE_DEST_n参数中，虽然也有LGWR写REDO数据，但都是非同步方式，因此有必要首先对初始化参数进行修改。

SQL>alter system set LOG_ARCHIVE_DEST_2=‘SERVICE=orajy_std LGWR SYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=orajy_std’;

设置新的数据保护模式，并选择合适时机重启数据库。语句非常简单，如下所示：

SQL>ALTER DATABASE SET Standby DATABASE TO MAXIMIZE AVAILABILITY;

(17)、对于实例ora7和tlmtrq1，备库的创建方法一样，参考上文步骤.

4. Data Guard日常维护

以实例orajy为例,主库备库的启动与关闭

(1)、主库和备库的正常启动顺序

在P590上，先启动主库

$export ORACLE_SID=orajy

SQL>startup

在P720上，再启动备库

$export ORACLE_SID=orajy

SQL>startup mount;

SQL> ALTER DATABASE RECOVER MANAGED Standby DATABASE DISCONNECT FROM SESSION;

在备库如启用实时应用，附加USING CURRENT LOGFILE 子句即可。建议在实施数据库容灾时启动实时应用。

SQL> ALTER DATABASE RECOVER MANAGED Standby DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;

(2)、主库与备库正确关闭顺序

在P720上，先关闭备库

$export ORACLE_SID=orajy

SQL> ALTER DATABASE RECOVER MANAGED Standby DATABASE CANCEL;

SQL> shutdown immediate

在P590上，在关闭主库

$export ORACLE_SID=orajy

SQL> shutdown immediate

(3)、备库Read-Only模式打开

当前主库处于OPEN状态，备库处于日志传送状态

在P720上

$export ORACLE_SID=orajy

SQL> recover managed standby database cancel;

SQL>alter database open read only;

备库回到日志传送模式

SQL> recover managed standby database disconnect from session;

(4)正常维护切换（Switchover）

A、在P590上，在主库端检验数据库可切换状态

$export ORACLE_SID=orajy

SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;

SWITCHOVER_STATUS

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

TO Standby

如果SWITCHOVER_STATUS为TO Standby表示可以正常切换

如果SWITCHOVER_STATUS的值为SESSIONS ACTIVE,表示当前有会话处于ACTIVE状态。

B、在P590上，开始主库正常切换

如果SWITCHOVER_STATUS的值为TO Standby 则执行：

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL Standby;

如果SWITCHOVER_STATUS的值为SESSIONS ACTIVE 则执行

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL Standby WITH SESSION SHUTDOWN;

成功运行后，主库被修改为备库

C、在P590上，重启先前的主库

SQL> SHUTDOWN IMMEDIATE;

SQL> STARTUP MOUNT;

D、在P720上，在备库验证可切换状态

$export ORACLE_SID=orajy

SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;

SWITCHOVER_STATUS

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

TO_PRIMARY

E、在P720上，将目标备库转换为主库

如果SWITCHOVER_STATUS的值为TO_PRIMARY 则执行

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

如果SWITCHOVER_STATUS的值为SESSIONS ACTIVE 则执行

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;

成功运行后，备库被修改为主库

F、在P720上，重启新的主库

SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP;

在P590上，新的备库启动日志传送进程

SQL> alter database recover managed standby database disconnect;

G、对外服务IP切换

在P590上，删除对外提供服务的IP，更换监听配置文件

以root用户登录，运行命令：#/home/ora10g/script/del_ip.sh

以ora10g用户登录，修改监听配置文件listener.ora，重新启动监听。修改后的P590上的listener.ora为

SID_LIST_LISTENER =

(SID_LIST =

(SID_DESC =

  (SID_NAME = orajy)

  (ORACLE_HOME = /app/oracle/product/10.2.0/db)

)

(SID_DESC =

  (SID_NAME = ora7)

  (ORACLE_HOME = /app/oracle/product/10.2.0/db)

)

(SID_DESC =

  (SID_NAME = tlmtrq1)

  (ORACLE_HOME = /app/oracle/product/10.2.0/db)

)

)

LISTENER =

(DESCRIPTION_LIST =

(DESCRIPTION =

 (ADDRESS = (PROTOCOL = TCP)(HOST = 10.79.20.51)(PORT = 1521))

 (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC0))

)

)

在P720上，新的主库增加对外提供服务IP，更换监听配置文件

以root用户登录，运行命令：#/home/ora10g/script/add_ip.sh

以ora10g用户登录，修改监听配置文件，重新启动监听。修改后的listener.ora为：

SID_LIST_LISTENER =

(SID_LIST =

(SID_DESC =

  (SID_NAME = orajy)

  (ORACLE_HOME = /app/oracle/product/10.2.0/db)

)

(SID_DESC =

  (SID_NAME = ora7)

  (ORACLE_HOME = /app/oracle/product/10.2.0/db)

)

 (SID_DESC =

  (SID_NAME = tlmtrq1)

  (ORACLE_HOME = /app/oracle/product/10.2.0/db)

)

)

LISTENER =

(DESCRIPTION_LIST =

(DESCRIPTION =

 (ADDRESS = (PROTOCOL = TCP)(HOST = 10.79.20.54)(PORT = 1521))

 (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC0))

)

(DESCRIPTION =

 (ADDRESS = (PROTOCOL = TCP)(HOST = 10.79.20.43)(PORT = 1521))

 (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC2))

)

(DESCRIPTION =

 (ADDRESS = (PROTOCOL = TCP)(HOST = 10.79.20.67)(PORT = 1521))

 (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC3))

)

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = 10.79.20.50)(PORT = 1521))

 (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC4))

)

)

(4)主库灾难切换failover

a、当主库出现故障的时候，首先删除其对外提供服务的IP

以root用户登录，运行命令：#/home/ora10g/script/del_ip.sh

在备库增加对外服务IP，以root用户登录，运行：#/home/ora10g/script/add_ip.sh

b、备库切换为主库

$export ORACLE_SID=orajy

SQL> atter database set standby database to maximize performance;

SQL> alter database recover managed standby database finish force;

SQL> alter database commit to switchover to primary ;

SQL> alter database open;

c、修改监听文件listener.ora，重新启动监听

本章小结

1、Oracle数据库从9i开始提供的Data Guard功能，为Oracle数据库的容灾提供了经济可靠的方案。用户可以根据需要，通过修改参数，实现同步或异步的数据库容灾。主库灾难切换（failover） 之后，原primary 数据库默认不再是data guard 配置的一部分。其它standby 数据库不直接参与failover 的过程，因此这些数据库不需要做任何操作。为了保证数据库的高可用性，为primary 数据库最好设计2个以上standby 数据库。

因为主库一般是性能高的服务器，在灾难切换后，在原主库的服务器上需要手动重建standby 数据库，将主库切换回来。这给日常管理带来了极大不便，不能满足数据级容灾的需要。

2、因为灾难切换是手动切换，时间长，不能满足RTO（恢复时间目标），为管理维护带来不便。

3、由于切换操作时，IP地址也需要进行切换，所以在规划Data Guard时通过网络设备的VLAN技术将primary数据库服务器和standby数据库服务器的IP地址划在同一子网内，便于IP地址的切换。从这点看来也为后期维护带来了不便。

总之单纯使用Data Guard建立备库，是不能满足容灾的管理需要的，下面的章节中，将进一步解决这方面的问题

原文始发于微信公众号（龙哥网络安全）：数据库容灾的设计与实现（1）【网络安全安全管理入门必知必会】