DG 学习笔记



3.2 Data Guard 背景
从ORACLE9i开始，改成DATA GUARD，在这种模式中，开始支持三种不同的数据保护模式，并开始采用LGWR 对数据的传送而不是以往的ARCH，而且增加了一个新的后台进程叫DMON 监控数据的同步，在11g之前最多支持9个节点的同时复制。从Oracle 9.2.0开始，开始支持逻辑standby。

3.4 Data Guard 是如何架构的？
(图)

3.4.1 Primary Database
DG环境包含一个主库。 主库可以是单实例，也可以是RAC 集群。

3.4.2 Standby Databases
3.4.2.1 Physical standby database –物理standby
物理standby是对主库进行physically identical copy。 这是一种Media recovery，是基于block-for-block的恢复。在数据块级别进行恢复，这种方式没有数据类型的限制，可以保证两个数据库完全一致。
这个同步的过程叫Redo Apply。
在Oracle 11g之前，standby 数据库只能在Mount 状态下进行恢复，也可以是打开，但只能已只读方式打开，并且打开时不能执行恢复操作。
到了11g，standby 可以启动到read-only状态并同步，这样standby 数据库就可以用来进行一些数据查询操作，提高数据库的利用率。

3.4.2.2 Logical standby database  --逻辑standby
逻辑standby 的同步使用的是SQL Apply。 这种方式是先把主库传送过来的redo 信息转换成SQL 语句，然后在备库执行这些SQL 语句，最终实现同步。
因为是通过Logminer 技术，通过把日志内容还原成SQL 语句，然后SQL引擎执行这些语句，Logminer Standby不支持所有数据类型，可以在视图 DBA_LOGSTDBY_UNSUPPORTED 中查看不支持的数据类型，如果使用了这种数据类型，则不能保证数据库完全一致。

3.4.2.3 Snapshot Standby Database  -- 快照 standby
现在我们看一下snapshot standby database 到底是什么。
1）.Snapshot standby database是建立在物理standby 的基础上的。
2）.如果我们想在standby 库上做一些测试，因为主库我们不能动，我们可以在备库测。 那么我们就可以把这个standby 切换成snapshot standby。
切换语句如下：
SQL> alter database convert to snapshot standby;
切换之后，我们可以查看alert log，会发现里面有创建一个restore point:
Created guaranteed restore point SNAPSHOT_STANDBY_REQUIRED_xxx
3). 把snapshot standby 数据库打开，进行我们的测试。
SQL> alter database open;
4）. 测试完毕后，我们把数据库重启到mount 状态。
5） 执行命令将数据库从snapshot状态切换到之前的状态，如物理standby或者逻辑standby。
SQL> alter database convert to physical standby;

3.4.3 Data Guard Services
DG 有三个Services：
（1）Redo Transport Services
这个服务在主库上，用来把主库的redo 数据传到指定的归档路径上去。 这个传输过程是自动实现的。
（2）Apply Services
这个服务器用在备库上，其用来应用redo data，已保持主备库数据的一致性。Redo data 可以通过归档日志来应用，如果启用了real-time apply，当数据写入到standby redo log后，就会直接进行apply，不需要先在备库进行归档切换操作。
（3）Role Transitions
这个服务用来控制主备库角色的切换，可以使用switchover 或者failover进行。

3.4.3.1 Redo Transport Services
Redo transport services 执行如下工作：
（1）根据参数中的配置，把主库的redo data 传送到备库。
（2）管理gap的进程。
（3）自动检测备库上缺失或者损坏的归档文件，如果检测到就把这些归档日志重新发送一次。

3.4.3.2 Apply Services
Redo data 从主库传到备库并写入备库的standby redo log。 Apply services 会自动的在备库上应用这些redo data来维护主备库数据的一致性。 在11g中也可以已只读的方式访问备库。

3.4.3.2.1 物理standby 使用Redo apply(图)
物理standby 使用的Redo apply技术。 Redo apply使用的是数据库标准的恢复技术。基于block的恢复。

3.4.3.2.2 逻辑standby 使用SQL apply(图)

3.4.3.3 Role Transitions
3.4.3.3.1 SWITCHOVER
switchover将一个physical standby database 转换成为primary database，这个过程可以保证无数据丢失，在完成后其它的standby数据库和原来的primary库还可以成为这个dataguard的standby role的一部分.

3.4.3.3.2 FAILOVER

3.4.4 DG 的保护模式
Data Guard 允许定义3钟数据保护模式，分别是最大保护（Maximum Protection），最大可用（Maximum Availability）和 最大性能（Maximum Performance

3.4.4.1. 最大保护（Maximum Protection）
这种模式能够确保绝无数据丢失。要实现这一步当然是有代价的，它要求所有的事务在提交前其REDO不仅被写入到本地的Online Redo logs，还要同时写入到Standby数据库的Standby Redo logs，并确认REDO数据至少在一个Standby数据库中可用（如果有多个的话），然后才会在Primary数据库上提交。
使用这种方式要求Standby Database 必须配置Standby Redo Log，而Primary Database必须使用LGWR，SYNC，AFFIRM 方式归档到Standby Database.

3.4.4.2. 最高可用性（Maximum availability）
这种模式在不影响Primary数据库可用前提下，提供最高级别的数据保护策略。其实现方式与最大保护模式类似，也是要求本地事务在提交前必须至少写入一台Standby数据库的Standby Redologs中，不过与最大保护模式不同。
如果出现故障导致Standby数据库无法访问，Primary数据库并不会被Shutdown(10G是Shutdown，11G是hang住)，而是自动转为最高性能模式，等Standby数据库恢复正常之后，Primary数据库又会自动转换成最高可用性模式。
这种方式要求Standby Database 必须配置Standby Redo Log，而Primary Database必须使用LGWR，SYNC，AFFIRM 方式归档到Standby Database.

3.4.4.3. 最高性能（Maximum performance）
缺省模式。 这种模式在不影响Primary数据库性能前提下，提供最高级别的数据保护策略。事务可以随时提交，当前Primary数据库的REDO数据至少需要写入一个Standby数据库，不过这种写入可以是不同步的。如果网络条件理想的话，这种模式能够提供类似最高可用性的数据保护，而仅对Primary数据库的性能有轻微影响。这也是创建Standby数据库时，系统的默认保护模式。
这种方式可以使用LGWR ASYNC 或者 ARCH 进程实现，Standby Database也不要求使用Standby Redo Log。

3.4.4.4. 修改数据保护模式步骤
1）关闭数据库，重启到Mount 状态，如果是RAC，需要关闭所有实例，然后只启动一个实例到mount状态。
2）修改模式：
语法：
ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {PROTECTION | AVAILABILITY | PERFORMANCE};
如：SQL>ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION;
3) 打开数据库： alter database open;
4) 确认修改数据保护模式：
SQL>select protection_mode,protection_level from v$database;

3.4.5 Data Guard Broker

3.5 DG Services 详解 -- Redo Transport Services
3.5.1 什么是Redo Transport Services
Redo transport services 在不同Oracle 数据库之间自动传送redo data。 注意这里强调的是redo data不是redo log。
Redo transport services 可以将Redo data传送到如下位置：
（1）Oracle Data Guard standby databases
（2）Archive Log repository –Archive log 仓库
（3）Oracle Streams downstream capture databases（废弃）

