最近部署了一套dataguard，没有采用dg broker来管理，部署方法是用rman的duplicate。在整个过程中遇到一些这样的坑，分享一下，希望能对大家有一点帮助。
环境：OS是redhat 6.4，数据库是Oracle11.2.0.4。
primary database: dscsh
standby database: DG
坑一:备库alert日志出现 No standby redo logfiles available for thread 1
警告信息如下：
RFS[3]: No standby redo logfiles available for thread 1
RFS[3]: Opened log for thread 1 sequence 158 dbid 90456326 branch 901809544
这个是由于主库设置传日志使用的方式是LGWR，然后备库没有创建standby redo log导致，在备库创建后可以消除这个警告。
另外，standby redo log 文件组数要比主库的 online redo 日志文件组数至少多一个。
推荐 standby redo 日志组数量基于主库的线程数(这里的线程数可以理解为RAC的节点数)。
有一个推荐的公式可以做参考：(每线程的日志组数+1)*最大线程数
假设现在节点是1个，则=(3+1)*1=4，如果是双节点则=(3+1)*2=8
另外，不建议组号group#紧挨着redo，因为后续redo有可能调整
坑二:备库alert日志间歇性出现 ORA-16009 invalid redo transport destination
这个是由于主库在配置log_archive_dest_2的时候没有加上手动设置valid_for属性，valid_for=(online_logfiles,primary_role)，默认不设置valid_for属性Oracle会认为是VALID_FOR=(ALL_LOGFILES, ALL_ROLES)，
在主库上设置好之后，备库的v$archive_dest和alert将不会出现上述的错误。需要说明的是即使报这个错，但并不影响dg的运行。
坑三:log_archive_dest_1的归档路径最后面缺少一个"/" ，个人觉得后面的补齐gap方法可能会用的较多。
1.查看主备库的alert日志，报错内容如下：
dscsh:
ARC3: Archive log rejected (thread 1 sequence 113) at host 'DG'
FAL[server, ARC3]: FAL archive failed, see trace file.
ARCH: FAL archive failed. Archiver continuing
ORACLE Instance dscsh - Archival Error. Archiver continuing.
DG:
ARCH: Archival stopped, error occurred. Will continue retrying
ORACLE Instance DG - Archival Error
ORA-16014: log 6 sequence# 113 not archived, no available destinations
ORA-00312: online log 6 thread 1: '/u01/app/oracle/oradata/DG/std_redo06.log'
2.分析:
根据在备库上的错误提示，猜测是主库的归档没有传过来或者没有被归档应用到备库上去，所以下一步要做的就是检查备库的归档是否报错，是否存在gap，以及相关的archivelog是否还在主库上存在。
3.主库上面归档路径的检查
SQL> select dest_name,status,target,archiver,schedule, valid_type,valid_role,db_unique_name from v$archive_dest;
DEST_NAME STATUS TARGET ARCHIVER SCHEDULE VALID_TYPE VALID_ROLE DB_UNIQUE_NAME
----------------- -------- ---------- --------- ---------- ------------- ----------- --------------
LOG_ARCHIVE_DEST_1 VALID PRIMARY ARCH ACTIVE ALL_LOGFILES ALL_ROLES NONE
LOG_ARCHIVE_DEST_2 error STANDBY LGWR ACTIVE ONLINE_LOGFILE PRIMARY_ROLE DG
4.在主库和备库检查GAP
select * from v$archive_gap;
在主库上面没有gap，在备库上面有gap
5.在主库检查归档是否存在：
select * from v$archived_log where sequence#=113;
发现有日志文件：/u01/app/oracle/archivelog1_113_901809544.dbf
问题来了，我在配置log_archive_dest_1，值= LOCATION=/u01/app/oracle/archivelog valid_for=(all_logfiles,all_roles) db_unique_name=dscsh
这个地方直接把archivelog和1_113_901809544.dbf放在一起了，变成了archivelog1_113_901809544.dbf。
检查下是否还有其他的归档日志也这样写了，发现如下：
[oracle@dscshdb1 oracle]$ ls
admin archivelog1_117_901809544.dbf archivelog1_123_901809544.dbf archivelog1_129_901809544.dbf checkpoints
archivelog archivelog1_118_901809544.dbf archivelog1_124_901809544.dbf archivelog1_130_901809544.dbf diag
archivelog1_113_901809544.dbf archivelog1_119_901809544.dbf archivelog1_125_901809544.dbf archivelog1_131_901809544.dbf fast_recovery_area
archivelog1_114_901809544.dbf archivelog1_120_901809544.dbf archivelog1_126_901809544.dbf archivelog1_132_901809544.dbf oradata
archivelog1_115_901809544.dbf archivelog1_121_901809544.dbf archivelog1_127_901809544.dbf archivelog1_133_901809544.dbf product
archivelog1_116_901809544.dbf archivelog1_122_901809544.dbf archivelog1_128_901809544.dbf cfgtoollogs
6.解决步骤：
(1)先把主库的 log_archive_dest_state_2修改成defer，因为传过去的过程中可能会出现日志的继续传送，因为要恢复所以害怕不能被应用到。
(2)接着把类似 archivelog1_1XX_901809544.dbf 的归档都传到备库的主机上去。
注意：如果是ASM管理的，可以用rman把ASM设备中拷贝出来所需的归档文件,上传至DG服务器，类似命令如下：
copy archivelog '+ORADATA/sid/ARCHIVELOG/2016_01_23/thread_1_seq_111.234.901809544.dbf' to '/tmp/log/thread_1_seq_111.dbf';
(3)取消备库的日志应用
alter database recover managed standby database cancel;
(4)将缺失的归档日志注册至DG数据库
alter database register logfile '/home/oracle/archivelog1_113_901809544.dbf';
...
alter database register logfile '/home/oracle/archivelog1_133_901809544.dbf';
(5)shutdown DG数据库；
(6)startup DG数据库,让它自己去recover
(7)开启日志恢复进程
alter database recover managed standby database disconnect from session;
(8)修改主库的初始化参数
alter system set log_archive_dest_1='LOCATION=/u01/app/oracle/archivelog/ valid_for=(all_logfiles,all_roles) db_unique_name=dscsh';
alter system set log_archive_dest_state_2=defer;
(9)将备库的log_archive_dest_1的目录，也加上"/"
alter system set log_archive_dest_1='LOCATION=/u01/app/oracle/archivelog/ valid_for=(all_logfiles,all_roles) db_unique_name=DG';
坑四:没有配置好实时应用。备库只是应用了归档日志，并没有进行实时的redo log应用，每次备库的改变，都要在主库先做完alter system switch logfile，备库才会应用redo。
在11g之前，DG处于日志应用状态时，是无法从备库读取数据的。如果想开库，需停止日志应用，备库可以开到read only状态。
如果物理备库从read only状态切回到日志应用状态，要先关掉物理备库，再将库启到mount状态，最后重新应用日志。
这样的话要从备库读数据，日志应用就必须停掉。无法实现一边应用日志一边读取数据，做不到读实时的数据。
11g的一个很大的特性，就是ADG。实现日志应用和查询同时进行。即Real-Time Apply + Real-Time Query。
以前备库的管理方法在11g上也可以使用：
物理备库取消日志应用：
alter database recover managed standby database cancel;
物理备库开库（read only）
alter database open;
select database_role,open_mode from v$database;
此时备库处于read only状态，可以进行数据查询，但无法应用日志。
如果物理备库从read only状态回到日志应用工状态，要先关掉物理备库，再将库启到mount状态，最后重新应用日志。
shutdown immediate;
mount startup mount;
alter database recover managed standby database disconnect from session;
这种日志应用方式无法实现备库上日志应用和数据查询同时进行。
如果想实现Active Standby，备库上需使用Real-Time Apply来应用日志。
1、主库日志传输方式
如果要实现真正的日志实时应用、数据实时查询，日志的远程传输方式必须是lgwr+sync+affirm
2.备库Real-Time Apply应用日志
alter database recover managed standby database using current logfile disconnect;
select database_role,open_mode from v$database;
即在日志应用过程中，同时只读方式开库来读取数据。
实现了DataGuard物理备库的日志应用和数据读取的同时进行。
