在前三篇中我们解释了DG的基础知识及相关概念和原理，从这篇开始会从实战角度去演示物理逻辑备库的搭建、主备库切换、主备间库数据同步监控以及优化。本篇我们主要结合官方文档演示物理备库的创建过程。

在正式开始演示物理备库创建过程前，先描述一下测试环境：

Oracle VM VirtualBox + Oracle Linux 5.8
Host Name: 10g.localdomain
IP Address: 192.168.56.10
Oracle 10.2.0.5.12 DB + File System
Primary DB Name and Instance Nname: PROD
Standby DB Instance Nname: SBDB

注：以下演示过程由于是在笔记本虚拟机上进行测试，因此硬件虚拟资源有限，所以选择将主备库放在同一台虚拟主机上演示物理备库的搭建过程，但这并不影响演示过程及测试结果。

0.主备库准备工作

0.0 Create a primary DB with DB_NAME and SID PROD using DBCA
0.1 Enable PROD with archived mode using FRA
0.2 Add listeners and configure service name for the primary and standby databases
    netca --- Add Listener and Configure Service Name (PROD + SBDB)

1.主库操作过程及步骤

1.1 打开主库归档
SYS@PROD> ARCHIVE LOG LIST
Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     7
Next log sequence to archive   9
Current log sequence           9
 
1.2 开启主库闪回
SYS@PROD> SELECT FLASHBACK_ON FROM V$DATABASE;
 
FLASHBACK_ON
------------------
YES
 
1.3 强制主库写日志
SYS@PROD> ALTER DATABASE FORCE LOGGING;
 
Database altered.
 
1.4 配置Standby Redo Log
Step 1 确认主库redo log大小使其备库上保持一致
Step 2 决定standby redo log数目，计算方法：(maximum number of logfiles for each thread + 1) * maximum number of threads
SYS@PROD> SELECT L.GROUP#,L.THREAD#,L.MEMBERS,F.MEMBER,BYTES/1024/1024,L.STATUS FROM V$LOG L,V$LOGFILE F WHERE L.GROUP#=F.GROUP#;
 
    GROUP#    THREAD#    MEMBERS MEMBER                                             BYTES/1024/1024 STATUS
---------- ---------- ---------- -------------------------------------------------- --------------- ----------------
         1          1          1 /u01/app/oracle/oradata/PROD/redo01.log                         50 CURRENT
         2          1          1 /u01/app/oracle/oradata/PROD/redo02.log                         50 INACTIVE
         3          1          1 /u01/app/oracle/oradata/PROD/redo03.log                         50 INACTIVE
 
SYS@PROD> ALTER DATABASE ADD STANDBY LOGFILE GROUP 4 ('/u01/app/oracle/oradata/PROD/redo04.log') SIZE 50M;
 
Database altered.
 
SYS@PROD> ALTER DATABASE ADD STANDBY LOGFILE GROUP 5 ('/u01/app/oracle/oradata/PROD/redo05.log') SIZE 50M;
 
Database altered.
 
SYS@PROD> ALTER DATABASE ADD STANDBY LOGFILE GROUP 6 ('/u01/app/oracle/oradata/PROD/redo06.log') SIZE 50M;
 
Database altered.
 
SYS@PROD> ALTER DATABASE ADD STANDBY LOGFILE GROUP 7 ('/u01/app/oracle/oradata/PROD/redo07.log') SIZE 50M;
 
Database altered.
 
1.5 查看已添加成功的Standby Redo Log
SYS@PROD> SELECT GROUP#,THREAD#,SEQUENCE#,ARCHIVED,STATUS FROM V$STANDBY_LOG;
 
    GROUP#    THREAD#  SEQUENCE# ARC STATUS
---------- ---------- ---------- --- ----------
         4          0          0 YES UNASSIGNED
         5          0          0 YES UNASSIGNED
         6          0          0 YES UNASSIGNED
         7          0          0 YES UNASSIGNED
 
SYS@PROD> select * from v$logfile;
 
    GROUP# STATUS  TYPE    MEMBER                                             IS_
