繼上一篇

管理影響物理standby的事件

1 創建表空間或數據文件
初始化參數standby_file_management用來控制是否自動將primary數據庫增加表空間或數據文件的改動，傳播到standby服務器AUTO/MANUAL
AUTO:自動傳播到standby
MANUAL:需要手動復制文件到standby，并更新控制文件

SQL> set sqlprompt "primary>" primary>show parameter standby_file NAME TYPE VALUE ------------------------------------ ---------------------- ------------------------------ standby_file_management string AUTO --select * from v$parameter where name like 'standby%';

2 刪除表空間
--對于表空間和數據文件的操作，STANDBY_FILE_MANAGEMENT=AUTO，無須手工干預
3 重命名數據文件
--需要手工干預，STANDBY_FILE_MANAGEMENT=AUTO/MANUAL
在主庫rename datafile文件，從庫需要手動操作
主庫

alter tablespace new_dg2 offline;mv /u01/app/oracle/oradata/hongquan/hongquantest/new_dg2.dbf /u01/app/oracle/oradata/hongquan/hongquantest/new_dg2_test.dbfalter tablespace new_dg2 rename datafile '/u01/app/oracle/oradata/hongquan/hongquantest/new_dg2.dbf' to '/u01/app/oracle/oradata/hongquan/hongquantest/new_dg2_test.dbf';alter tablespace new_dg2 online;alter system switch logfile; select name from v$datafile;

備庫

alter database recover managed standby database cancel;mv /u02/app/oracle/oradata/hongquan1/hongquantest/new_dg2.dbf /u02/app/oracle/oradata/hongquan1/hongquantest/new_dg2_test.dbfalter database recover managed standby database disconnect from session;select name from v$datafile;

4 添加或刪除redologs文件

--需要手工干預改文件的刪除和創建
無論主庫端對日志組或日志文件的操作是否傳播到了standby端，也不會影響到standby的運行。
在主庫增加或刪除redo logs時，一定記得手工同步相關物理standby中的相關設置，保證standby log比primary redolog多一組操作要將STANDBY_FILE_MANAGEMENT=MANUAL
保證standby redologs比online redologs多一組

5垮open_resetlogs的應用

在某些情況下，主庫以resetlogs打開數據庫，也不會影響dg的配置，standby數據庫不需要人工參與，自動應用open resetlogs的操作。
并非所有條件下有這樣，在alter database open resetlogs之后，數據庫的INCARNATION被重置，此時其standby數據庫的
sequence序號也會從頭開始，物理standby數據庫不需要關注。
在不完全恢復情況下

?

監控primary 和物理standby

###帶有enable|disable thread子句的alter database命令 V$THREAD --This view contains thread information from the control file. ###當前數據庫角色，保護模式，保護級別，switchover 狀態，failover快速啟動信息等 select * from v$database; --LOG_MODE,CONTROLFILE_TYPE,OPEN_MODE,PROTECTION_MODE,DATABASE_ROLE,SWITCHOVER_STATUS,FORCE_LOGGING,FLASHBACK_ON,DB_UNIQUE_NAME --controlfile_type=CURRENT/STANDBY --PROTECTION_MODE=MAXIMUM PROTECTION/MAXIMUM AVAILABILITY/RESYNCHRONIZATION/MAXIMUM PERFORMANCE/UNPROTECTED --DATABASE_ROLE=LOGICAL STANDBY/PHYSICAL STANDBY/PRIMARY --DATAGUARD_BROKER=ENABLED/DISABLED ###redo log 切換 V$LOG/V$LOGFILE ###重建控制文件,手工執行恢復 alert.log SQL> select * from v$diag_info; /u01/app/oracle/diag/rdbms/orcl/orcl/trace ###表空間狀態修改(read write/read only,online/offline) select * from dba_tablespaces; ###創建刪除表空間或數據文件 select * from dba_data_files; ###表空間或數據文件offline select * from dba_tablespaces; select * from v$recover_file; --This view displays the status of files needing media recovery ###重命名數據文件 select * from v$datafile; ###未被日志記錄或不可恢復的操作 select * from v$datafile; select * from v$database; ###恢復的進程 select * from v$archive_dest_status; --主庫 select * from v$archived_log; select * from v$log_history; select * from v$managed_standby; ###redo傳輸的狀態和進度 select * from v$archive_dest_status; --主庫 select * from v$archive_dest; --主庫 select * from v$archived_log; --主庫 select * from v$archived_log; ###數據文件自動擴展 /u01/app/oracle/diag/rdbms/orcl/orcl/trace ###執行open resetlogs或clear unarchived logfiles，修改初始化參數 /u01/app/oracle/diag/rdbms/orcl/orcl/trace

監控恢復進度

1 查看進程的活動狀態

standby > select process,client_process,sequence#,status from v$managed_standby; ARCH ARCH 1846 CLOSING ARCH ARCH 0 CONNECTED MRP0 N/A 1847 APPLYING_LOG RFS UNKNOWN 0 IDLE RFS UNKNOWN 0 IDLE RFS LGWR 1847 IDLE RFS UNKNOWN 0 IDLE -- PROCESS:進程名稱，如ARCH\RFS\MRP0等 CLIENT_P:對應的primary數據庫中的進程，如ARCH\LGWR等 SEQUENCE#:歸檔序號 STATUS:進程的當前狀態，常見的有：ALLOCATED:整準備連接primary庫ATTACHED:正在連接primary庫CONNECTED:已連接到primary庫IDLE:空閑中RECEIVING:歸檔文件接收中OPENING:歸檔文件處理中CLOSING:歸檔文件處理完，收尾中WRITING:REDO數據庫寫想歸檔文件中WAIT_FOR_LOG:等待新的redo數據中WAIT_FOR_GAP:歸檔有中斷，正等待中斷的那部分redo數據APPLYING_LOG:應用redo數據中 數據庫開了1個歸檔進程，使用ARCH同步傳輸方式與物理standby通信，已經接收并收尾處理1846號日志，正在應用1847號日志