（1）Synchronous ---同步传送
同步日志传送模式会与事务提交保持一致。 只有当所有的日志都被成功的传送到了目标后，本地的事务才能commit。
(2) Asynchronous  --- 异步传送
异步传送日志采用异步的传送事务信息。 主库的事务可以提交，不用等待日志同时成功写入目标库。 而是采用异步的方式来传送归档。 这种方式灵活性就增加很多。
异步传送在Maximum Performance模式下使用。

3.5.2 如何配置 Redo Transport Services
3.5.2.1 Redo Transport 的安全性
Redo transport 使用Oracle Net sessions来传送redo data。 这些redo 传送session 使用Secure Socket Layer (SSL) 协议或者远程密码文件来进行验证。
3.5.2.2.1 使用SSL 认证Redo Transport
SSL 是一个产业标准的网络连接协议。 SSL 使用RSA 公用密码或者对称密码来提供验证，加密和数据完整性功能。
当Oracle Net能够匹配到LOG_ARCHIVE_DEST_n 和FAL_SERVER 初始化参数的值，那么就会使用SSL。

3.5.2.1.2 使用口令文件认证Redo Transport
Oracle的口令文件的作用是存放所有以sysdba或者sysoper权限连接数据库的用户的口令。

3.5.2.2 配置数据库发送Redo Data
初始化参数LOG_ARCHIVE_DEST_n用来指定redo log的存放位置，可以存放在本地，也可以指定redo transport的位置。 在oracle 11g中，该参数的n的值从1到31.
有另外一个初始化参数：LOG_ARCHIVE_DEST_STATE_n ，其与LOG_ARCHIVE_DEST_n 参数相对应。 (百度一下参数值)
log_archive_dest _3='SERVICE=path1 NOREOPEN ALTERNATE=LOG_ARCHIVE_DEST_4'
log_archive_dest _4='SERVICE=path2 NOREOPEN OPTIONAL'
log_archive_dest_state_3=ENABLE
log_archive_dest_state_4=ALTERNATE

DB_UNIQUE_NAME=BOSTON
LOG_ARCHIVE_CONFIG='DG_CONFIG=(BOSTON,CHICAGO,HARTFORD)'
LOG_ARCHIVE_DEST_2='SERVICE=CHICAGO ASYNC NOAFFIRM VALID_FOR=(ONLINE_LOGFILE,
PRIMARY_ROLE) REOPEN=60 COMPRESSION=ENABLE  DB_UNIQUE_NAME=CHICAGO'
LOG_ARCHIVE_DEST_STATE_2='ENABLE'
LOG_ARCHIVE_DEST_3='SERVICE=HARTFORD SYNC AFFIRM NET_TIMEOUT=30
VALID_FOR=(ONLINE_LOGFILE,PRIMARY_ROLE) REOPEN=60 COMPRESSION=ENABLE  
DB_UNIQUE_NAME=HARTFORD'
LOG_ARCHIVE_DEST_STATE_3='ENABLE'
LOG_ARCHIVE_DEST_2='SERVICE=CHICAGO ASYNC NOAFFIRM VALID_FOR=(ONLINE_LOGFILE,
PRIMARY_ROLE) REOPEN=60 COMPRESSION=ENABLE  DB_UNIQUE_NAME=CHICAGO' 

SERVICE: 这个是一个强制的属性，而且也必须是第一个属性值。SERVICE 指定Oracle Net Service Name。就是tnsnames.ora 里面配置的名称。
SYNC: 该属性用来指定使用同步redo transport mode来传送redo data 到destination。
ASYNC: 该属性来用指定使用异步的方式来传送redo data。 在没有指定SYNC 或ASYNC的情况下，默认使用ASYNC.
NET_TIMEOUT：该属性控制LGWR进程在中断网络连接之前等待网络服务进程状态的时间长短。如果在NET_TIMEOUT参数设置的值内还没有响应，LGWR进程就会返回错误信息。
在SYNC的模式下，Oracle 建议设置该值，这样就可以控制redo 同步的最大持续时间，减少对事务的影响。
AFFIRM:The AFFIRM attribute is used to specify that redo received from a redo source database is not acknowledged until it has been written to the standby redo log.
NOAFFIRM ：The NOAFFIRM attribute is used to specify that received redo is acknowledged without waiting for received redo to be written to the standby redo log.
AFFIRM：确保备库从主库接受到的redo log由LGWR进程完全写入磁盘之后进行提交，NOAFFIRM则与之相反。
AFFIRM：在日志写进程进行之前，所以的归档日志和备库日志必须同步写完
NOFFIRM:在主库的日志写进程不等所有磁盘IO完成
缺省的是NOFFIRM
DB_UNIQUE_NAME：该属性用来指定redo transport destination。如果LOG_ARCHIVE_CONFIG 参数和DG_CONFIG属性已经配置，那么该属性必须指定，并且该值也必须匹配DG_CONFIG中的一个值。 如果匹配失败，就不会传送日志。
VALID_FOR: 该属性用来控制日志传输的，即角色转换方面。VALID_FOR允许同时为主备库数据库角色配置目的地属性，使DG切换后能正常工作。简化切换和故障转移。默认valid_for＝(all_logfiles,all_roles)
格式：VALID_FOR=(redo_log_type,database_role)
redo_log_type包括：online_logfile、standby_logfile、all_logfiles
database_role包括：primary_role、standby_role、all_roles
REOPEN：该属性来用指定在之前ARCn 进程或LGWR 进程在错误过后多少秒之后重新连接并传送日志。
COMPRESSION： 该属性指定是否已压缩的形式传送日志。 压缩传送可以提高性能，降低对带宽的影响。

 V$ARCHIVE_DEST --DG中这个视图最重要
 
3.5.2.2 配置数据库接收Redo Data 
3.5.2.2.1 创建和管理Standby Redo Log
同步传送和异步传送REDO 都需要standby 需要standby redo log，用来存储从其他database 接受来的redo data。
通过redo transport 传送到Standby database 的redo数据由RFS 的前台进程写入到当前的standby redo log group。
当primay database 发生日志切换时，对应的redo 数据写入到standby的下一组standby redo log group，然后standby 的ARCn 进程对standby redo log group 进行归档操作
RFS（Remote File Server ）和ARCn。
RFS 进程是专门用来接受并将日志写入standby的current standby redo log的。
每个standby redo log file 至少要和primary database的redo log 一样大，为了方便管理，Oracle 建议主备库的redo log 设置成一样的大小。
Standby redo log group 至少要比primary database的redo log group 多一组。
--在primary 库执行如下SQL，确定每个redo log file的大小和每个log groups的成员数量：
SQL> SELECT GROUP#, BYTES FROM V$LOG;
--在standby 库执行执行如下SQL 查询每个standby redo log 大小和每组的成员：
SQL> SELECT GROUP#, BYTES FROM V$STANDBY_LOG;

3.5.2.2.2  Standby Redo Log 的归档配置
3.5.2.2.2.1 启用归档
如果没有启用归档，可是使用如下SQL启用归档：
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE ARCHIVELOG;
DG 环境下的主库必须是归档的。