---------- ------- ------- -------------------------------------------------- ---
         1         ONLINE  /u01/app/oracle/oradata/PROD/redo01.log            NO
         2         ONLINE  /u01/app/oracle/oradata/PROD/redo02.log            NO
         3         ONLINE  /u01/app/oracle/oradata/PROD/redo03.log            NO
         4         STANDBY /u01/app/oracle/oradata/PROD/redo04.log            NO
         5         STANDBY /u01/app/oracle/oradata/PROD/redo05.log            NO
         6         STANDBY /u01/app/oracle/oradata/PROD/redo06.log            NO
         7         STANDBY /u01/app/oracle/oradata/PROD/redo07.log            NO
 
1.6 设置主库初始化参数
[oracle@10g dbs]$ cat initPROD.ora 
PROD.__db_cache_size=427819008
PROD.__java_pool_size=4194304
PROD.__large_pool_size=4194304
PROD.__shared_pool_size=155189248
PROD.__streams_pool_size=0
*.audit_file_dest='/u01/app/oracle/admin/PROD/adump'
*.background_dump_dest='/u01/app/oracle/admin/PROD/bdump'
*.compatible='10.2.0.5.0'
*.control_files='/u01/app/oracle/oradata/PROD/control01.ctl','/u01/app/oracle/oradata/PROD/control02.ctl','/u01/app/oracle/oradata/PROD/control03.ctl'
*.core_dump_dest='/u01/app/oracle/admin/PROD/cdump'
*.db_block_size=8192
*.db_domain=''
*.db_file_multiblock_read_count=16
*.db_name='PROD'
*.db_recovery_file_dest='/u01/app/oracle/flash_recovery_area'
*.db_recovery_file_dest_size=2147483648
*.job_queue_processes=10
*.open_cursors=300
*.pga_aggregate_target=199229440
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=597688320
*.undo_management='AUTO'
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='/u01/app/oracle/admin/PROD/udump'
###### Add Primary DB Initialization Parameters ######
DB_UNIQUE_NAME=PROD
LOG_ARCHIVE_CONFIG='DG_CONFIG=(PROD,SBDB)'
LOG_ARCHIVE_DEST_1=
 'LOCATION=USE_DB_RECOVERY_FILE_DEST
  VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
  DB_UNIQUE_NAME=PROD'
LOG_ARCHIVE_DEST_2=
 'SERVICE=SBDB LGWR ASYNC
  VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) 
  DB_UNIQUE_NAME=SBDB'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
LOG_ARCHIVE_FORMAT=%t_%s_%r.arc
LOG_ARCHIVE_MAX_PROCESSES=8
FAL_SERVER=SBDB
FAL_CLIENT=PROD
DB_FILE_NAME_CONVERT='SBDB','PROD'
LOG_FILE_NAME_CONVERT='SBDB','PROD'
STANDBY_FILE_MANAGEMENT=AUTO
关于主库初始化参数需要说明的几点：
①主库初始化参数中应去掉相关的shared server参数；
②参数文件中自###### Add Standby DB Initialization Parameters ######到文末内容粘贴官档修改；
③LOG_ARCHIVE_DEST_n定义了主库归档日志位置、主备库redo传输方式；
④DB_FILE_NAME_CONVERT及LOG_FILE_NAME_CONVERT定义了主备库数据文件及日志文件转换规则；
⑤STANDBY_FILE_MANAGEMENT定义了备库文件的管理方式。
 
1.7使用新初始化参数文件启动主库到mount状态使用RMAN冷备主库
SYS@PROD> alter system checkpoint;
 
System altered.
 
SYS@PROD> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
 
SYS@PROD> create spfile from pfile;
 
File created.
 
SYS@PROD> startup mount;
ORACLE instance started.
 
Total System Global Area  599785472 bytes
Fixed Size                  2098112 bytes
Variable Size             163580992 bytes
Database Buffers          427819008 bytes
Redo Buffers                6287360 bytes
Database mounted.
 
[oracle@10g ~]$ rman target /
 
Recovery Manager: Release 10.2.0.5.0 - Production on Thu Oct 24 11:17:12 2013
 
