All about Data Guard

一、 Data Guard 配置(Data Guard Configurations)
Data Guard 是一个集合，由一个primary数据库(生产数据库)及一个或多个standby数据库(最多9个)组成。组成Data Guard的数据库通过Oracle Net连接，并且有可能分布于不同地域。只要各库之间可以相互通信，它们的物理位置并没有什么限制，至于操作系统就更无所谓了(某些情况下)，只要支持oracle就行了。

你即可以通过命令行方式管理primary数据库或standby数据库，也可以通过Data Guard broker提供的专用命令行界面(DGMGRL)，或者通过OEM图形化界面管理。

1. Primary  数据库
前面提到，Data Guard包含一个primary数据库即被大部分应用访问的生产数据库，该库即可以是单实例数据库，也可以是RAC。

2. Standby  数据库
Standby 数据库是primary数据库的复制(事务上一致)。在同一个Data Guard中你可以最多创建9个standby数据库。一旦创建完成，Data Guard 通过应用primary数据库的redo 自动维护每一个standby 数据库。Standby 数据库同样即可以是单实例数据库，也可以是RAC 结构。关于standby 数据库，通常分两类：逻辑standby 和物理standby，如何区分，两类各有什么特点，如何搭建，这方面内容就是后面主要介绍的，在这里呢简单白话一下：

逻辑standby
就像你请人帮你素描画像，基本器官是都会有的，这点你放心，但是各器官位置啦大小啦肤色啦就不一定跟你本人一致了。

物理standby
就像拿相机拍照，你长什么样出来的照片就是什么样，眼睛绝对在鼻子上头。或者说就像你去照镜子，里外都是你。具体到数据库就是不仅文件的物理结构相同，甚至连块在磁盘上的存储位置都是一模一样的(默认情况下)。

为什么会这样呢？这事就得从同步的机制说起了。逻辑standby是通过接收primary数据库的redo log并转换成sql语句，然后在standby数据库上执行SQL语句(SQL Apply)实现同步，物理standby是通过接收并应用primary数据库的redo log 以介质恢复的方式(Redo Apply)实现同步。

另外，不知道大家是否注意到形容词上的细节：对于相机拍照而言，有种傻瓜相机功能强大而操作简便，而对于素描，即使是最简单的画法，也需要相当多的练习才能掌握。这个细节是不是也说明逻辑standby相比物理standby需要操作者拥有更多的操作技能呢？

二、 Data Guard 服务(Data Guard Services)
REDO 传输服务(Redo Transport Services)
控制redo 数据的传输到一个或多个归档目的地。

Log 应用服务(Log Apply Services)
应用redo数据到standby 数据库，以保持与primary 数据库的事务一致。redo数据即可以从standby 数据库的归档文件读取，也可直接应用standby redo log 文件(如果实时应用打开了的话)。

角色转换服务(Role Transitions)
Dg 中只有两种角色：primary 和standby。所谓角色转换就是让数据库在这两个角色中切换，切换也分两种：switchover 和failover。

switchover ：转换primary 数据库与standby 数据库。switchover可以确保不会丢失数据。

failover ：当primary数据库出现故障并且不能被及时恢复时，会调用failover将一个standby数据库转换为新的primary 数据库。在最大保护模式或最高可用性模式下，failover可以保证不会丢失数据。

注：上述各概念简要了解即可，这里写的太简单，不要咬文嚼字，不然你会越看越糊涂，相关服务在后面章节将会有详细介绍，不仅有直白的描述，还会有示例，再加上浅显的图片，就算你一看不懂，再看肯定懂：）

三、 Data Guard 保护模式(Data Guard Protection Modes)
对于Data Guard而言，其生存逻辑非常简单，好好活，做有意义的事，做黑多黑多有意义的事：）

由于它提供了三种数据保护的模式，我们又亲切的叫它：有三模：

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

最高性能(Maximum performance)：
这种模式提供在不影响primary数据库性能前提下最高级别的数据保护策略。事务可以随时提交，当前primary数据库的redo数据也需要至少写入一个standby数据库，不过这种写入可以是不同步的。

如果网络条件理想的话，这种模式能够提供类似最高可用性的数据保护而仅对primary数据库有轻微的性能影响。

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

