Configuration File: C:\app\administrator\product\11.2.0\dbhome_1\NETWORK\ADMIN\listener.ora
# Generated by Oracle configuration tools.
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = dg)
(ORACLE_HOME = C:\app\administrator\product\11.2.0\dbhome_1)
(SID_NAME = dg)
)
)
LISTENER =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = dgdg)(PORT = 1521))
)
ADR_BASE_LISTENER = C:\app\administrator\product\11.2.0\dbhome_1\log
6.备库创建相关目录
c:\archivelog --指定一个本地归档路径，备库接收到的归档日志和自己生成的归档日志都放在这里
c:\app\administrator\admin\dg\adump
c:\app\administrator\admin\dg\dpdump
c:\app\administrator\admin\dg\hdump
c:\app\administrator\admin\dg\pfile
c:\app\administrator\flash_recovery_area
c:\app\administrator\oradata\dg
7.主库做rman全备
RMAN> backup as compressed backupset full database format 'c:\bak\full_%d_%I_%T_%U'
8.主库创建备库控制文件
SQL> alter database create standby controlfile as 'c:\control01.ctl';
SQL> alter database create standby controlfile as 'c:\control02.ctl';
9.复制备份文件、密码文件、pfile文件、tnsnames.ora、listener.ora到备库相应位置
10.备库创建实例
oradim -new -sid dg -startmode manual -spfile;
11.启动监听
lsntrctl start
12.启动实例到mount
set oracle_sid=dg
sqlplus / as sysdba
SQL> startup mount
13.恢复数据库
RMAN> catalog start with 'd:\bak'; --不指定会提示无法恢复数据库
RMAN> restore database;
14.备库添加standby redo logfile
SQL> alter database add standby logfile 'C:\app\administrator\oradata\dg\std_05.log' size 50m;
SQL> alter database add standby logfile 'C:\app\administrator\oradata\dg\std_06.log' size 50m;
SQL> alter database add standby logfile 'C:\app\administrator\oradata\dg\std_07.log' size 50m;
SQL> alter database add standby logfile 'C:\app\administrator\oradata\dg\std_08.log' size 50m;
SQL> alter database add standby logfile 'C:\app\administrator\oradata\dg\std_09.log' size 50m;
15.启用redo apply
SQL> alter database recover managed standby database disconnect from session;
16.给备库创建spfile(可选)
SQL> create spfile from pfile;
下面记录几个在整个配置过程中遇到的问题：
1.用opatch apply命令无法打patch
出现原因：11.2.0.3默认装完后的opatch版本是11.2.0.1.7,我要打的patch 27需要在这个版本之上才可以
解决方法：解压高版本的opatch安装包后覆盖原opatch目录
2.备库alert.log报警提示无法找到控制文件自动备份路径
出现原因：RAC主库之前部署过自动RMAN备份脚本，指定了控制文件自动备份路径，但备库并没有此路径
解决方法：进入RMAN，修改该项参数为备库存在的目录
3.参数设置错误而引起GAP,导致自动备份脚本停止运行
出现原因：之前在设置参数时，把主库的log_archive_dest_1参数设置了本地路径归档，如：
alter system set log_archive_dest_1='LOCATION=C:\archivelog VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=dg';
作为RAC，归档路径在本地的话，其他节点就无法读取，发现后重新设置为USE_DB_RECOVERY_FILE_DEST后，那些在本地的归档日志就成为GAP而无法传递到备库
解决方法：手工复制所有提示缺失的xxx归档到指定位置，再手动执行RMAN自动备份脚本
说明：由于RMAN自动备份脚本里配置了冗余7份,而之搭建DG时手动执行了全库备份，这些手动备份也是算在7份冗余之内的，为了不占用正常备份的配额，DG搭建完成后建议物理删除，然后再crossecheck并清理掉
4.主、备库的alert.log经常会出现TNS错误
fatal NI connect error 12547
TNS-12547 TNS : 丢失连接
ns secondary err code : 12560
ns main err code : 517
TNS-00517 TNS : 丢失连接
nt secondary err code : 54
nt OS err code : 0
出现原因：节点2没有配置tnsnames.ora，造成thread 2的归档日志无法传递到备库，同时也会造成主库日志能传递过去，但无法应用。
解决方法: 把节点1的tnsnames.ora直接复制一个到节点2
说明：其实这个也是造成备库应用出现GAP的最大原因，由于节点2日志传递不到备库，虽然之前的几个归档日志序列相应的applied列的属性值都是YES，但是会造成节点1的日志也不应用，哪怕在节点1切了很多次归档，applied列始终会显示NO，但日志都是可以正常传递过去的