Copyright (c) 1982, 2007, Oracle.  All rights reserved.
 
connected to target database: PROD (DBID=241479471, not open)
 
RMAN> backup as compressed backupset full database plus archivelog delete input;
 
Starting backup at 24-OCT-13
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=159 devtype=DISK
specification does not match any archive log in the recovery catalog
backup cancelled because all files were skipped
Finished backup at 24-OCT-13
 
Starting backup at 24-OCT-13
using channel ORA_DISK_1
channel ORA_DISK_1: starting compressed full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00001 name=/u01/app/oracle/oradata/PROD/system01.dbf
input datafile fno=00002 name=/u01/app/oracle/oradata/PROD/undotbs01.dbf
input datafile fno=00003 name=/u01/app/oracle/oradata/PROD/sysaux01.dbf
input datafile fno=00004 name=/u01/app/oracle/oradata/PROD/users01.dbf
channel ORA_DISK_1: starting piece 1 at 24-OCT-13
channel ORA_DISK_1: finished piece 1 at 24-OCT-13
piece handle=/u01/app/oracle/flash_recovery_area/PROD/backupset/2013_10_24/o1_mf_nnndf_TAG20131024T111756_96k4c4j8_.bkp tag=TAG20131024T111756 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:15
channel ORA_DISK_1: starting compressed full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
including current control file in backupset
including current SPFILE in backupset
channel ORA_DISK_1: starting piece 1 at 24-OCT-13
channel ORA_DISK_1: finished piece 1 at 24-OCT-13
piece handle=/u01/app/oracle/flash_recovery_area/PROD/backupset/2013_10_24/o1_mf_ncsnf_TAG20131024T111756_96k4cnys_.bkp tag=TAG20131024T111756 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:02
Finished backup at 24-OCT-13
 
Starting backup at 24-OCT-13
using channel ORA_DISK_1
specification does not match any archive log in the recovery catalog
backup cancelled because all files were skipped
Finished backup at 24-OCT-13
注：由于主库使用FRA并开启闪回功能，因此归档及备份文件都放在FRA。
 
1.8 创建备库控制文件
SYS@PROD> ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/home/oracle/SBDB.ctl';
 
Database altered.
 
---到此主库配置完成。

2.物理备库创建过程及步骤

2.1在备库上创建与主库相同的目录结构
[oracle@10g ~]$ mkdir -p /u01/app/oracle/admin/SBDB/{a,b,c,u}dump
[oracle@10g ~]$ mkdir -p /u01/app/oracle/oradata/SBDB
[oracle@10g ~]$ mkdir -p /u01/app/oracle/flash_recovery_area/SBDB/archivelog
[oracle@10g ~]$ mkdir -p /u01/app/oracle/flash_recovery_area/SBDB/backupset
[oracle@10g ~]$ mkdir -p /u01/app/oracle/flash_recovery_area/SBDB/flashback
 
2.2拷贝主库密码文件到备库
[oracle@10g dbs]$ pwd
/u01/app/oracle/product/10.2.0/db_1/dbs
[oracle@10g dbs]$ cp orapwPROD orapwSBDB
 