最大保护及最高可用性需要至少一个standby数据库redo数据被同步写入。三种模式都需要指定LOG_ARCHIVE_DEST_n 初始化参数。LOG_ARCHIVE_DEST_n 很重要，你看着很眼熟是吧，我保证，如果你完完整整学完dataguard，你会对它更熟。

四、 Data Guard 优点总结
灾难恢复及高可用性
全面的数据保护
有效利用系统资源
在高可用及高性能之间更加灵活的平衡机制
故障自动检查及解决方案
集中的易用的管理模式

自动化的角色转换

同一个Data Guard配置包含一个 Primary 数据库和最多九个 Standby 数据库。 Primary 的创建就不说了，Standby数据库初始可以通过primary数据库的备份创建。一旦创建并配置成standby后，dg负责传输primary数据库redo data到standby数据库，standby数据库通过应用接收到的redo data保持与primary数据库的事务一致。

一、 Standby 数据库类型

前章我们简单介绍了Standby数据库，并且也知道其通常分为两类：物理standby和逻辑standby，同时也简短的描述了其各自的特点，下面我们就相关方面进行一些稍深入的了解：

1.  物理standby
我们知道物理standby与primary数据库完全一模一样(默认情况下，当然也可以不一样，事无绝对嘛)，Dg通过redo应用维护物理standby数据库。通常在不应用恢复的时候，可以以read-only模式打开，如果数据库指定了flashback area的话，也可以被临时性的置为read-write模式。

Redo 应用
物理standby通过应用归档文件或直接从standby系统中通过oracle恢复机制应用redo文件。恢复操作属于块对块的应用(不理解？那就理解成块复制，将redo中发生了变化的块复制到standby)。如果正在应用redo，数据库不能被open。

Redo 应用是物理standby 的核心，务必要搞清楚其概念和原理，后续将有专门章节介绍。
Read-only 模式
以read-only模式打开后，你可以在standby数据库执行查询，或者备份等操作(变相减轻primary数据库压力)。此时standby数据库仍然可以继续接收redo数据，不过并不会触发操作，直到数据库恢复redo应用。也就是说read-only模式时不能执行redo应用，redo应用时数据库肯定处于未打开状态。如果需要的话，你可以在两种状态间转换，比如先应用redo,然后read-only，然后切换数据库状态再应用redo，呵呵，人生就是循环，数据库也是一样。

Read-write 模式
如果以read-write模式打开，则standby数据库将暂停从primary数据库接收redo数据，并且暂时失去灾难保护的功能。当然，以read-write模式打开也并非一无是处，比如你可能需要临时调试一些数据，但是又不方便在正式库操作，那就可以临时将standby数据库置为read-write模式，操作完之后将数据库闪回到操作前的状态(闪回之后，Data Guard会自动同步，不需要重建standby)。

物理standby特点
Ø  灾难恢复及高可用性
物理standby提供了一个健全而且极高效的灾难恢复及高可用性的解决方案。更加易于管理的switchover/failover角色转换及最更短的计划内或计划外停机时间。

Ø  数据保护
应用物理standby数据库，Dg能够确保即使面对无法预料的灾害也能够不丢失数据。前面也提到物理standby是基于块对块的复制，因此对象、语句统统无关，primary数据库上有什么，物理standby也会有什么。

Ø  分担primary数据库压力
通过将一些备份任务、仅查询的需求转移到物理standby，可以有效节省primary数据库的cpu以及i/o资源。

Ø  提升性能
物理standby所使用的redo应用技术使用最底层的恢复机制，这种机制能够绕过sql级代码层，因此效率最高。

2.  逻辑standby
逻辑standby是逻辑上与primary数据库相同，结构可以不一致。逻辑standby通过sql应用与primary数据库保持一致，也正因如此，逻辑standby可以以read-write模式打开，你可以在任何时候访问逻辑standby数据库。同样有利也有弊，逻辑standby对于某些数据类型以及一些ddl,dml会有操作上的限制。

逻辑standby的特点：
除了上述物理standby中提到的类似灾难恢复，高可用性及数据保护等之外，还有下列一些特点：