3.5.2.2.2.2 设置Standby Redo Log 归档到FRA(fast recovery area)  --建议设置到文件系统中
设置步骤如下：
（1）设置LOG_ARCHIVE_DEST_n 参数的LOCATION 属性等于USE_DB_RECOVERY_FILE_DEST。
（2）设置LOG_ARCHIVE_DEST_n 参数的VALID_FOR 属性允许进行归档。
示例：
LOG_ARCHIVE_DEST_2 = 'LOCATION=USE_DB_RECOVERY_FILE_DEST
VALID_FOR=(STANDBY_LOGFILE,STANDBY_ROLE)'
LOG_ARCHIVE_DEST_STATE_2=ENABLE

3.5.2.2.2.3 设置Standby Redo Log 归档到本地文件系统
设置步骤如下：
（1） 设置 LOG_ARCHIVE_DEST_n 参数的LOCATION 属性。
（2） 设置LOG_ARCHIVE_DEST_n 参数的VALID_FOR 属性允许进行归档。
示例：
LOG_ARCHIVE_DEST_2 = 'LOCATION = /disk2/archive
VALID_FOR=(STANDBY_LOGFILE,STANDBY_ROLE)'
LOG_ARCHIVE_DEST_STATE_2=ENABLE

3.5.2.2.3 什么情况下Redo 直接写入归档文件
如果我们的standby redo log不可用，或者我们接收的redo 是为了解决redo gap的时候，那么这时候我们接收的redo data就会直接写入archived redo log。
具体写归档文件的位置就是LOG_ARCHIVE_DEST_n参数的LOCATION属性指定的。

3.5.3 Cascaded Redo Transport Destinations --- 级联Redo 传送
比如有1个主库A，2个备库：B，C。
那么日志传送A--->B—>C。 这个就是Cascaded Redo Transport。
Cascading 有如下2个限制：
（1）只有物理standby database 才可以做cascading standby。
（2）Data Guard broker不支持cascaded destinations。

3.5.3.1 配置 Cascaded Destination
配置cascaded destination的步骤如下：
（1）选择一个physical standby database 做为cascading standby database。
（2）在cascading standby database设置FAL_SERVER 参数为primary database或者其他直接从primary database接收redo的standby database。
（3）在cascading standby database设置LOG_ARCHIVE_DEST_n 参数指定cascaded destination，并指定其他有效参数。
（4）在cascaded destination database 设置FAL_SERVER参数为cascading standby database或者其他直接从primary database接收redo的standby database。
-- Primary Database：
DB_UNIQUE_NAME=boston
FAL_SERVER=boston2
LOG_ARCHIVE_CONFIG='DG_CONFIG=(boston,boston2,denver)'
LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST
VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=boston'
LOG_ARCHIVE_DEST_2='SERVICE=boston2 SYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=boston2'

--Cascading Physical Standby Database：
DB_UNIQUE_NAME=boston2
FAL_SERVER=boston
LOG_ARCHIVE_CONFIG= 'DG_CONFIG=(boston,boston2,denver)'
LOG_ARCHIVE_DEST_1='LOCATION= USE_DB_RECOVERY_FILE_DEST
VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=boston2'
LOG_ARCHIVE_DEST_2= 'SERVICE=denver
VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=denver'
 
--Cascaded Physical Standby Database：
DB_UNIQUE_NAME=denver
FAL_SERVER=boston2
LOG_ARCHIVE_CONFIG='DG_CONFIG=(boston,boston2,denver)'
LOG_ARCHIVE_DEST_1='LOCATION= USE_DB_RECOVERY_FILE_DEST
VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=denver'