2.3设置备库初始化参数文件
Step 1 拷贝主库初始化参数文件到备库
Step 2 修改参数文件如下
[oracle@10g dbs]$ cat initSDBD.ora 
SBDB.__db_cache_size=427819008
SBDB.__java_pool_size=4194304
SBDB.__large_pool_size=4194304
SBDB.__shared_pool_size=155189248
SBDB.__streams_pool_size=0
*.audit_file_dest='/u01/app/oracle/admin/SBDB/adump'
*.background_dump_dest='/u01/app/oracle/admin/SBDB/bdump'
*.compatible='10.2.0.5.0'
*.control_files='/u01/app/oracle/oradata/SBDB/control01.ctl','/u01/app/oracle/oradata/SBDB/control02.ctl','/u01/app/oracle/oradata/SBDB/control03.ctl'
*.core_dump_dest='/u01/app/oracle/admin/SBDB/cdump'
*.db_block_size=8192
*.db_domain=''
*.db_file_multiblock_read_count=16
*.db_name='PROD'
*.db_recovery_file_dest='/u01/app/oracle/flash_recovery_area'
*.db_recovery_file_dest_size=2147483648
*.job_queue_processes=10
*.open_cursors=300
*.pga_aggregate_target=199229440
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=597688320
*.undo_management='AUTO'
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='/u01/app/oracle/admin/SBDB/udump'
###### Add Standby DB Initialization Parameters ######
DB_UNIQUE_NAME=SBDB
LOG_ARCHIVE_CONFIG='DG_CONFIG=(PROD,SBDB)'
DB_FILE_NAME_CONVERT='PROD','SBDB'
LOG_FILE_NAME_CONVERT='PROD','SBDB'
LOG_ARCHIVE_FORMAT=log%t_%s_%r.arc
LOG_ARCHIVE_DEST_1=
 'LOCATION=USE_DB_RECOVERY_FILE_DEST
  VALID_FOR=(ALL_LOGFILES,ALL_ROLES) 
  DB_UNIQUE_NAME=SBDB'
LOG_ARCHIVE_DEST_2=
 'SERVICE=PROD LGWR ASYNC
  VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) 
  DB_UNIQUE_NAME=PROD'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
STANDBY_FILE_MANAGEMENT=AUTO
FAL_SERVER=PROD
FAL_CLIENT=SBDB
关于备库初始化参数需要说明的几点：
①将主库初始化参数文件拷贝改名后，使用vi打开将自###### Add Primary DB Initialization Parameters ######到文末删除，使用全局替换将除*.db_name='PROD'外所有PROD换成SBDB；
②参数文件中自###### Add Standby DB Initialization Parameters ######到文末内容粘贴官档修改；
③LOG_ARCHIVE_DEST_n定义了主库归档日志位置、主备库redo传输方式；
④DB_FILE_NAME_CONVERT及LOG_FILE_NAME_CONVERT定义了主备库数据文件及日志文件转换规则；
⑤STANDBY_FILE_MANAGEMENT定义了备库文件的管理方式。
 
2.4启动备库到nomount将主库RMAN全备恢复到备库上
SYS@SBDB> create spfile from pfile;
 
File created.
 
SYS@SBDB> startup nomount;
ORACLE instance started.
 
Total System Global Area  599785472 bytes
Fixed Size                  2098112 bytes
Variable Size             163580992 bytes
Database Buffers          427819008 bytes
Redo Buffers                6287360 bytes
 
[oracle@10g ~]$ export ORACLE_SID=SBDB
[oracle@10g ~]$ rman target /
 
Recovery Manager: Release 10.2.0.5.0 - Production on Thu Oct 24 11:30:24 2013
 
Copyright (c) 1982, 2007, Oracle.  All rights reserved.
 
connected to target database: PROD (not mounted)
 
RMAN> restore controlfile from '/home/oracle/SBDB.ctl';
 
Starting restore at 24-OCT-13
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=156 devtype=DISK
 
channel ORA_DISK_1: copied control file copy
output filename=/u01/app/oracle/oradata/SBDB/control01.ctl
output filename=/u01/app/oracle/oradata/SBDB/control02.ctl
output filename=/u01/app/oracle/oradata/SBDB/control03.ctl
Finished restore at 24-OCT-13
 
RMAN> run {
2> allocate channel c1 type disk;
3> set newname for datafile 1 to '/u01/app/oracle/oradata/SBDB/system01.dbf'; 
4> set newname for datafile 2 to '/u01/app/oracle/oradata/SBDB/undotbs01.dbf';
5> set newname for datafile 3 to '/u01/app/oracle/oradata/SBDB/sysaux01.dbf';
6> set newname for datafile 4 to '/u01/app/oracle/oradata/SBDB/users01.dbf';
7> set newname for tempfile 1 to '/u01/app/oracle/oradata/SBDB/temp01.dbf';
8> released channel c1;
9> }
 
allocated channel: c1
channel c1: sid=156 devtype=DISK
 
executing command: SET NEWNAME
 
executing command: SET NEWNAME
 