Ø  有效的利用standby的硬件资源
除灾难恢复外，逻辑standby数据库还可用于其它业务需求。比如通过在standby数据库创建额外的索引、物化视图等提高查询性能并满足特定业务需要。又比如创建新的schema(primary数据库并不存在)然后在这些schema中执行ddl或者dml操作等。

Ø  分担primary数据库压力
逻辑standby数据库可以在更新表的时候仍然保持打开状态，此时这些表可同时用于只读访问。这使得逻辑standby数据库能够同时用于数据保护和报表操作，从而将主数据库从那些报表和查询任务中解脱出来，节约宝贵的 CPU和I/O资源。

Ø  平滑升级
比如跨版本升级啦，打小补丁啦等等，应该说应用的空间很大，而带来的风险却很小(前提是如果你拥有足够的技术实力。另外虽然物理standby也能够实现一些升级操作，但如果跨平台的话恐怕就力不从心，所以此项就不做为物理standby的特点列出了)，我个人认为这是一种值的推荐的在线的滚动的平滑的升级方式。

二、 Data Guard 操作界面(方式)
做为oracle环境中一项非常重要的特性，oracle提供了多种方式搭建、操作、管理、维护Data Guard配置，比如：

OEM(Oracle Enterprise Manager)
Orcale EM 提供了一个窗口化的管理方式，基本上你只需要点点鼠标就能完全dg的配置管理维护等操作，其实质是调用oracle为dg专门提供的一个管理器：Data Guard Broker来实施管理操作。

Sqlplus 命令行方式
命令行方式的管理，本系列文章中主要采用的方式。不要一听到命令行就被吓倒，data guard的管理命令并不多，你只需要在脑袋瓜里稍微挪出那么一小点地方用来记忆就可以了。

DGMGRL(Data Guard broker 命令行方式)
就是Data Guard Broker，不过是命令行方式的操作。

初始化参数文件
我感觉不能把参数化参数视为一种操作方式，应该说，在这里，通过初始化参数，更多是提供更灵活的Data Guard配置。

三、 Data Guard 的软硬件需求
1、 硬件及操作系统需求

同一个Data Gurid配置中的所有oracle数据库必须运行于相同的平台。比如inter架构下的32位linux系统可以与inter架构下的32位linux系统组成一组Data Guard。另外，如果服务器都运行于32位的话，64位HP-UX也可以与32位HP-UX组成一组Data Guard。
不同服务器的硬件配置可以不同，比如cpu啦，内存啦，存储设备啦，但是必须确保standby数据库服务器有足够的磁盘空间用来接收及应用redo数据。

primary 数据库和standby数据库的操作系统必须一致，不过操作系统版本可以略有差异，比如(linux as4&linux as5)，primary数据库和standby数据库的目录路径也可以不同。

2、 软件需求

Data Guard 是Oracle企业版的一个特性，明白了吧，标准版是不支持地。
通过Data Guard的SQL应用，可以实现滚动升级服务器数据库版本(要求升级前数据库版本不低于10.1.0.3)。
同一个Data Guard配置中所有数据库初始化参数：COMPATIBLE的值必须相同。
Primary 数据库必须运行于归档模式 ，并且务必确保在primary数据库上打开FORCE LOGGING，以避免用户通过nologging等方式避免写redo造成对应的操作无法传输到standby数据库。
Primary 和standby数据库均可应用于单实例或RAC架构下 ，并且同一个data guard配置可以混合使用逻辑standby和物理standby 。
Primary 和standby数据库可以在同一台服务器，但需要注意各自的数据文件存放目录，避免重写或覆盖。
使用具有sysdba系统权限的用户管理primary和standby数据库。
建议数据库必须采用相同的存储架构。比如存储采用ASM/OMF的话，那不分primarty或是standby也都需要采用ASM/OMF。

另外还有很重要一点，注意各服务器的时间设置，不要因为时区/时间设置的不一置造成同步上的 问题。

四、 分清某某REDO LOGS(Online Redo Logs, Archived Redo Logs, Standby Redo Logs)