2 檢查redo應用進度

standby > select dest_name,archived_thread#,archived_seq#,applied_thread#,applied_seq#,db_unique_name,destination from v$archive_dest_status where status='VALID'; LOG_ARCHIVE_DEST_1 1 1846 0 0 cadbk C:\app\Administrator\fast_recovery_area\cadbk\ARCHIVELOG LOG_ARCHIVE_DEST_2 0 0 0 0 CAD cad_192.168.19.97 STANDBY_ARCHIVE_DEST 1 1846 1 1846 NONE C:\app\Administrator\fast_recovery_area\cadbk\ARCHIVELOG

3 檢查歸檔文件路徑和創建信息

standby > select name,creator,sequence#,applied,completion_time from v$archived_log; C:\APP\ADMINISTRATOR\FAST_RECOVERY_AREA\CADBK\ARCHIVELOG\1_1845_976879612.ARCH ARCH 1845 YES 2019/6/26 6:04:33 C:\APP\ADMINISTRATOR\FAST_RECOVERY_AREA\CADBK\ARCHIVELOG\1_1846_976879612.ARCH ARCH 1846 IN-MEMORY 2019/6/26 8:17:32

4 查詢歸檔歷史

standby > select first_time,first_change#,next_change#,sequence# from v$log_history; --查詢到最后應用的歸檔文件 standby > select thread#,max(sequence#) as "last_applied_log" from v$log_history group by thread#; thread# last_applied_log 1 1846 --也可以通過v$archived_log中的app列表獲得相同的功能 standby > select thread#,sequence#,applied from v$archived_log; 1 1844 YES 1 1845 YES 1 1846 IN-MEMORY

5 查看物理standby數據庫未接收的日志文件
在primary端獲取，日志文件的發送是通過log_archive_dest_n參數來控制，因此只需要對比本地生成的歸檔和遠端生成的歸檔的差異即可

primary > select local.thread#,local.sequence# from (select thread#,sequence# from v$archived_log where dest_id=1) localwhere local.sequence# not in(select sequence# from v$archived_log where dest_id=2 and thread#=local.thread#);

監控日志應用服務

1 查詢當前數據庫的基本信息

standby > select database_role,db_unique_name,open_mode,protection_mode,protection_level, switchover_status from v$database; PHYSICAL STANDBY cadbk READ ONLY WITH APPLY MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE NOT ALLOWED --查詢failover后快速啟動的信息 standby > select fs_failover_status,fs_failover_current_target,fs_failover_threshold, fs_failover_observer_present from v$database;

2 查詢當前redo應用和redo傳輸服務的活動狀態

standby > select process,status,thread#,sequence#,block#,blocks from v$managed_standby; ARCH CLOSING 1 1846 90112 347 ARCH CONNECTED 0 0 0 0 MRP0 APPLYING_LOG 1 1848 1156 102400 RFS IDLE 0 0 0 0 RFS IDLE 0 0 0 0 RFS IDLE 1 1848 1157 2

3 檢查應用模式（是否啟用了實時應用）

standby > select recovery_mode from v$archive_dest_status where dest_id=1; MANAGED REAL TIME APPLY ##打開了實時應用

4 data guard事件(v$dataguard_status)
該視圖顯示那些被自動觸發寫入alert.log或服務器trace文件的事件

standby > select message from v$dataguard_status; Media Recovery Waiting for thread 1 sequence 1847 (in transit) ARC0: Beginning to archive thread 1 sequence 1847 (40070728-40088719) Media Recovery Waiting for thread 1 sequence 1848 (in transit) ARC0: Completed archiving thread 1 sequence 1847 (0-0)

調整物理standby端redo數據應用頻率
--調整I/O讀取能力
-設置recover并行度
在介質恢復或redo應用期間，都需要讀取redo log，默認是串行恢復，可以在recover的時候加上parallel來指定并行度。
standby > recover standby database parallel 2;
##建議parallel的值為#cpus*2
注意：該值設置僅對當前環境有效，oracle數據庫重啟之后，默認情況下并行度會恢復到初始值，
如果dba每次執行很麻煩，要通過初始化參數parallel_max_servers來設置默認的并行度
-加快redo應用頻率
設置初始化參數db_block_checking=false能夠提高2倍左右的應用效率，該參數設置是否驗證數據塊的有效性，
對于物理standby數據塊，禁止驗證基本上開始可以接受（paiarmy數據塊強力建議該值為true，默認就是true），
動態參數，修改直接生效，不需要重啟數據庫
-設置parallel_execution_message_size
如果打開了并行恢復，適當提高初始化參數，比如4096也能提高大概20%左右的性能，增大這個參數可能會占更多內存
-優化磁盤I/O
在恢復期間最大的瓶頸就是I/O讀寫，要緩解這個瓶頸，使用本地異步I/O并設置初始化參數disk_asynch_io=true會有所
幫助，disk_asynch_io控制數據文件的磁盤I/O是否異步，某些情況下異步I/O能降低數據庫文件并行讀取，提高整個恢復時間。

轉載于:https://www.cnblogs.com/yhq1314/p/11091220.html

總結

以上是生活随笔為你收集整理的oracle data guard --理论知识回顾02的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。