executing command: SET NEWNAME
 
executing command: SET NEWNAME
 
executing command: SET NEWNAME
released channel: c1
 
RMAN> restore database;
 
Starting restore at 24-OCT-13
Starting implicit crosscheck backup at 24-OCT-13
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=156 devtype=DISK
Crosschecked 11 objects
Finished implicit crosscheck backup at 24-OCT-13
 
Starting implicit crosscheck copy at 24-OCT-13
using channel ORA_DISK_1
Crosschecked 1 objects
Finished implicit crosscheck copy at 24-OCT-13
 
searching for all files in the recovery area
cataloging files...
no files cataloged
 
using channel ORA_DISK_1
 
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00001 to /u01/app/oracle/oradata/SBDB/system01.dbf
restoring datafile 00002 to /u01/app/oracle/oradata/SBDB/undotbs01.dbf
restoring datafile 00003 to /u01/app/oracle/oradata/SBDB/sysaux01.dbf
restoring datafile 00004 to /u01/app/oracle/oradata/SBDB/users01.dbf
channel ORA_DISK_1: reading from backup piece /u01/app/oracle/flash_recovery_area/PROD/backupset/2013_10_24/o1_mf_nnndf_TAG20131024T111756_96k4c4j8_.bkp
channel ORA_DISK_1: restored backup piece 1
piece handle=/u01/app/oracle/flash_recovery_area/PROD/backupset/2013_10_24/o1_mf_nnndf_TAG20131024T111756_96k4c4j8_.bkp tag=TAG20131024T111756
channel ORA_DISK_1: restore complete, elapsed time: 00:00:35
Finished restore at 24-OCT-13
关于将主库RMAN全备恢复到备库上的几点说明：
①由于主库使用RMAN做冷全备份，因此在备库上使用RMAN恢复时只需要执行restore；
②由于主库数据文件等命名与备库不同，因此在备库上使用RMAN恢复时需要在RUN块中执行set newname for命令转换；
③如果不清楚RMAN异机恢复过程建议查阅官方文档。
 
2.5检查备库是否恢复完成
SYS@PROD> select * from v$log;
 
    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIM
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ---------
         1          1         13   52428800          1 YES INACTIVE                183935 24-OCT-13
         3          1         12   52428800          1 YES INACTIVE                183375 24-OCT-13
         2          1         14   52428800          1 NO  CURRENT                 183951 24-OCT-13
 
SYS@SBDB> select * from v$log;
 
    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIM
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ---------
         1          1         13   52428800          1 YES INACTIVE                183935 24-OCT-13
         3          1         12   52428800          1 YES INACTIVE                183375 24-OCT-13
         2          1         14   52428800          1 NO  CURRENT                 183951 24-OCT-13
 
2.6检查此时主备库监听状态
[oracle@10g ~]$ lsnrctl status
 
LSNRCTL for Linux: Version 10.2.0.5.0 - Production on 24-OCT-2013 12:08:45
 
Copyright (c) 1991, 2010, Oracle.  All rights reserved.
 
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=10g.localdomain)(PORT=1521)))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 10.2.0.5.0 - Production
Start Date                24-OCT-2013 10:39:05
Uptime                    0 days 1 hr. 29 min. 39 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /u01/app/oracle/product/10.2.0/db_1/network/admin/listener.ora
Listener Log File         /u01/app/oracle/product/10.2.0/db_1/network/log/listener.log
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=10g.localdomain)(PORT=1521)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC0)))
Services Summary...
Service "PLSExtProc" has 1 instance(s).
  Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
Service "PROD" has 1 instance(s).
  Instance "PROD", status READY, has 1 handler(s) for this service...
Service "PROD_XPT" has 1 instance(s).
  Instance "PROD", status READY, has 1 handler(s) for this service...
Service "SBDB" has 1 instance(s).
  Instance "SBDB", status READY, has 1 handler(s) for this service...
Service "SBDB_XPT" has 1 instance(s).
  Instance "SBDB", status READY, has 1 handler(s) for this service...
The command completed successfully
 