黑多黑多的redo，想必诸位早已晕头并吐过多次了吧。哎，说实话我描述的时候也很痛苦。这块涉及到中英文之间的意会。我又不能过度白话，不然看完我这篇文章再看其它相关文档的相关概念恐怕您都不知道人家在说什么，这种误人子弟的事情咱不能干(也许干过，但主观意愿上肯定是不想的)，更何况咱也是看各乱杂七杂八文档被误过XXXXXXXXXXXXXXXXX次(X=9)，深受其害，坚决不能再让跟俺一样受尽苦楚，历经磨难的DDMM们因为看俺的文档被再次一百遍啊一百遍。

但是已到关键时刻，此处不把redo混清楚，后头就得被redo混了，所以这里我要用尽我全部的口水+目前为止我所有已成体系的认识再给大家浅显的白话一回。

REDO ：中文直译是重做，与UNDO对应(天哪又扯出个概念，你看不见我看不见我看不见我)。重做什么？为什么要重做呢？首先重做是oracle对操作的处理机制，我们操作数据(增册改)并非直接反映到数据文件，而是先被记录(就是online redo log喽)，等时机合适的时候，再由相应的进程操作提交到数据文件(详细可见： 数据写过程中各项触发条件及逻辑 ) 。你是不是想说如果把所有的online redo logs都保存下来，不就相当于拥有了数据库做过的所有操作了吗？en，我可以非常负责任的告诉你，你说的对，oracle跟你想到一块去了并且也将其实现了，这就是archived  redo logs，简称archive log即归档日志。我们再回来看Data Guard，由于standby数据库的数据通常都来自于primary数据库，怎么来的呢，通过RFS进程接收primary数据库的redo，保存在本地，就是Standby redo logs喽(arch模式的话不写standby redo，直接保存归档)，然后standby数据库的相关进程读取接收到的redo数据，再将其写入standby数据库。保存之后数据又是怎么生成的呢，两种方式，物理standby通过redo应用，逻辑standby通过sql应用，不管是哪种应用，应用的是什么呢？是redo log中的内容(默认情况下应用archived redo logs，如果打开了实时应用，则直接从standby redo logs中读取)，至于如何应用，那就是redo应用和sql应用机制的事情了(也许后头我们会深入聊一聊这个话题，很复杂也很有趣)。

针对上述内容我们试着总结一下，看看能否得出一些结论：

对于primary数据库和逻辑standby数据库，online redo log文件肯定是必须的，而对于物理standby是否还需要redo log呢？毕竟物理standby通常不会有写操作，所以物理standby应该不会生成有redo数据。为保证数据库的事务一致性必然需要有归档，也就是说不管primary或standby都必须运行于归档模式。

Standby redo logs 是standby数据库特有的文件(如果配置了的话)，就本身的特点比如文件存储特性，配置特性等等都与online redo logs非常类似，不过它存储的是接收自primary数据库的redo数据，而online redo logs中记录的是本机中的操作记录。

第二部分 物理standby(1)创建步骤

一、 准备工作
不管物理standby还是逻辑standby，其初始创建都是要依赖primary数据库，因为这个准备工作中最重要的一部分，就是对primary数据库的配置。

1、 打开Forced Logging模式
将primary数据库置为FORCE LOGGING模式。通过下列语句：

SQL> alter database force logging;

提示：关于FORCE LOGGING
想必大家知道有一些DDL语句可以通过指定NOLOGGING子句的方式避免写redo log(目的是提高速度，某些时候确实有效)，指定数据库为FORCE LOGGING模式后，数据库将会记录除临时表空间或临时回滚段外所有的操作而忽略类似NOLOGGING之类的指定参数。如果在执行force logging时有nologging 之类的语句在执行，则force logging 会等待直到这类语句全部执行。FORCE LOGGING是做为固定参数保存在控制文件中，因此其不受重启之类操作的影响(只执行一次即可)，如果想取消，可以通过alter database no force logging 语句关闭强制记录。

2、 创建密码文件(如果不存在的话)
需要注意的是，同一个Data Guard 配置中所有数据库必须都拥有独立的密码文件，并且必须保证同一个Data Guard配置中所有数据库服务器的SYS用户拥有相同密码以保证redo 数据的顺利传输，因为redo 传输服务通过认证的网络会话来传输redo 数据，而会话使用包含在密码文件中的SYS用户密码来认证。

