【DB筆試面試764】在Oracle中，邏輯DG維護中經常使用到的SQL語句有哪些？

♣          題目         部分

在Oracle中，邏輯DG維護中經常使用到的SQL語句有哪些？

     
♣          答案部分          

1.日誌應用的啓動和關閉

1ALTER DATABASE STOP LOGICAL STANDBY APPLY; ---中止應用，等待事務完成
2ALTER DATABASE ABORT LOGICAL STANDBY APPLY;--不等待事務完成就中止
3ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; ---實時
4ALTER DATABASE START LOGICAL STANDBY APPLY; --非實時
5ALTER DATABASE START LOGICAL STANDBY APPLY  IMMEDIATE SKIP FAILED TRANSACTION; --實時應用並跳過失敗的事務

     

如何知道是否開啓了實時應用呢？能夠查詢V$LOGSTDBY_STATE視圖或查詢是否有lsp進程。

1SQL> SELECT * FROM V$LOGSTDBY_STATE;
2PRIMARY_DBID SESSION_ID REALTIME_APPLY      STATE
3------------ ---------- ------------------  -----------------------------------------
4  1480747539          1 Y                   APPLYING
5[oracle@rhel6_lhr oraljdg]$ ps -ef|grep -i ora_lsp
6oracle   20450     1  0 15:22 ?        00:00:00 ora_lsp0_oraljdg

     

2.查看日誌文件的應用狀況

 1COLUMN DICT_BEGIN FORMAT A15;
 2COLUMN FILE_NAME FORMAT A50;
 3SET NUMF 9999999;
 4COL FCHANGE# FORMAT 9999999999999;
 5COL NCHANGE# FOR 999999999999999999999;
 6SET LINE 200
 7SELECT  FILE_NAME, SEQUENCE# AS SEQ#, FIRST_CHANGE# AS FCHANGE#,
 8        NEXT_CHANGE# AS NCHANGE#, TIMESTAMP, DICT_BEGIN AS BEG,
 9        DICT_END AS END, THREAD# AS THR#, APPLIED
10    FROM DBA_LOGSTDBY_LOG
11ORDER BY THREAD#,SEQUENCE#;
12
13SET LINE 9999 PAGESIZE 9999
14COL FILE_NAME FORMAT A120
15SELECT THREAD#,SEQUENCE#, FILE_NAME, APPLIED, TIMESTAMP 
16FROM DBA_LOGSTDBY_LOG D 
17WHERE D.SEQUENCE# >=(SELECT MAX(SEQUENCE#)-3 FROM  DBA_LOGSTDBY_LOG NB WHERE  NB.THREAD#=D.THREAD# AND NB.APPLIED='YES' ) 
18ORDER BY THREAD#,D.SEQUENCE#;

     

3.查看備庫SQL Apply的進度

1SQL> SELECT LATEST_SCN,MINING_SCN,APPLIED_SCN,LATEST_TIME,MINING_TIME,APPLIED_TIME FROM V$LOGSTDBY_PROGRESS;
2LATEST_SCN MINING_SCN APPLIED_SCN LATEST_TIME         MINING_TIME         APPLIED_TIME
3---------- ---------- ----------- ------------------- ------------------- -------------------
48895794846 8895316681  8895316680 2010-05-18 16:27:08 2010-05-18 16:03:54 2010-05-18 16:03:54

     

4.查看備庫是否有任何DDL/DML語句未成功應用

 1COL EVENT_TIMESTAMP FORMAT A30
 2COL EVENT FORMAT A40
 3COL EVENT_STATUS FORMAT A80
 4SELECT A.EVENT_TIME,
 5       A.CURRENT_SCN,
 6       A.COMMIT_SCN,
 7       XIDUSN,
 8       XIDSLT,
 9       XIDSQN,
10       TO_CHAR(EVENT) EVENT,
11       A.STATUS_CODE,
12       STATUS EVENT_STATUS
13  FROM DBA_LOGSTDBY_EVENTS A
14 WHERE A.EVENT_TIME >= SYSDATE - 10 / 1660
15 ORDER BY A.EVENT_TIME ;

     

5.查看備庫SQL Apply的狀態

1COL REALTIME_APPLY FORMAT A15
2COL STATE FORMAT A20
3SELECT * FROM V$LOGSTDBY_STATE;
4PRIMARY_DBID SESSION_ID REALTIME_APPLY       STATE
5------------ ---------- --------------- ---------------
6262089084          1                 Y         APPLYING

     

注意STATE列，該列可能有下述的幾種狀態：

l INITIALIZING：LogMiner SESSION已建立並初始化

l LOADING DICTIONARY：SQL應用調用LogMiner字典

l WAITING ON GAP：SQL應用正在等待日誌文件，可能有中斷

l APPLYING：SQL應用正在工做

l WAITING FOR DICTIONARY LOGS：SQL應用正在等待LogMiner字典信息

l IDLE：SQL應用工做很是出色，處於空閒狀態