2.7启动备库应用redo
SYS@SBDB> select instance_name,status from v$instance;
 
INSTANCE_NAME    STATUS
---------------- ------------
SBDB             MOUNTED
 
SYS@SBDB> select name,open_mode from v$database;
 
NAME      OPEN_MODE
--------- ----------
PROD      MOUNTED
 
SYS@SBDB> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION PARALLEL 2;
 
Database altered.
 
---到此备库创建完成。

3.打开主库查看主备库日志同步及备库日志应用情况

3.1检查备库已归档日志情况
SYS@SBDB> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;
 
 SEQUENCE# FIRST_TIM NEXT_TIME
---------- --------- ---------
        14 24-OCT-13 24-OCT-13
        15 24-OCT-13 24-OCT-13
        16 24-OCT-13 24-OCT-13
        17 24-OCT-13 24-OCT-13
        18 24-OCT-13 24-OCT-13
        19 24-OCT-13 24-OCT-13
        20 24-OCT-13 24-OCT-13
        21 24-OCT-13 24-OCT-13
        22 24-OCT-13 24-OCT-13
        23 24-OCT-13 24-OCT-13
        24 24-OCT-13 24-OCT-13
        25 24-OCT-13 24-OCT-13
        26 24-OCT-13 24-OCT-13
        27 24-OCT-13 24-OCT-13
        28 24-OCT-13 24-OCT-13
        29 24-OCT-13 24-OCT-13
        30 24-OCT-13 24-OCT-13
        31 24-OCT-13 24-OCT-13
        32 24-OCT-13 24-OCT-13
        33 24-OCT-13 24-OCT-13
        34 24-OCT-13 24-OCT-13
        35 24-OCT-13 24-OCT-13
        36 24-OCT-13 24-OCT-13
        37 24-OCT-13 24-OCT-13
        38 24-OCT-13 24-OCT-13
        39 24-OCT-13 24-OCT-13
        40 24-OCT-13 24-OCT-13
        41 24-OCT-13 24-OCT-13
        42 24-OCT-13 24-OCT-13
 
29 rows selected.
 
3.2主库手动切换日志（可以多切换几组）
SYS@PROD> alter database open;
 
Database altered.
 
3.3检查备库新日志归档情况
SYS@SBDB> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;
 
 SEQUENCE# FIRST_TIM NEXT_TIME
---------- --------- ---------
        14 24-OCT-13 24-OCT-13
        15 24-OCT-13 24-OCT-13
        16 24-OCT-13 24-OCT-13
        17 24-OCT-13 24-OCT-13
        18 24-OCT-13 24-OCT-13
        19 24-OCT-13 24-OCT-13
        20 24-OCT-13 24-OCT-13
        21 24-OCT-13 24-OCT-13
        22 24-OCT-13 24-OCT-13
        23 24-OCT-13 24-OCT-13
        24 24-OCT-13 24-OCT-13
        25 24-OCT-13 24-OCT-13
        26 24-OCT-13 24-OCT-13
        27 24-OCT-13 24-OCT-13
        28 24-OCT-13 24-OCT-13
        29 24-OCT-13 24-OCT-13
        30 24-OCT-13 24-OCT-13
        31 24-OCT-13 24-OCT-13
        32 24-OCT-13 24-OCT-13
        33 24-OCT-13 24-OCT-13
        34 24-OCT-13 24-OCT-13
        35 24-OCT-13 24-OCT-13
        36 24-OCT-13 24-OCT-13
        37 24-OCT-13 24-OCT-13
        38 24-OCT-13 24-OCT-13
        39 24-OCT-13 24-OCT-13
        40 24-OCT-13 24-OCT-13
        41 24-OCT-13 24-OCT-13
        42 24-OCT-13 24-OCT-13
        43 24-OCT-13 24-OCT-13
 
30 rows selected.
 
3.4检查备库新日志应用情况
SYS@SBDB> SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;
 
 SEQUENCE# APP