3、 配置Standby Redo Log
对于最大保护和最高可用性模式，Standby数据库必须配置standby redo log，并且oracle推荐所有数据库都使用LGWR ASYNC 模式传输，当然你现在可能还不知道LGWR ASYNC 是什么问题，没关系，你很快就会知道了。

Oracle 建议你在创建standby 时就考虑standby redo log 配置的问题。standby redo logs 与online redo logs 非常类似，应该说两者只是服务对象不同，其它参数属性甚至操作的命令格式几乎都一样，你在设计standby redo logs 的时候完全可以借鉴创建online redo logs 的思路，比如多个文件组啦，每组多个文件冗余之类的。除些之外呢，oracle提供了一些标准的建议如下：

* 确保standby redo log 的文件大小与primary数据库online redo log 文件大小相同。

* 创建适当的日志组
一般而言，standby redo 日志文件组数要比primary 数据库的online redo 日志文件组数至少多一个。推荐standby redo 日志组数量基于primary 数据库的线程数(这里的线程数可以理解为rac结构中的rac节点数)。

有一个推荐的公式可以做参考：(每线程的日志组数+1)*最大线程数

例如primary数据库有两个线程，每个线程分配两组日志，则standby日志组数建议为6组，使用这个公式可以降低primary数据库实例LGWR进程锁住的可能性。

提示：逻辑standby数据库有可能需要视工作量增加更多的standby redo log文件(或增加归档进程)，因为逻辑standby需要同时写online redo log 文件。

Standby redo log 的操作方式与online redo log几乎一模一样，只不过在创建或删除时需要多指定一个standby 关键字，例如添加：
=========================================================================================================
SQL> alter database add standby logfile group  4  ('e:\ora10g\oradata\jsspdg\STANDBYRD01.LOG') size 20 M;

SQL> alter database drop standby logfile group 4;
=========================================================================================================

另外，从可靠性方面考虑，建议在primary数据库也创建standby redologs，这样一旦发生切换，不会影响primary做为standby的正常运行。

验证standby redo log文件组是否成功创建

例如：

========================================================================
SQL> SELECT GROUP#,THREAD#,SEQUENCE#,ARCHIVED,STATUS FROM V$STANDBY_LOG;

========================================================================

4、 设置初始化参数
对于primary数据库，需要定义几个primary角色的初始化参数控制redo传输服务，还有几个附加的standby角色的参数需要添加以控制接收redo数据库并应用(switchover/failover后primary/standby角色可能互换，所以建议对于两类角色 相关的 初始化参数都进行配置)。

下列参数为primary角色相关的初始化参数：
DB_NAME	注意保持同一个Data Guard中所有数据库DB_NAME相同。 例如：DB_NAME=jssweb
DB_UNIQUE_NAME	为每一个数据库指定一个唯一的名称，该参数一经指定不会再发生变化，除非你主动修改它。 例如：DB_UNIQUE_NAME=jssweb
LOG_ARCHIVE_CONFIG	该参数通过DG_CONFIG属性罗列同一个Data Guard中所有DB_UNIQUE_NAME(含primary db及standby db)，以逗号分隔 例如：LOG_ARCHIVE_CONFIG=¨D G _CONFIG=(jssweb,jsspdg)¨
CONTROL_FILES	没啥说的，控制文件所在路径。
LOG_ARCHIVE_DEST_n	归档文件的生成路径 。该参数非常重要，并且属性和子参数也特别多(这里不一一列举，后面用到时单独讲解如果你黑好奇，建议直接查询oracle官方文档。Data guard白皮书第14章专门介绍了该参数各属性及子参数的功能和设置)。 例如： LOG_ARCHIVE_DEST_1= 'LOCATION=E:\ora10g\oradata\jssweb VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=jssweb'
LOG_ARCHIVE_DEST_STATE_n	指定参数值为ENABLE，允许redo传输服务传输redo数据到指定的路径。 该参数共拥有4个属性值，功能各不相同。
REMOTE_LOGIN_PASSWORDFILE	推荐设置参数值为EXCLUSIVE或者SHARED，注意保证相同Data Guard配置中所有db服务器sys密码相同。
LOG_ARCHIVE_FORMAT	指定归档文件格式。
LOG_ARCHIVE_MAX_PRODUCESSES	指定归档进程的数量(1-30)，默认值通常是4 。
以下参数为standby角色相关的参数，建议在Primary数据库 的初始化参数中也进行 设置，这样在role transition后(Primary转为Standby)也能正常运行：
FAL_SERVER	指定一个 TNSNAMES ，通常该 tnsnames 对应数据库为primary角色。 例如：FAL_SERVER=jssweb
FAL_CLIENT	指定一个 TNSNAMES ，通常该 tnsnames 对应数据库为standby角色。 例如：FAL_CLIENT=jsspdg 提示：FAL是Fetch Archived Log的缩写
DB_FILE_NAME_CONVERT	在做duplicate复制和传输表空间的时候这类参数讲过很多遍，该参数及上述内容中同名参数功能，格式等完全相同。
LOG_FILE_NAME_CONVERT	同上
STANDBY_FILE_MANAGEMENT	如果primary数据库数据文件发生修改（如新建，重命名等）则按照本参数的设置在standby中做相应修改。设为AUTO表示自动管理。设为MANUAL表示需要手工管理。 例如：STANDBY_FILE_MANAGEMENT=AUTO

