總結搭建Oracle11g DG踩的坑

 

此次的操作環境是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>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;

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下均產生歸檔日志文件

至此搭建完畢