---------- ---
        14 YES
        15 YES
        16 YES
        17 YES
        18 YES
        19 YES
        20 YES
        21 YES
        22 YES
        23 YES
        24 YES
        25 YES
        26 YES
        27 YES
        28 YES
        29 YES
        30 YES
        31 YES
        32 YES
        33 YES
        34 YES
        35 YES
        36 YES
        37 YES
        38 YES
        39 YES
        40 YES
        41 YES
        42 YES
        43 YES
 
30 rows selected.
 
3.5检查主备库当前状态
SYS@PROD> select DATABASE_ROLE,SWITCHOVER_STATUS from v$database;
 
DATABASE_ROLE    SWITCHOVER_STATUS
---------------- --------------------
PRIMARY          TO STANDBY
 
SYS@SBDB> select DATABASE_ROLE,SWITCHOVER_STATUS from v$database;
 
DATABASE_ROLE    SWITCHOVER_STATUS
---------------- --------------------
PHYSICAL STANDBY TO PRIMARY
 
---到此主备数据库日志传输及备库日志应用均正常。

该篇结合官方文档演示了物理备库的创建过程，为了使该演示过程简介清晰，未将主备库日志同步及备库日志应用情况时的alert.log贴出，但在此不得不指出，主备库alert.log中相关信息的重要性，很多时候我们在配置主备库过程中难免会出现错误，此时就需要仔细查阅主备库alert.log日志中的相关信息才能定位错误发生的原因。对于该篇中的演示过程，虽然我们是在同一太主机上进行，但是这和我们在两天机器上演示该过程并没有本质的变化，唯一不同的操作是拷贝文件及恢复出备库都是在异机上操作而已。下一篇将会介绍物理主备库在两种情况下的角色转换，敬请期待！

在上一篇Oracle 10g DataGuard学习（二）中，我们详细解释了DG主备库间redo data传输方式及原理，当主库redo data传输到备库后，备库该如何应用，以保持主备库数据同步，这就是我们本篇要解释的问题。

Log apply services automatically apply redo to standby databases to maintain synchronization with the primary database and allow transactionally consistent access to the data. Log apply services use the following methods to maintain physical and logical standby databases:
Redo apply (physical standby databases only)
Uses media recovery to keep the primary and physical standby databases synchronized.
You can also open a physical standby database in read-only mode to allow users to query the standby database for reporting purposes. While open, redo data is still received; however, Redo Apply stops and the physical standby database is not kept synchronized with the primary database. If a failure occurs during this time, it can prolong the time it takes for a failover operation to complete.
SQL Apply (logical standby databases only)
Reconstitutes SQL statements from the redo received from the primary database and executes the SQL statements against the logical standby database.
Logical standby databases can be opened in read/write mode, but the target tables being maintained by the logical standby database are opened in read-only mode for reporting purposes (providing the database guard was set appropriately). SQL Apply enables you to use the logical standby database for reporting activities, even while SQL statements are being applied.

以来源于Oracle 10g官方文档，主要解释了log apply services通过两种方式维护主备数据库，对于物理备库而言，只能通过redo apply（介质恢复）方式同步主备库数据，对于逻辑备库而言，只能通过sql apply（执行SQL语句）方式同步主备库数据。在具体解释该含义之前，我们先看一张官档上的Applying Redo Data图：

这张图为实时应用redo data的原理图（关于LGWR SYNC概念上一篇已解释），从这个图上，我们可以清楚的看到备库RFS进程在接收到主库传来的redo daya后将其先写入到standby redo log中后，如果备库为物理备库，则由MRP进程（Media Recovery Process）将standby redo log以介质恢复的方式应用于物理备库，以此保证与主库的数据同步；如果备库为逻辑备库，则先由LSP进程（Logical Standby Process）将standby redo log解析成SQL语句，然后去逻辑备库中执行，以此保证与主库的数据同步。

关于Real-Time Apply to Apply Redo Data Immediately解释：
If the real-time apply feature is enabled, log apply services can apply redo data as it is received, without waiting for the current standby redo log file to be archived. This results in faster switchover and failover times because the standby redo log files have been applied already to the standby database by the time the failover or switchover begins.
Use the ALTER DATABASE statement to enable the real-time apply feature, as follows:
For physical standby databases, issue the ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE statement.
For logical standby databases, issue the ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE statement.