注意：上面列举的这些参数仅只是对于primary/standby两角色可能会相关的参数，还有一些基础性参数比如*_dest,*_size等数据库相关的参数在具体配置时也需要根据实际情况做出适当修改。
5、 确保数据库处于归档模式

SQL> archive log list;

SQL> STARTUP MOUNT;
SQL> ALTER DATABASE ARCHIVELOG;

SQL> ALTER DATABASE OPEN;

二、 手把手的创建物理standby
1、 创建备份(手工复制数据文件或通过RMAN)  ---primary库操作

2、 创建控制文件  --primary库操作

通过下列语句为standby数据库创建控制文件

SQL> alter database create standby controlfile as 'd:\backup\jsspdg01.ctl';

注意哟，控制文件通常需要有多份，你要么手工将上述文件复制几份，要么用命令多创建几个出来。另外，创建完控制文件之后到standby数据库创建完成这段时间内，要保证primary数据库不再有结构性的变化(比如增加表空间等等)，不然primary和standby同步时会有问题。

3、 创建初始化参数文件

创建客户端初始化参数文件
例如：
SQL> create pfile='d:\backup\initjsspdg.ora' from spfile;
修改初始化参数文件中的参数
根据实际情况修改吧，注意primary和standby不同角色的属性配置，注意文件路径。

4、 复制文件到standby服务器

至少三部分：数据文件，控制文件，修改过的初始化参数文件，注意路径。

5、 配置standby数据库

1) . 创建新的OracleService(windows环境下需要)。

2) . 创建密码文件，注意保持密码与primary数据库一致。

3) . 配置监听并启动

4) . 修改primary和standby的tnsnames.ora，各自增加对应的Net Service Name。

5) . 创建服务器端的初始化文件

6、 启动standby

注意哟，咱们前面说过的，物理standby极少情况下可以以read-write模式打开，某些情况下可以以read-only模式打开，所以默认情况下，加载到mount状态即可。

SQL> STARTUP MOUNT;
启动redo应用

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
启动实时应用

SQL>  ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
提示： disconnect from session 子句并非必须，该子句用于指定启动完应用后自动退出到命令操作符前，如果不指定的话，当前session就会一直停留处理redo应用，如果想做其它操作，就只能新建一个连接。

7、 停止standby

正常情况下，我们停止也应该是先停止redo应用，可以通过下列语句：

SQL>  ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CALCEL;
然后再停止standby数据库

SQL> SHUTDOWN IMMEDIATE;
当然你非要直接shutdown也没问题，dg本来就是用于容灾的，别说你生停standby，就是直接拔电源也不怕。


第二部分 物理standby(2)创建示例
为了最大的降低硬件需求，此处创建的data guard处于同一台机器，但其创建过程与多机并无区别。做为演示用的示例足够了，我们分两阶段配置，分别是配置primary数据库和配置standby数据库，如下：

一、 Primary 数据库配置及相关操作

1、 确认主库处于归档模式

SQL> archive log list;

2、 将primary数据库置为FORCE LOGGING模式。通过下列语句：

SQL> alter database force logging;