l SQL APPLY NOT ON：沒有開啓應用

6.取消部分對象或事務的同步

能夠利用DBMS_LOGSTDBY.SKIP存儲過程跳過特定表或特定用戶的DML事務或部分DDL語句。這些跳過的對象或事務能夠經過視圖DBA_LOGSTDBY_SKIP和DBA_LOGSTDBY_SKIP_TRANSACTION查看。

 1EXECUTE DBMS_LOGSTDBY.SKIP(STMT => 'VIEW');
 2EXECUTE DBMS_LOGSTDBY.SKIP(STMT => 'PROFILE');
 3EXECUTE DBMS_LOGSTDBY.SKIP(STMT => 'DATABASE LINK');
 4EXECUTE DBMS_LOGSTDBY.SKIP(STMT => 'CREATE VIEW');
 5EXECUTE DBMS_LOGSTDBY.SKIP(STMT => 'DROP VIEW');
 6EXECUTE DBMS_LOGSTDBY.SKIP(STMT=>'SCHEMA_DDL', SCHEMA_NAME=>'%', OBJECT_NAME=>'%', PROC_NAME=>NULL);
 7EXECUTE DBMS_LOGSTDBY.SKIP(STMT=>'SCHEMA_DDL', SCHEMA_NAME=>'LHR', OBJECT_NAME=>'%', PROC_NAME=>NULL);
 8EXECUTE DBMS_LOGSTDBY.SKIP(STMT=>'SCHEMA_DDL', SCHEMA_NAME=>'MDSYS', OBJECT_NAME=>'%', PROC_NAME=>NULL);
 9
10EXEC DBMS_LOGSTDBY.SKIP_TRANSACTION (3, 3, 827); --(XIDUSN = 3, XIDSLT = 3, XIDSQN = 827)
11SELECT EVENT, STATUS,'EXEC DBMS_LOGSTDBY.SKIP_TRANSACTION ('||XIDUSN||', '||XIDSLT||', '||XIDSQN||');' FROM DBA_LOGSTDBY_EVENTS A WHERE XIDUSN IS NOT NULL AND   A.EVENT_TIME >= SYSDATE - 60 / 1660;
12SELECT 'EXEC DBMS_LOGSTDBY.SKIP_TRANSACTION ('||XIDUSN||', '||XIDSLT||', '||XIDSQN||');' FROM DBA_LOGSTDBY_EVENTS A WHERE XIDUSN IS NOT NULL AND   A.EVENT_TIME >= SYSDATE - 10 / 1660;
13
14SELECT * FROM DBA_LOGSTDBY_SKIP;
15SELECT * FROM DBA_LOGSTDBY_SKIP_TRANSACTION;

     

7.增長apply進程個數

若是Apply進程過於繁忙，那麼能夠增長Apply進程個數。如下命令調整爲20，默認爲5個:

1SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
2SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('APPLY_SERVERS',20);
3SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

     

8.處理從主庫接收到的歸檔文件

邏輯DG在應用完歸檔日誌後會自動刪除該歸檔文件，這一特性是由邏輯DG中的2個參數控制的，它們分別爲LOG_AUTO_DELETE和LOG_AUTO_DEL_RETENTION_TARGET。

LOG_AUTO_DELETE的值默認爲TRUE，表示邏輯DG在應用完歸檔日誌後會自動刪除該歸檔文件，默認24小時以後刪除（由參數LOG_AUTO_DEL_RETENTION_TARGET控制）。若是但願禁用自動刪除的功能，那麼能夠執行下列語句：

1EXECUTE DBMS_LOGSTDBY.APPLY_SET('LOG_AUTO_DELETE', FALSE);

     

在告警日誌中會有相似以下的記錄：

1Fri Jul 27 13:48:53 2018
2LOGMINER: Log Auto Delete - deleting: /u01/app/oracle/flash_recovery_area/ORADGLG/1_202_886695024.dbf
3Deleted file /u01/app/oracle/flash_recovery_area/ORADGLG/1_202_886695024.dbf

     

在某些狀況下確實須要禁用歸檔文件的自動刪除功能，例如邏輯DG須要執行Flashback Database操做，若是你想恢復到以前的某個時間點，而後再接着應用，那麼就必需要有該時間點後對應的歸檔。假如LOG_AUTO_DELETE爲TRUE的話，應用過的歸檔已經被刪除，想回都回不去。

參數LOG_AUTO_DEL_RETENTION_TARGET表示邏輯DG在應用完歸檔日誌後的多長時間以後再自動刪除該歸檔文件。該參數僅在LOG_AUTO_DELETE設置爲TRUE以後才起做用，默認值爲1440分鐘，即24小時，能夠經過如下命令修改該值的大小：

1exec DBMS_LOGSTDBY.APPLY_SET('LOG_AUTO_DEL_RETENTION_TARGET', 1);

     