上面说了这么一大段，其实理解Real-Time Apply to Apply Redo Data只需抓住一点：如果开始实时redo data应用，log apply services可以直接应用接收到的redo data到备库，而不用等当前的standby redo log file归档，这正可以使主备库间switchover或failover更快完成。既然有Real-Time Apply to Apply Redo Data，必然也有time delay apply redo data。通常情况下，我们希望主库产生的redo data能够及时在备库应用，这样当主库发生意外宕机（硬件故障或是地震），以failover方式切换备库后，可以立即对外提供服务，并且数据不会出现丢失或是很少丢失（如果采用最大保护模式）。那为什么这里出现了延迟redo data应用于备库呢？这是因为对于数据实时性要求不高的数据库系统，我们希望可以通过设置主备库LOG_ARCHIVE_DEST_n参数中DELAY=minutes属性来延迟redo data在备库中的应用，这样当主库应用系统发生崩溃或是错误的操作时，只要在我们设置的延迟redo data应用的时间范围内，我们就可以及时介入，暂停备库redo data应用，然后从备库中将主库应用误操作的数据库恢复回来。注意设置time delay apply redo data不会影响redo data传输，而仅影响redo data在备库中的应用。

该篇最后结合官档简单介绍redo data应用于备库的SQL命令：
Applying Redo Data to Physical Standby Databases
By default, the redo data is applied from archived redo log files. When performing Redo Apply, a physical standby database can use the real-time apply feature to apply redo directly from the standby redo log files as they are being written by the RFS process.
Starting Redo Apply
To start log apply services on a physical standby database, ensure the physical standby database is started and mounted and then start Redo Apply using the SQL ALTER DATABASE RECOVER MANAGED STANDBY DATABASE statement.
You can specify that Redo Apply runs as a foreground session or as a background process, and enable it with real-time apply. To start Redo Apply in the foreground, issue the following SQL statement:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE;
If you start a foreground session, control is not returned to the command prompt until recovery is canceled by another session.
To start Redo Apply in the background, include the DISCONNECT keyword on the SQL statement. For example:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
This statement starts a detached server process and immediately returns control to the user. While the managed recovery process is performing recovery in the background, the foreground process that issued the RECOVER statement can continue performing other tasks. This does not disconnect the current SQL session.
To start real-time apply, include the USING CURRENT LOGFILE clause on the SQL statement. For example:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE;
Stopping Redo Apply
To stop Redo Apply, issue the following SQL statement in another window:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
Monitoring Redo Apply on Physical Standby Databases
To monitor the status of log apply services on a physical standby database, see DG Section 8.5.4.
Applying Redo Data to Logical Standby Databases
SQL Apply converts the data from the archived redo log or standby redo log in to SQL statements and then executes these SQL statements on the logical standby database. Because the logical standby database remains open, tables that are maintained can be used simultaneously for other tasks such as reporting, summations, and queries.
Starting SQL Apply
To start SQL Apply, start the logical standby database and issue the following statement:
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY;
To start real-time apply on the logical standby database to immediately apply redo data from the standby redo log files on the logical standby database, include the IMMEDIATE keyword as shown in the following statement:
SQL>  ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
Stopping SQL Apply on a Logical Standby Database
To stop SQL Apply, issue the following statement on the logical standby database:
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
When you issue this statement, SQL Apply waits until it has committed all complete transactions that were in the process of being applied. Thus, this command may not stop the SQL Apply processes immediately.
If you want to stop SQL Apply immediately, issue the following statement:
SQL> ALTER DATABASE ABORT LOGICAL STANDBY APPLY;
Monitoring SQL Apply on Logical Standby Databases
To monitor SQL Apply, see DG Section 9.2. Also, see the discussion about the V$ARCHIVE_DEST_STATUS fixed view in DG Section 8.5.4.3 and the Oracle Database Reference for complete reference information.

以上为该篇内容，到此我们用了三个篇幅来解释DG的基本原理及基础理论知识，后面将会更新DG的搭建，切换及调优，敬请期待！