3、 创建standby数据库控制文件

SQL> alter database create standby controlfile as 'd:\backup\jsspdg01.ctl';

4、 创建primary数据库客户端初始化参数文件

注：主要此处修改项较多，为了方便，我们首先创建并修改pfile，然后再通过pfile重建spfile，你当然也可以通过alter system set命令直接修改spfile内容。

SQL> create pfile from spfile;

将该初始化参数文件复制一份，做为standby数据库的客户端初始化参数文件

SQL> host copy e:\ora10g\product\10.2.0\db_1\database\initjssweb.ora d:\backup\initjsspdg.ora

修改客户端初始化参数文件，增加下列内容

DB_UNIQUE_NAME=jssweb

LOG_ARCHIVE_CONFIG='DG_CONFIG=(jssweb,jsspdg)'

LOG_ARCHIVE_DEST_1='LOCATION=E:\ora10g\oradata\jssweb\ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=jssweb'

LOG_ARCHIVE_DEST_2='SERVICE=jsspdg LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=jsspdg'

LOG_ARCHIVE_DEST_STATE_1=ENABLE

LOG_ARCHIVE_DEST_STATE_2=ENABLE

REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE

#-------- 配置standby角色的参数用于角色转换

FAL_SERVER=jsspdg

FAL_CLIENT=jssweb

DB_FILE_NAME_CONVERT='oradata\jsspdg','oradata\jssweb'

LOG_FILE_NAME_CONVERT='oradata\jsspdg','oradata \jssweb'

STANDBY_FILE_MANAGEMENT=AUTO

SQL> shutdown immediate

SQL> create spfile from pfile='initjssweb.ora';

5、 复制数据文件到standby服务器(方式多样，不详述)

注意需要复制所有数据文件，备份的控制文件及客户端初始化参数文件

6、 配置listener及net service names(方式多样，不详述)。

完之后重启listener:


二、 Standby 数据库配置及相关操作
1、 通过ORADIM 创建新的OracleService

2、 创建密码文件，注意保持sys密码与primary数据库一致。

E:\ora10g>orapwd file=e:\ora10g\product\10.2.0\db_1\database\PWDjsspdg.ora password=verysafe entries=30

3、 创建目录

E:\ora10g\product\10.2.0\admin\jsspdg>mkdir adump

4、 复制文件，不做过多描述

5、 修改初始化参数文件

增加下列参数：
db_unique_name=jsspdg
LOG_ARCHIVE_CONFIG='DG_CONFIG=(jssweb,jsspdg)'
DB_FILE_NAME_CONVERT='oradata\jssweb','oradata\jsspdg'
LOG_FILE_NAME_CONVERT='oradata\jssweb','oradata\jsspdg'
LOG_ARCHIVE_FORMAT=log%t_%s_%r.arc
LOG_ARCHIVE_DEST_1='LOCATION=E:\ora10g\oradata\jsspdg\ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=jsspdg'
LOG_ARCHIVE_DEST_STATE_1=ENABLE

#--- 下列参数用于角色切换

LOG_ARCHIVE_DEST_2='SERVICE=jssweb LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)  DB_UNIQUE_NAME=jssweb'
LOG_ARCHIVE_DEST_STATE_2=ENABLE
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
FAL_SERVER=jssweb
FAL_CLIENT=jsspdg
STANDBY_FILE_MANAGEMENT=AUTO
注意同时修改*_dest的路径

通过该pfile创建spfile

SQL> create spfile from pfile='D:\backup\initjsspdg.ora';

6、 启动standby到mount

SQL> startup mount;

7、 启动redo应用

SQL> alter database recover managed standby database disconnect from session;

8、 查看同步情况

首先连接到primary数据库

SQL> show parameter instance_name;
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
instance_name                        string      jssweb

SQL> alter system switch logfile;

系统已更改。

SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
--------------
            51

连接到standby数据库

SQL> show parameter instance_name;
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
instance_name                        string      jsspdg


SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
--------------
            51

9、 暂停应用

通过下列语句暂停redo应用。

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

注意，此时只是暂时redo应用，并不是停止Standby数据库，standby仍会保持接收只不过不会再应用接收到的归档，直到你再次启动redo应用为止。