以上命令表示歸檔日誌被應用完以後，再過1分鐘纔會自動刪除該歸檔日誌。須要注意的是，這些設置僅適用於從主庫傳遞過來的歸檔文件歸檔到的位置不是閃回恢復區。若是正在使用閃回恢復區，那麼這些從主庫傳遞過來的歸檔文件將再也不根據參數LOG_AUTO_DELETE和LOG_AUTO_DEL_RETENTION_TARGET的值作處理。

若是禁止了邏輯DG歸檔文件的自動刪除功能，那麼必定要有相應的其餘解決方案，不能說取消了自動刪除功能，以後邏輯Standby數據庫接收到的Standby歸檔文件就再也不管它，這確定會產生問題，最起碼要考慮到邏輯Standby數據庫的存儲空間是有限的。

邏輯Standby數據庫接收到的歸檔文件並不會顯示在V$ARCHIVED_LOG視圖中，所以覺得經過RMAN中的配置自動刪除這些文件的但願也是會落空的。對於這類文件的刪除，正確的刪除方法一般會按照以下步驟操做：

首先執行DBMS_LOGSTDBY.PURGE_SESSION，該過程會檢查當前全部接收到的歸檔日誌文件，對於那些已經應用過，再也不須要（這裏是當前再也不需求，將來是否有可能須要就得由DBA來決定了）的文件進行標記，例如：

1EXECUTE DBMS_LOGSTDBY.PURGE_SESSION;

     

而後，查詢數據字典DBA_LOGMNR_PURGED_LOG，全部被DBMS_LOGSTDBY. PURGE_SESSION標記再也不須要的日誌都會記錄在這裏，例如：

1SELECT * FROM DBA_LOGMNR_PURGED_LOG;

     

該字典只有一列，即歸檔文件的實際路徑。最後根據顯示的路徑找到這些文件，而後在操做系統中刪除便可。

9.調整PREPARER（調製機）的進程數

若是備庫上有不少事務在等待Apply，可是還有空閒的Applier進程，且已經沒有idle狀態的PREPARER（調製機）進程，這時須要增長PREPARER的進程數。如下命令調整爲4個，默認爲1個:

1SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
2SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('PREPARE_SERVERS',4);
3SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

     

10.調整MAX_SGA，防止Paged out

經過如下SQL能夠查詢到是否發生了Paged out：

1SQL>select value bytes from v$logstdby_stats where name='bytes paged out';

     

若是以上查詢結果在增加，那麼查看當前MAX_SGA的大小:

1SQL>select value from v$logstdby_stats where name like 'maximum SGA for LCR cache%';
2VALUE
3---------------------------------------------------------------
430

     

能夠增大MAX_SGA:

1SQL>alter database stop logical standby apply;
2SQL>execute dbms_logstdby.apply_set('MAX_SGA',1000);
3SQL>alter database start logical standby apply immediate;

     

邏輯備庫須要將Redo記錄解析成LCR（Logical Change Records），會在Shared Pool裏分配一部分空間來做爲LCR Cache，若是Cache過小，就會像OS的虛擬內存管理同樣，須要作page out，這會嚴重影響應用日誌的性能。在默認狀況下，LCR Cache爲Shared Pool的四分之一，最少很多於30M（默認爲30M，最大能夠設置到4096M），不然SQL Apply不能啓動。若是機器的內存足夠，建議將LCR Cache儘可能設大一點，固然，同時Share Pool也要足夠大。若是機器內存有限，那麼能夠考慮將Buffer Cache減小一點來給LCR Cache騰出空間。

11.調整事務應用方式

默認狀況下邏輯Standby端事務應用順序與Primary端提交順序相同。若是但願邏輯Standby端的事務應用不要按照順序的話，那麼能夠按照下列的步驟操做：

①中止SQL應用:

1SQL>ALTER DATABASE STOP LOGICAL STANDBYAPPLY;

     

②容許事務不按照Primary的提交順序應用：

1SQL>EXECUTE DBMS_LOGSTDBY.APPLY_SET('PRESERVE_COMMIT_ORDER','FALSE');

     

③從新啓動SQL應用

1SQL>ALTER DATABASE START LOGICAL STANDBYAPPLY IMMEDIATE;

     

恢復邏輯Standby按照事務提交順序應用的話，按照下列步驟：

①仍是先中止SQL應用：

1SQL>ALTER DATABASE STOP LOGICAL STANDBYAPPLY;

     

②重置參數PRESERVE_COMMIT_ORDER的初始值：

1SQL>EXECUTE DBMS_LOGSTDBY.APPLY_UNSET('PRESERVE_COMMIT_ORDER');

     

③從新啓動SQL應用：

1SQL>ALTER DATABASE START LOGICAL STANDBYAPPLY IMMEDIATE;

     

邏輯備庫還有不少其它很是實用的SQL語句，這裏就不列舉了，讀者能夠關注做者的微信公衆號，做者天天會推送一個很是實用的SQL語句。