3.5.4 监控 Redo Transport Services
3.5.4.1 监控Redo Transport Status
--检查最近的归档日志文件：
SQL> SELECT MAX(SEQUENCE#), THREAD# FROM V$ARCHIVED_LOG GROUP BY THREAD#;
--检查传输目的地路径及最近的归档情况：
SELECT DESTINATION,
       STATUS,
       ARCHIVED_THREAD#,
       ARCHIVED_SEQ#
  FROM V$ARCHIVE_DEST_STATUS
 WHERE STATUS <> 'DEFERRED' AND STATUS <> 'INACTIVE';

DESTINATION         STATUS  ARCHIVED_THREAD#  ARCHIVED_SEQ#
------------------  ------  ----------------  -------------
/private1/prmy/lad   VALID                 1            947
standby1             VALID                 1            947
--检查归档目的地已经接收到的归档日志情况：
SELECT LOCAL.THREAD#, LOCAL.SEQUENCE#
  FROM (SELECT THREAD#, SEQUENCE#
          FROM V$ARCHIVED_LOG
         WHERE DEST_ID = 1) LOCAL
 WHERE LOCAL.SEQUENCE# NOT IN
          (SELECT SEQUENCE#
             FROM V$ARCHIVED_LOG
            WHERE DEST_ID = 2 AND THREAD# = LOCAL.THREAD#);  --DEST_ID = 2要根据自己的配置改

3.5.4.2 监控同步传送Redo Transport的响应时间
V$REDO_DEST_RESP_HISTOGRAM 视图包含了每个redo transport destination的response time。
Response time 数据对同步传送数据实时传输时有帮助。也可以用来做NET_TIMEOUT的值调整时的参考。
V$REDO_DEST_RESP_HISTOGRAM 视图有4列：FREQUENCY, DURATION, DEST_ID, 和 TIME.
The FREQUENCY column contains the number of times that a given response time has been observed.
The DURATION column corresponds to the response time. 
The DEST_ID column identifies the destination.
The TIME column contains a timestamp taken when the row was last updated.
每个destination 都会包含一系列的记录。 每个记录都会有response time。 为了便于记录，当response time 会计算到实际值，如果超过300秒，就会用最接近600，1200，2400，4800，9600的值来代替。
--在主库查询destination=2 的response time 信息：
SQL> SELECT FREQUENCY, DURATION FROM V$REDO_DEST_RESP_HISTOGRAM WHERE DEST_ID=2 AND FREQUENCY>1;
--在主库查询destionation=2 最慢的响应时间：
SQL> SELECT max(DURATION) FROM V$REDO_DEST_RESP_HISTOGRAM WHERE DEST_ID=2 AND FREQUENCY>1;
--在主库查询destionation=2最快的响应时间：
SQL> SELECT min( DURATION) FROM V$REDO_DEST_RESP_HISTOGRAM WHERE DEST_ID=2 AND FREQUENCY>1;

3.5.4.3.1 手工解决 Gap 问题
3.5.4.3.2.1 解决物理standby Gap问题
在物理standby 库上执行如下SQL，判断是否存在gap：
SQL> SELECT * FROM V$ARCHIVE_GAP;
--把这些归档copy到物理standby，并使用ALTER DATABASE REGISTER LOGFILE应用这些归档：
SQL> ALTER DATABASE REGISTER LOGFILE '/physical_standby1/thread1_dest/arcr_1_7.arc';  --重新手工注册归档的语法

3.5.4.3.1.2 解决逻辑standby Gap问题
对于logical standby database，在logical standby database上查询DBA_LOGSTDBY_LOG视图。
SELECT THREAD#, SEQUENCE#, FILE_NAME FROM DBA_LOGSTDBY_LOG L WHERE NEXT_CHANGE# NOT IN
(SELECT FIRST_CHANGE# FROM DBA_LOGSTDBY_LOG WHERE L.THREAD# = THREAD#) ORDER BY THREAD#, SEQUENCE#;
SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE '/disk1/oracle/dbs/log-1292880008_7.arc'; --重新手工注册归档的语法

3.5.5 Oracle 10g中的Redo Data 是如何传送的
3.5.5.1 使用 Archiver (ARCn) 进程传送归档文件
默认情况下，Redo transport Service 使用ARCn 进程来归档online redo log。
注意一点，ARCn 进程的归档只支持DG的maximum performance 模式。 如果是最大保护和最高可用，就必须只用LGWR 进程来传送redo data 到standby 数据库。

3.5.2.1.1 控制ARCn的初始化参数
有2个初始化参数控制ARCn 进程的行为：LOG_ARCHIVE_DEST_n和LOG_ARCHIVE_MAX_PROCESSES。

3.5.2.1.2.1 启用ARCn 进程将日志归档到本地或者远程库
这个参数我们前面看过，就是LOG_ARCHIVE_DEST_n，它控制redo data的自动传送。 默认情况下就是使用ARCn 进程来发送redo data。 所以我们在LOG_ARCHIVE_DEST_n 参数中可以不用指定ARCH属性。 但必须指定SERVICE 属性。

3.5.2.1.1.2 指定ARCn 进程的数量
[oracle@dave ~]$ ps -ef|grep arc
LOG_ARCHIVE_MAX_PROCESSES 初始化参数指定ARCn 进程的最大数量。 该参数默认值是4. 即当我们primary instance 启动时，会创建4个ARCn 进程。 然后根据4个进程的负载情况，动态的分配4个进程的工作。 
LOG_ARCHIVE_MAX_PROCESSES 的最大值是30个。
ALTER SYSTEM SET LOG_ARCHIVE_MAX_PROCESSES = 8;  --修改语法，一般不要改

3.5.2.1.2 ARCn 进程处理归档的过程
priamry database 会发生归档的动作。
（1）在primary 数据库，当ARC0 进程完成online redo 的本地归档（LOG_ARCHIVE_DEST_1）动作之后， ARC1 进程就会把本地的归档文件传送到remote standby destination（LOG_ARCHIVE_DEST_2）。
（2）在standby 数据库，RFS(remote file server) 会接收这些归档文件，并将接收的redo data写入standby redo log file。 最后在从standby redo log file归档到standby 的归档文件中。
Standby 的apply service 使用Redo Apply（MRP） 或者SQL apply（LSP）从standby 的归档文件中应用数据，实现同步。
(核心图)

3.5.5.2 使用 Log Writer (LGWR) 进程传送 Redo Data
3.5.2.2.1 LGWR  的LOG_ARCHIVE_DEST_n 属性
（1） SYNC 属性会保证所有的数据都会同步，即每次写操作都会要求主备库同时完成。
（2） ASYNC 属性会执行异步的的同步，先写本地的online redo log ，在由LNS进程从online redo log传送redo data，因此可以立即返回给用户状态，而不需要等待备库的操作也完成。
3.5.2.2.2 LGWR SYNC 传送
使用LGWR SYNC 同步的示例：
LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago'
LOG_ARCHIVE_DEST_2='SERVICE=boston LGWR SYNC NET_TIMEOUT=30'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
LOG_ARCHIVE_DEST_n  参数的SYNC 属性是可选的。 因为LGWR 传送默认就是使用SYNC的方式。 因为是同步传送，所以建议设置NET_TIMEOUT属性。 从而控制LGWR 等待redo data写入standby的时间，如果在NET_TIMEOUT时间内没有反应，LGWR就会返回错误。
（1）主库，LGWR 进程提交redo data 到一个或者多个LNSn 进程，然后初始这些进程并行的发送redo data到远程数据。 主库的事务不会提交，直到所有的redo data 发送到所有的LGWR SYNC的目的地。
从这点看，很依赖与网络。
（2）备库，RFS接收LGWR发送过来的数据，然后写入standby redo log files。
(核心图)

3.5.2.2.3 LGWR ASYNC 传送
(核心图)

使用LGWR SYNC 同步的示例：
LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago'
LOG_ARCHIVE_DEST_2='SERVICE=boston LGWR SYNC NET_TIMEOUT=30'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE

使用LGWR ASYNC 同步的示例：
LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago'
LOG_ARCHIVE_DEST_2='SERVICE=boston LGWR ASYNC'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE

3.6 DG Services 详解 -- Apply Services
3.6.1 什么是 Apply Services
Apply service  可以自动在备库应用接收的redo data，从而维护主备库的同步。
默认情况下，只有当standby redo log 归档以后，apply services 才会去apply 这些信息。
如果启用了real-time apply, apply services 就会直接apply current standby redo 里的数据，有数据过来，就直接apply，而不需要等待归档后才开始apply。
（1）Redo Apply (physical standby databases only)
使用media recovery 来保持主库和物理standby 库的同步。
（2）SQL Apply (logical standby databases only)
从接收的redo data中重新构建出SQL 语句，然后在logical standby 上执行这些SQL 语句来实现同步。
Standby Database  上Apply Service 对应的进程：
（1） 如果是physical standby database，那么就是由MRP(Managed Recovery Process)进程来负责Redo Apply 日志。
（2） 如果是logical standby database，那么就是由LSP（Logical Standby Process）进程来负责SQL Apply。

3.6.2 Apply Services 的配置选项
3.6.2.1 使用 Real-Time Apply 实现redo data 实时apply
(1) physical standby databases：
SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE;

(2)logical standby databases：
SQL>ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

3.6.2.2 指定备库归档延时apply
3.6.2.2.1 设置 Time Delay
我们可以在primary database 和standby database 的LOG_ARCHIVE_DEST_n 参数中设置DELAY=minutes 属性。
默认的DELAY=30 分钟。
3.6.2.2.2 取消 Time Delay
（1）对于physical standby database：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY;

（2）对于logical standby database：
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NODELAY;

3.6.3 在Physical Standby Databases 应用Redo data
3.6.3.1 启动 Redo Apply
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE;  --命令
alter database recover managed standby database disconnect from session;  --平时用这个
alter database recover managed standby database using current logfile disconnect from session;  --启动实时应用

3.6.3.2 停止 Redo Apply
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
如果最后是finish，DG就完蛋了

3.6.3.3 监控 Primary, Physical, Snapshot Standby Databases 的应用
V$DATABASE
V$MANAGED_STANDBY --重要
V$ARCHIVED_LOG   --重要
V$LOG_HISTORY
V$DATAGUARD_STATUS
V$ARCHIVE_DEST  --重要

select process,status from V$MANAGED_STANDBY;  --备库查
select dest_name,status,error from V$ARCHIVE_DEST; --主库查，看有没有eeror
select sequence#,applied from V$ARCHIVED_LOG;  --主库和备库查

3.6.4 在 Logical Standby Databases 应用Redo Data
3.6.4.1 启动 SQL Apply
--在logical standby database上执行如下命令：
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY;

--启动real-time apply并立即进行apply 操作：
SQL>  ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

3.6.4.2 停止 SQL Apply

--执行如下SQL，停止SQL Apply：
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;

怎么启动关闭DG。 --10G有顺序，11G没什么影响
主库：startup
备库：startup，启动MRP
监听
启动： 先备后主
关闭：先主后备

3.8 DG Services 详解 -- Role Transitions
3.5.1 什么是Role Transitions
（1）Switchover
Switchover 切换允许primary 和一个备库进行切换，并且这种切换没有数据丢失。
（2）Failover
当主库不可用或者没反应的时候，我们可以把备库激活成primary状态。 在备库激活之前，如果不是最大保护或者最高可用性的模式，那么可能就会有一些数据丢失。
如果主库已经启动了Flashback Database，可以将主库重新闪回到之前的状态，这样原来的主库就可以继续当作备库使用。

3.5.1.1 Role Transition 的准备工作
1. 验证主备库的配置信息，包括初始化参数，归档模式，standby redo logs 和online redo log。
2. 在主库查询V$ARCHIVE_DEST_STATUS 视图，验证备库没有redo 传输错误 或者redo gap。
3. 确保主备库Temp 表空间一致。
4. 移除standby 上任何delay apply redo 的设置。
5. 如果是将RAC 主库切换到物理备库，RAC 主库只能保留一个节点，其他节点要关闭，在switchover 完成以后在启动关闭的节点即可。
6. 如果备库是real-time apply 的物理standby，并且是read only 模式，在切换之前，建议先将备库启动到mount状态，而不是open状态，这样可以实现最快速的角色切换，而不需要在切换之前清除用户的session连接。

3.5.1.2 如果有多个standby，在Role Transition 时如何选择？
（1） standby 数据库的位置。
（2） standby database的性能，比如CPU,I/O，带宽等。
（3） 执行role transition 需要的时间,主要是看有多少redo data 需要apply。
（4） Standby 数据库的类型。

3.5.1.3 Switchover 说明
DG 的switchover 操作分2个步骤：
1. 将现主库切换成备库
2. 将原备库切换成主库。

3.5.1.4 Failover 说明
Failover 注意事项：
1）如果可能，在将备库激活之前，应该尽可能多的把主库的redo data 传送到备库，并应用。 这样可以减少数据丢失。
2）  maximum protection 模式不能进行Failover。

3.5.3 Physical Standby 的 switchover
3.5.3.1 验证主库能否切换成备库
在主库执行如下SQL查询：
SQL> select switchover_status from v$database;
3.5.3.2 将主库切换成备库
alter database commit to switchover to physical standby with session shutdown;
--如果想做DUBUG
oradebug setmypid;
alter database commit to switchover to physical standby with session shutdown;
oradebug tracefile_name;

3.5.3.3 Shut down 原主库并启动到mount状态：
select open_mode from v$database;
SQL> SHUTDOWN immediate;
SQL> STARTUP MOUNT;

3.5.3.4 验证原备库是否可以切换成主库
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;

3.5.3.5 将原备库切换成主库
SQL> alter database commit to switchover to primary with session shutdown;

select open_mode from v$database;
3.5.3.6 打开新主库
SQL> ALTER DATABASE OPEN;

3.5.3.7 在新的物理standby 上启动REDO APPLY
SQL> alter database recover managed standby database disconnect from session;

3.5.3.8 验证
alter system switch logfile;
select sequence#,applied from v$archived_log;

清除控制文件中国企的archived_log历史记录。
SQL> execute sys.dbms_backup_restore.resetCfileSection(11);

--如果遇到错误
ORA-10456: cannot open standby database; media recovery session may be in
[oracle@ogg1 dirprm]$ oerr ora 10456
10456, 00000, "cannot open standby database; media recovery session may be in progress"
// *Cause:  A media recovery, RMAN, or flashback database session may have
//          been in progress on a mounted instance of a standby database
//          when an attempt was made to open the standby database.
// *Action: Check for and cancel any conflicting recovery session and open
//          the standby database.
//
progress

3.5.2.2 Oracle 10g中的Failover
3.5.2.2.1 Failover 如何才能做到零数据丢失？ ----把onlin log拷贝过去

3.5.2.2.2.1 处理归档日志GAP   -- 一般Failover
select thread#, low_sequence#, high_sequence# from v$archive_gap;
--1.主库执行看看有没有GAP：
sql> select thread#, low_sequence#, high_sequence# from v$archive_gap;
--2.把归档文件拷贝到备库，手工注册归档文件
alter database register physical logfile 'log_file_path';

3.5.2.2.1.2 处理online redo log   -- 强制Failover
1）。把所有online redo log 都copy过去。
2） 用rman 来处理
具体操作步骤如下：
SQL> alter database recover managed standby database cancel;  --取消APPLY
SQL> recover standby database until cancel;    --恢复
SQL> recover standby database until cancel;
ORA-00279: change 509016 generated at 11/05/2010 11:40:27 needed for thread 1
ORA-00289: suggestion : /u01/archive/1_17_734225750.dbf
ORA-00280: change 509016 for thread 1 is in sequence #17

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/u01/app/oracle/oradata/orcl/redo01.log   -- 注意， 这个位置是我手动写的
Log applied.
Media recovery complete.

当我们使用了recover standby database until cancel之后，只能使用强制激活备库，如果使用正常模式，会提示我们需要：
ORA-16139: media recovery required

3.5.2.2.2 正常的Failover – 没有GAP 问题
3.5.2.2.2.1 检查Gap
3.5.2.2.2.2 解决gap问题后，进行切换
--取消Apply Service：
SQL> recover managed standby database cancel;
SQL> alter database recover managed standby database finish;
--在oracle 10gR2之前的版本：没有备库日志文件：
SQL> alter database recover managed standby database finish skip standby logfile;
3.5.2.2.2.3 将备库切换成主库
SQL> alter database commit to switchover to primary;
SQL> shutdown immediate;
SQL> startup

3.5.2.2.3  强行切换（激活）  --有GAP问题
当我们正常切换的时候，提示我们需要介质恢复的时候，就需要使用强行激活standby 库。 如：
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY
*
ERROR at line 1:
ORA-16139: media recovery required
3.5.2.2.3.2 强行激活下的 redo 问题
3.5.2.2.3.3 强制激活备库
sql> alter database recover managed standby database cancel;
sql> recover standby database until cancel;
sql>alter database activate standby database;
sql>shutdown immediate;
sql>startup

3.5.2.2 Oracle 11g中的Failover 步骤
3.5.2.2.1   将原主库还未发送的Redo data 刷到备库
一般做Failover 切换都是主库发生了故障，出现问题，但只要主库能够启动到mount 状态，那么就可以将任何没有发送的归档和current online redo log 刷到备库上去，只要Flush成功，Failover 也不会有数据丢失。
SQL> ALTER SYSTEM FLUSH REDO TO 'study_st';
3.5.2.2.2   验证备库最近接收的归档信息
SQL> SELECT UNIQUE THREAD# AS THREAD, MAX(SEQUENCE#) OVER (PARTITION BY thread#) AS LAST from V$ARCHIVED_LOG;
SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';
3.5.2.2.3   确认并解决GAP
在备库查询V$ARCHIVE_GAP，确认是否存在GAP，如果有从主库copy过来，注册一下。

SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
3.5.2.2.4   重复第三部，直到没有GAP问题
3.5.2.2.5   停止 Redo Apply.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
3.5.2.2.6   结束Apply 所有的Redo data
在备库执行如下SQL,结束所有的Apply：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;

3.5.2.2.7   验证备库是否可以切换成主库
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
3.5.2.2.8  将备库切换成主库
执行如下SQL 完成切换：
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;
3.5.2.2.9   打开新主库
SQL> ALTER DATABASE OPEN;

3.5.2.2.12 强制Failover 示例
3.5.2.2.12.1 将主库启动到mount状态并FLUSH REDO
SQL> shutdown immediate
SQL> startup mount;
SQL> alter system flush redo to 'dave_st';
System altered.
3.5.2.2.12.2 查看备库归档及GAP问题
3.5.2.2.12.3 停止 Redo Apply 并强制激活备库

SQL> alter database recover managed standby database cancel;

Database altered.

SQL> alter database activate physical standby database;

Database altered.

SQL>

3.5.2.2.12.4 打开数据库
SQL> alter database open;

3.9 使用Active Data Guard 搭建物理Data Guard
3.9.1 DG 环境说明

rman target sys/123456@study_pd auxiliary sys/123456@study_st;

3.10 Data Guard 的数据保护级别与性能关系
3.10.1 Data Guard 保护模式
3.10.1.1 Maximum Availability  --- 最大可用性
主库的事务不能提交，直到所有需要恢复的redo data成功写入online redo log 和至少一个standby redo log。
3.10.1.2 Maximum Performance  --- 最大性能（默认）
3.10.1.3 Maximum Protection --- 最大保护
3.10.1.4  三种模式对比
3.10.1.4.1. 最大保护模式
1）这种模式提供了最高级别的数据保护能力；
2）要求至少一个物理备库收到重做日志后，主库的事务才能够提交；
3）主库找不到合适的备库写入时，主库会hang住，防止未受保护的数据出现；
4）优点：该模式可以保证备库没有数据丢失；
5）缺点：主库的自动关闭会影响到主库的可用性，同时需要备库恢复后才能提交，对网络等客观条件要求非常的高，主库的性能会因此受到非常大的冲击。
3.10.1.4.2.最大可用性模式
1）该模式提供了仅次于“最大保护模式”的数据保护能力；
2）要求至少一个物理备库收到重做日志后，主库的事务才能够提交；
3）主库找不到合适的备库写入时，主库不会关闭，而是临时降低到“最大性能模式”模式，直到问题得到处理；
4）优点：该模式可以在没有问题出现的情况下，保证备库没有数据丢失，是一种折中的方法；
5）缺点：在正常运行的过程中缺点是主库的性能受到诸多因素的影响。
3.10.1.4.3.最大性能模式
1）该模式是默认模式，可以保证主数据库的最高可用性；
2）保证主库运行过程中不受备库的影响，主库事务正常提交，不因备库的任何问题影响到主库的运行；
4）优点：避免了备库对主数据库的性能和可用性影响；
5）缺点：如果与主库提交的事务相关的恢复数据没有发送到备库，这些事务数据将被丢失，不能保证数据无损失；

3.10.2  设置主库的保护模式
3.10.2.1 查询当前的保护模式
SQL> SELECT PROTECTION_MODE, PROTECTION_LEVEL, DATABASE_ROLE ROLE, SWITCHOVER_STATUS FROM V$DATABASE;

3.10.2.2 不同数据保护模式对redo transport 的要求
(图)

3.10.2.3 验证参数是否设置DB_UNIQUE_NAME
主库和备库的参数log_archive_dest_n 参数都需要指定DB_UNIQUE_NAME。
3.10.2.4  验证LOG_ARCHIVE_CONFIG 参数
3.10.2.5 设置数据库的保护模式
在主库执行如下SQL，切换保护模式：
SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {AVAILABILITY | PERFORMANCE | PROTECTION};

3.10.2.7 切换保护模式示例
3.10.2.7.1 主库查看当前的保护模式 
SQL> select protection_mode, protection_level, database_role role, switchover_status from v$database;
3.10.2.7.22 将主库模式切换到最大可用性
保护模式按如下顺序改变时可以在主库open状态执行：
maximize protection -->  maximize availability --> maximize performance
当在把dataguard的保护级别按这上面的顺序减低的时候， 不需要primary库在mount状态，否则primary 必须在mount 状态。

--操作,只需要主库操作
SQL> alter database set standby database to maximize availability;
SQL> select protection_mode, protection_level, database_role role, switchover_status from v$database;
SQL> alter system set log_archive_dest_2='service=study_st lgwr affirm sync valid_for=(online_logfiles,primary_role) db_unique_name=study_st';

--切换最大保护：
SQL> alter database set standby database to maximize protection;

--关闭备库：会报错。除非shutdown abort
SQL> shutdown immediate;

3.11 Data Guard 是否支持异构平台？
3.11.1 概述
3.11.2 查看主备库的Platform ID
select platform_id, platform_name from v$database;
3.11.3 word-size 问题的影响
这里的word-size 只的是数据库的位数，是32位还是64位。
3.11.4 DG 主备库兼容性具体规则表
（图）

3.12 如何管理物理standby
3.12.2 物理备库Real-time query说明
3.12.2.1 实时查询
sql> alter database recover managed standby database cancel;
sql> alter database recover managed standby database using current logfile disconnect from session;
SQL> SELECT open_mode FROM V$DATABASE;

3.12.2.2 在real-time query下监控Apply Lag
select name, value, datum_time, time_computed from v$dataguard_stats where name like 'apply lag';
DATUM_TIME 列指备库最后接收redo data的时间。
VALUE: Value of the parameter. For example, the APPLY FINISH TIME parameter value +00 00:00:01.7 indicates the standby database needs 1.7 seconds to finish applying the remaining redo data.
TIME_COMPUTED 列指apply lag metric的计算时间。这里的时间与DATUM_TIME 的差距要小于30秒，如果超过过30秒，那么这里的apply lag metric就不准确了。

可以通过V$STANDBY_EVENT_HISTOGRAM 视图查询从备库启动以后apply lag 的历史信息：
SQL> col name for a15
SQL> select * from v$standby_event_histogram where name = 'apply lag' and count > 0;

3.12.2.3 配置Real-time Query 下的Apply Lag 延时时间
STANDBY_MAX_DATA_DELAY参数用来指定session 级别的apply lag 允许延时的最大值，单位是秒。
STANDBY_MAX_DATA_DELAY参数默认为NONE，如果STANDBY_MAX_DATA_DELAY为NONE，那么我们在备库就可以随便查询，不用关心apply lag的问题，但这样也就是不能保证主备库数据的一致性
如果设置STANDBY_MAX_DATA_DELAY为非0值，那么备库的查询操作仅当apply lag值小于等于STANDBY_MAX_DATA_DELAY时才可以查询，否则客户端就会返回ORA-3172的错误。
使用SQL 修改该参数的命令如下：
SQL> ALTER SESSION SET STANDBY_MAX_DATA_DELAY=2

自动修复坏块功能
如果物理备库启动了Real-time query，那么就可以用来自动修复主库的坏块。
如果我们主库发现了坏块，那么就会自动从启用real-time query的物理备库上把正常的数据块copy 过来，并替换主库掉坏的block。
当然这里的前提是主库使用了SYNC来进行数据同步，不然数据就不一致了。
如果不能自动修复，就会报ORA-1578的错误。

手工修复坏块
RMAN 的recover block命令用来手工修复坏块。 在DG 环境下，这个命令会搜索可用的locations来修复。 默认情况下，如果物理备库是real-time query 模式，那么也会使用物理备库来修复。
如果在RMAN的block recover 命令中加上exclude standby 选项，就不会在把standby database 作为一个可替换block的源地址。

3.12.3 主库的哪些操作需要手工的同步的物理
3.12.3.1 添加数据文件或者创建表空间
（1）如果物理备库的STANDBY_FILE_MANAGEMENT 参数设置为AUTO，主库上添加任何的数据文件都会自动同步到物理standby。
（2）如果物理备库的STANDBY_FILE_MANAGEMENT 参数设置为MANUAL，那么主库添加的数据文件必须手工在备库添加。
思考：如果是从其他数据库copy 的数据文件到主库，那么该如何处理？
在这种情况下，STANDBY_FILE_MANAGEMENT参数就不管用了。那么也必须将这个数据文件copy 到备库，同时要重建standby control file(从主库)。

3.12.3.1.1 Raw 设备下的STANDBY_FILE_MANAGEMENT 参数
在前面说在备库设置STANDBY_FILE_MANAGEMENT参数为AUTO，那么在主库添加和删除数据都会自动同步到备库，而不需要主库的干预。 这里的前提就是使用的是文件系统。

如果使用的是raw设备，STANDBY_FILE_MANAGEMENT 仍然可以继续使用，但是就需要DBA手工的进行干预。

如果我们在主库添加了一个raw的数据文件，那么也必须在备库也创建一个同名raw设备，否则Redo Apply 就会报错。
助教-D83-月读(351699974)9:38:59
 
3.12.3.1.2 解决备库没有创建raw文件导致的Redo Apply 停止问题
1. 在备库创建raw设备，并对oracle 用户分配权限。
2.查询v$datafile 视图，确定当前的数据文件信息：

ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=MANUAL;
 ALTER DATABASE CREATE DATAFILE '/u01/app/oracle/product/10.1.0/dbs/UNNAMED00007' AS '/dev/raw/raw101';
在备库将STANDBY_FILE_MANAGEMENT修改成AUTO，并重启Redo Apply：
SQL> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO;
SQL> RECOVER MANAGED STANDBY DATABASE DISCONNECT;

3.12.3.2 Drop 表空间和删除数据文件
在主库drop 表空间或者delete 数据文件的时候，会自动同步到物理备库。
3.12.3.3 在物理standby 情况下使用Transportable Tablespaces
Oracle Transportable TableSpace(TTS) 传输表空间 说明
http://blog.csdn.net/tianlesoftware/article/details/7267582

Oracle 传输表空间（Transportable Tablespaces） 示例（一） -- 跨操作系统迁移表空间 （endianness 格式相同）
http://blog.csdn.net/tianlesoftware/article/details/7299283

Oracle 传输表空间（Transportable Tablespaces） 示例（二） -- 跨操作系统迁移表空间（endianness格式不同）
http://blog.csdn.net/tianlesoftware/article/details/7299696
我们这里主要看一下在DG 环境下如何使用传输表空间。
步骤如下：
1. 使用expdp工具导出表空间的结构信息。
2. 复制数据库对应的数据文件和expdp 的dump 文件到主库。 复制数据文件到备库。
3. 在主库调用impdp导出表空间的结构信息。主库生产的Redo data 会自动传送到备库并应用。

3.12.3.4 Rename 主库的DataFile
当我们在主库rename 一个或者多个数据文件时，这些改变不会同步到备库。 因此我们需要手工的在备库执行这些rename操作。
create tablespace dave datafile '/s01/oracle/oradata/study/dave01.dbf' size 10m;

1.在主库offline 表空间
SQL> alter tablespace dave offline;
Tablespace altered.

2.在操作系统层面将数据文件移动到其他位置
[oracle@dg1 ~]$ mv /s01/oracle/oradata/study/dave01.dbf /s01/dave01.dbf

3.在主库rename 数据文件并将表空间改成online状态

SQL>alter tablespace dave rename datafile '/s01/oracle/oradata/study/dave01.dbf' to '/s01/dave01.dbf';
Tablespace altered.

SQL> alter tablespace dave online;
Tablespace altered.

SQL>

4. 在备库取消MRP
SQL> alter database recover managed standby database cancel;
Database altered.

5.shutdown 备库

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.

3.移动备库的数据文件

注意我这里主备库的路径是不一样的。
[oracle@dg2 oradata]$ mv /u02/oradata/dave01.dbf /u01/dave01.dbf

7. 将备库启动到mount状态

SQL> startup mount
ORACLE instance started.

Total System Global Area  814227456 bytes
Fixed Size                  2232760 bytes
Variable Size             457182792 bytes
Database Buffers          352321536 bytes
Redo Buffers                2490368 bytes
Database mounted.
SQL>

8.在备库进行rename操作

/u02/oradata/dave01.dbf /u01/dave01.dbf

SQL> alter database rename file '/u02/oradata/dave01.dbf' to '/u01/dave01.dbf';
alter database rename file '/u02/oradata/dave01.dbf' to '/u01/dave01.dbf'
*
ERROR at line 1:
ORA-01511: error in renaming log/data files
ORA-01275: Operation RENAME is not allowed if standby file management is automatic.

SQL> alter system set STANDBY_FILE_MANAGEMENT=manual;
System altered.

SQL> alter database rename file '/u02/oradata/dave01.dbf' to '/u01/dave01.dbf';
Database altered.

SQL> alter system set STANDBY_FILE_MANAGEMENT=auto;
System altered.

SQL>

9.在备库启动Redo Apply
SQL>alter database open;
SQL> alter database recover managed standby database disconnect from session;
Database altered.

SQL>

3.12.3.5 添加删除Redo log Files Group
在主库上，Redo log 和standby redo log 需要根据实际的需要来进行添加或者删除。

如果是在备库上进行添加或者删除，需要按照如下步骤来操作：
1.停止Redo Apply。

2.如果STANDBY_FILE_MANAGEMENT参数为AUTO，设置为MANUAL。
SQL> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=MANUAL;

3.添加或者删除log file group。

4.还原STANDBY_FILE_MANAGEMENT参数为AUTO.

5.启动Redo Apply。

3.12.4 监控DG 状态
（1） V$DATABASE
（2） V$MANAGED_STANDBY
（3） V$ARCHIVED_LOG
（4） V$LOG_HISTORY
（5） V$DATAGUARD_STATUS

3.13 如何创建和管理Snapshot Standby Databases
3.13.1．Snapshot standby database 说明
3.13.2.1 snapshot standby 概述

3.13 如何创建和管理Snapshot Standby Databases

3.13.1．Snapshot standby database 说明

3.13.2.1 snapshot standby 概述
在oracle 11g中引入了第三种standby database： snapshot standby database。 所以在oracle 11g中有三种standby：
Physical standby
Logical standby
Snapshot standby 
Snapshot standby database 具有如下限制：

（1）Snapshot standby 数据库不能进行switchover 或者failover 操作。 在转换之前，也必须先从snapshot standby 转换成physical standby 以后才可以转换。
（2）Snapshot standby 不支持Maximum Protection 模式。 

3.13.1.2 snapshot standby database 到底是什么？
1）.Snapshot standby database是建立在物理standby 的基础上的。
2）.如果我们想在standby 库上做一些测试，因为主库我们不能动，我们可以在备库测。 那么我们就可以把这个standby 切换成snapshot standby。

切换语句如下：
SQL> alter database convert to snapshot standby;

切换之后，我们可以查看alert log，会发现里面有创建一个restore point:
Created guaranteed restore point snapshot_standby_required_xxx
3). 把snapshot standby 数据库打开，进行我们的测试。
SQL> alter database open;
4）. 测试完毕后，我们把数据库重启到mount 状态。

5） 执行命令将数据库从snapshot状态切换到之前的状态，如物理standby或者逻辑standby。
SQL> alter database convert to physical standby;

3.14.2．Snapshot standby database 操作示例
3.14.2.1.2 操作示例
在备库操作
--检查FRA 配置：
SQL> show parameter flashback

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_flashback_retention_target        integer     1440

SQL> show parameter db_recover

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest                string      /u01/app/oracle/fast_recovery_area
db_recovery_file_dest_size           big integer 4122M

--我们这里把FRA 设置大一点：
SQL> alter system set db_recovery_file_dest_size=10g scope=both;
System altered.

SQL> show parameter db_recover

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest                string      /u01/app/oracle/fast_recovery_area
db_recovery_file_dest_size           big integer 10G
SQL>

--停止Redo Apply：
SQL> select process,status from v$managed_standby;

alter database recover managed standby database cancel;

select process,status from v$managed_standby;

--将物理standby 转换成snapshot standby：

SQL> shutdown immediate;

SQL> startup mount;
SQL> alter database convert to snapshot standby;
SQL> alter database open;
SQL> select open_mode from v$database;
OPEN_MODE
--------------------
READ WRITE

3.14.2.2 使用 Snapshot Standby Database 进行测试
SQL> create table huaining as  select * from dba_objects;
SQL> select count(1) from huaining;

3.14.2.3 将 Snapshot Standby 转成 Physical Standby
SQL> shutdown immediate;
SQL> startup mount;
SQL> alter database convert to physical standby;
SQL> shutdown immediate
SQL> startup
--启用Redo Apply：
SQL> alter database recover managed standby database disconnect from session;
SQL> select process,status from v$managed_standby;
SQL> select count(1) from huaining;

3.14 如何配置Data Guard 归档删除策略？
3.14.1 Oracle Data Guard 主库 归档文件 删除策略
在Oracle 10g 后，RMAN提供了配置归档文件删除策略：   
configure archivelog deletion policy
该策略对应三个值：
（1）NONE ：设置为该值时，则不启用归档文件的删除策略。默认情况下就是NONE。
（2）APPLIED ON STANDBY ：设置为该值时，会强制检查待删除的log 是否已经在备库apply，只有apply后的log才能删除。
当通过附加的 DELETE INPUT 子句删除Standby数据库仍需要的日志时，会提示RMAN-08137错误。
不过仍然可以手动地通过 DELETE ARCHIVELOG 方式删除。
(3) SHIPPED TO ALL STANDBY:  当归档传送到备库就可以删除。
RMAN>configure archivelog deletion policy to shipped to all standby;
RMAN> configure archivelog deletion policy to applied on standby;

--如果报错RMAN-08591: WARNING: invalid archived log deletion policy
SQL>alter system set "_log_deletion_policy"=ALL scope=spfile sid='*';
设置该参数以后，DB 需要重启。

3.14.2 Oracle Data Guard 备库 归档文件 删除脚本
[oracle@qs-xezf-db2 scripts]$ cat del_st_archive.sh
#!/usr/bin/ksh
# created by tianlesoftware
# 2010/12/24
export ORACLE_HOME=/u01/app/oracle/product/10.2.0/db_1
export ORACLE_SID=xxxx
export SHELL_DIR=/u02/scripts
 
del_seq=`ls /u02/archivelog/|head -1|cut -f2 -d_`
echo $del_seq
$ORACLE_HOME/bin/sqlplus -s "user/pwd@sid_pd as sysdba" <<eof >/u02/scripts/max_sn.log
set head off;
set feedback;
select max(sequence#) from v/$log_history;
exit;
eof
max_sn=`cat /u02/scripts/max_sn.log|awk '{print $1}'|grep ^[0-9]`
max_sn=`expr $max_sn - 30`
-- 我这里是保留最近的30个归档文件，这个具体情况自己决定
echo $max_sn
while [ $del_seq -lt $max_sn ]
do
  rm /u02/archivelog/1_"$del_seq"_737806218.arc
-- 这里是我定义归档文件的格式，具体根据自己的归档文件格式来匹配，关键是匹配日志的sequence no。
  del_seq=`expr $del_seq + 1`
  echo $del_seq
done

添加到crontab，定时执行：
[oracle@qs-xezf-db2 scripts]$ crontab -l
00 6 * * * /u02/scripts/del_st_archive.sh >/u02/scripts/del_st_arch.log 2>&1

3.16 如何监控Data Guard 环境？
3.16.1 DG 监控脚本

3.15 Data Guard主库丢失archivelog，如何不重建备库？
3.15.2.1 停止备库的Redo Apply
SQL> alter database recover managed standby database cancel;
3.15.2.2 查询备库的FROM SCN 值
3.15.2.2.1 如果是归档缺失，在备库使用如下查询
SQL> SELECT CURRENT_SCN FROM V$DATABASE;

CURRENT_SCN
-----------
1579945

3.15.2.2.2 如果主库使用了nologging模式，在备库使用如下查询

SQL> select min(first_nonlogged_scn) from v$datafile where first_nonlogged_scn>0;

MIN(FIRST_NONLOGGED_SCN)
------------------------
                  223948

3.15.2.2.3 如果主库部分数据文件使用了nologging，在备库使用如下查询
SQL> select file#, first_nonlogged_scn from v$datafile where first_nonlogged_scn > 0;

FILE#      FIRST_NONLOGGED_SCN
---------- -------------------
         4              225979
         5              230184

3.15.2.2 在主库使用RMAN 基于SCN 的增量备份

3.15.2.2.1 如果归档缺失或者主库使用nologging模式，备份命令如下
RMAN> backup incremental from scn 1579945 database format '/u01/backup/forstandby_%u' tag 'forstandby';

3.15.2.2.2 如果部分数据文件使用nologging，备份命令如下

那只争对部分数据文件进行备份：
RMAN> BACKUP INCREMENTAL FROM SCN 225979 DATAFILE 4 FORMAT '/tmp/ForStandby_%U' TAG 'FORSTANDBY';
RMAN> BACKUP INCREMENTAL FROM SCN 230184 DATAFILE 5 FORMAT '/tmp/ForStandby_%U' TAG 'FORSTANDBY';
这里的FROM SCN 也是上面的部分查询。

3.15.2.4 将备份copy 到备库
[oracle@dg1 backup]$ scp forstandby* 192.165.2.20:/u01/backup

3.15.2.3 还原备库控制文件并执行恢复操作

我们这里使用的控制文件来保存归档的信息，所以这里必须指定控制问的具体在哪个备份集中，在我们的备份log中有显示：
/u01/backup/forstandby_0oo8daoa
RMAN> STARTUP NOMOUNT;
RMAN> RESTORE STANDBY CONTROLFILE FROM '/u01/backup/forstandby_0oo8daoa';
RMAN> ALTER DATABASE MOUNT;
RMAN> RECOVER DATABASE NOREDO;

3.15.2.8 启动备库的Redo Apply
SQL> alter database recover managed standby database disconnect from session;
3.15.2.9 验证DG 同步