标签：orm 文件名 总结 环境 target ssi data type logfile
此次的操作环境是Oracle11g 单实例，os为Linux，采用duplicate在线创建物理备库
primary上设置相关参数
ALTER SYSTEM SET LOG_ARCHIVE_CONFIG=‘DG_CONFIG=(ora11g,stdb)‘;alter system set log_archive_dest_2=‘SERVICE=DB_DG2 lgwr async valid_for=(online_logfiles,primary_role) db_unique_name=stdb‘; ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE; ALTER SYSTEM SET FAL_SERVER=ORA11G02; ALTER SYSTEM SET FAL_CLIENT=ORA11G01; ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO; alter system set LOG_ARCHIVE_DEST_1= ‘LOCATION=/data0/u01/app/oracle/arch VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=ora11g‘ scope=spfile; alter system set log_archive_format=‘%t_%s_%r.arch‘ scope=spfile;
添加standby redo log
alter database add standby logfile thread 1 group 4(‘/data0/u01/app/oracle/oradata/ora11g/standby_redo04.log‘) size 50m; alter database add standby logfile thread 1 group 5(‘/data0/u01/app/oracle/oradata/ora11g/standby_redo05.log‘) size 50m; alter database add standby logfile thread 1 group 6(‘/data0/u01/app/oracle/oradata/ora11g/standby_redo06.log‘) size 50m; alter database add standby logfile thread 1 group 7(‘/data0/u01/app/oracle/oradata/ora11g/standby_redo07.log‘) size 50m;
备库安装完软件配置好环境变量
然后是配置监听文件listener.ora和tnsnames.ora
创建备库的命令为
DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE DORECOVER SPFILE SET "db_unique_name"="jjdb" SET LOG_ARCHIVE_DEST_2="service=ora11g02 ASYNC REGISTER VALID_FOR=(online_logfile,primary_role)" SET FAL_CLIENT="ora11g02" SET FAL_SERVER="ora11g01" NOFILENAMECHECK;
针对以上过程，rman会自动拷贝server端的参数文件到standby端，然后启动到nomount状态，还原控制文件，并拷贝所有的数据文件、临时表空间和归档日志到备库。然后进行recovery
在将备库启动到nomount状态是使用pfile即：startup nomount pfile=initorcl11g.ora
否则由于spfile被占用而报：RMAN-05537: DUPLICATE without TARGET connection when auxiliary instance is started with spfile cannot use SPFILE clause
然后在primary端（standby端均可）登录rman
rman target sys/oracle@ORA11G01 auxiliary sys/oracle@ORA11G02
在创建备库期间，变更完参数后，从库会重启，报错：
RMAN-04006: error from auxiliary database: ORA-01017: invalid username/password; logon denied
首先确定口令文件是从主库端拷贝过来的，文件名字以及用户名和密码都是正确的
使用tnsping检查网络也都互通
最后查看从库监听状态，只有一个orcl11g实例（对应$ORACLE_SID）
但是linstener.ora 中的SID_NAME指定的非$ORACLE_SID
改正监听文件后开始创建备库
创建完成后查看备机的数据库状态
SQL> SELECT DATABASE_ROLE,OPEN_MODE,PROTECTION_MODE FROM V$DATABASE; DATABASE_ROLE OPEN_MODE PROTECTION_MODE ---------------- -------------------- -------------------- PHYSICAL STANDBY MOUNTED MAXIMUM PERFORMANCE
# standby
SQL> select GROUP#,STATUS,TYPE,MEMBER from v$logfile;
GROUP# STATUS TYPE MEMBER
---------- ------- ------- --------------------------------------------------------------------------------
3 ONLINE /data0/u01/app/oracle/fast_recovery_area/STDB/onlinelog/o1_mf_3_d8byvvoq_.log
2 ONLINE /data0/u01/app/oracle/fast_recovery_area/STDB/onlinelog/o1_mf_2_d8byvvn0_.log
1 ONLINE /data0/u01/app/oracle/fast_recovery_area/STDB/onlinelog/o1_mf_1_d8byvvl6_.log
此时迷惑我的问题发生了，rman是不会拷贝redo日志文件的，那么此时查看到的redo日志文件是控制文件记录的，但是主上的redo log路径并不是这个，可视主机开启了闪回区，所以redo log在闪回区也有存在
所以可以推断控制文件记录的redo log的路径是: 闪回区路径/db_uniq_name/onlinelog,实际上在备库上并不存在这些redo log file
备库创建redo log和standby redo log
开始启动备库到实时应用日志
SQL> ALTER DATABASE OPEN READ ONLY; Database altered. SQL> SELECT DATABASE_ROLE,OPEN_MODE,PROTECTION_MODE FROM V$DATABASE; DATABASE_ROLE OPEN_MODE PROTECTION_MODE ---------------- -------------------- -------------------- PHYSICAL STANDBY READ ONLY MAXIMUM PERFORMANCE SQL>ALTERDATABASERECOVER MANAGED STANDBYDATABASEUSINGCURRENTLOGFILE DISCONNECTFROMSESSION;Database altered. SQL> SELECT DATABASE_ROLE,OPEN_MODE,PROTECTION_MODE FROM V$DATABASE; DATABASE_ROLE OPEN_MODE PROTECTION_MODE ---------------- -------------------- -------------------- PHYSICAL STANDBY READ ONLY WITH APPLY MAXIMUM PERFORMANCE
备库上查看 archive log list
归档路径状态异常，查看使用的是LOG_ARCHIVE_DEST_3
SQL> col DEST_NAME format a30 SQL> col DESTINATION format a30 SQL> SELECT dest_name, status, destination FROM v$archive_dest; DEST_NAME STATUS DESTINATION ------------------------------ --------- ------------------------------ LOG_ARCHIVE_DEST_1 BAD PARAM /data0/u01/app/oracle/arch LOG_ARCHIVE_DEST_2 BAD PARAM ora11g02 LOG_ARCHIVE_DEST_3 VALID USE_DB_RECOVERY_FILE_DEST
官方文档上对状态为BAD PARAM的解释为 A parameter error occurred; refer to error data.
select dest_id,status,error from v$archive_dest ; # 未发现错误信息
查看参数发现是db_uniq_name设置错误
更正后重启数据库后
路径1和2的状态均为valid
但是archive log list看到的仍旧是
Archive destination USE_DB_RECOVERY_FILE_DEST
官方文档解释：If you configure a Fast Recovery Area (by setting the DB_RECOVERY_FILE_DEST and DB_RECOVERY_FILE_DEST_SIZE parameters) and do not specify any local archive destinations, the database automatically selects the Fast Recovery Area as a local archive destination and sets LOG_ARCHIVE_DEST_1 to USE_DB_RECOVERY_FILE_DEST.
但是查看发现闪回区路径下和LOG_ARCHIVE_DEST_1下均产生归档日志文件
至此搭建完毕
标签：orm 文件名 总结 环境 target ssi data type logfile
原文地址：http://www.cnblogs.com/Bccd/p/6362786.html
