[zt]Logical standby同步故障的處理過程

故障描述：
早上到公司，應用人員說邏輯standby庫和生產庫資料不一致，簡訊報錯從昨天上午10點開始


分析過程：
1。先看兩邊的alert.log，生產庫一切正常，沒有發現通訊不暢以致不能歸檔到遠端歸檔路徑的問題
standby端的alert.log發現以下資訊：

LOGSTDBY event: ORA-16204: DDL successfully applied
LOGSTDBY stmt: -- Create sequence
create sequence seq_reject_user_list
minvalue 1
maxvalue 99999999999999999999999
start with 1
increment by 1
Tue Mar 29 10:56:07 2005
LOGSTDBY event: ORA-16204: DDL successfully applied
LOGSTDBY stmt: -- Modify the last number
alter sequence SEQ_REJECT_USER_LIST increment by 741 nocache
LOGSTDBY event: ORA-16204: DDL successfully applied
LOGSTDBY stmt: alter sequence SEQ_REJECT_USER_LIST increment by 1 nocache
LOGSTDBY event: ORA-16204: DDL successfully applied
LOGSTDBY stmt: alter sequence SEQ_REJECT_USER_LIST increment by 1 cache 20
Tue Mar 29 10:57:57 2005
LOGSTDBY event: ORA-00001: unique constraint (SMS_USER.IDX_REJECT_USER) violated
LOGSTDBY stmt: SMS_USER.REJECT_USER_LIST (Oper=INSERT)
Tue Mar 29 10:58:02 2005
LOGSTDBY event: ORA-00001: unique constraint (SMS_USER.IDX_REJECT_USER) violated
LOGSTDBY stmt: SMS_USER.REJECT_USER_LIST (Oper=INSERT)
LOGSTDBY event: ORA-00001: unique constraint (SMS_USER.IDX_REJECT_USER) violated
LOGSTDBY stmt: SMS_USER.REJECT_USER_LIST (Oper=INSERT)
...
...
...
LOGSTDBY event: ORA-00001: unique constraint (SMS_USER.IDX_REJECT_USER) violated
LOGSTDBY stmt: SMS_USER.REJECT_USER_LIST (Oper=INSERT)
Tue Mar 29 10:58:24 2005
Errors in file /u01/app/oracle/admin/sms/bdump/sms_p009_12133.trc:
ORA-07445: exception encountered: core dump [knasnfd()+126] [SIGSEGV] [Address not mapped to object] [0x0] [] []

經過詢問，應用人員說昨天確實對該表進行過操作，批次往表裡導資料，違反了唯一性約束條件。

2。然後檢視生產庫和邏輯standby端的sequence，發現沒有問題，說明所有的歸檔日誌都已經被邏輯standby端收到。

3。接著在生產端做了一個測試，建了一張表，插入了一行資料，進行一次日誌切換，到邏輯standby端檢視檢視，dba_logstdby_log，發現已經收到最新的歸檔日誌，但是並沒有找到我剛才新建的表。

4。初步確定日誌傳送和接收沒有問題，再進一步看看日誌apply的狀態，檢視檢視dba_logstdby_progress

SQL> alter session set nls_date_format='DD-MM-YY HH24:MI:SS';

Session altered.

SQL> select * from dba_logstdby_progress;

APPLIED_SCN APPLIED_TIME        READ_SCN READ_TIME         NEWEST_SCN NEWEST_TIME
----------- ----------------- ---------- ----------------- ---------- -----------------
3910598216 29-03-05 10:07:07 3910576561 29-03-05 07:54:19 3911585635 30-03-05 09:58:16

從結果我們可以看出，APPLIED_SCN和NEWEST_SCN不一致！！！，說明從昨天上午10:07:07開始，邏輯standby庫就停止了把日誌的轉化成SQL然後apply。

進一步確認，查詢檢視v$logstdby_status
SQL> select * from v$logstdby_stats;
no rows selected.

SQL apply操作已經意外停止

問題找到！！！！


查詢原因：

1。查了一下Oracle Data Guard Concepts and Administration中的page 412，What to Do IF SQL Apply Operation to a Logical Standby Database Stop，發現如果遇到了邏輯standby不支援的SQL語句和package，那麼SQL apply操作將會中止。

檢視檢視dba_logstdby_events的最後一條記錄（一般情況下，最後的一條記錄應該能反映出導致SQL apply停止的原因）
SQL> select * from dba_logstdby_events where rownum=1 order by event_time desc;

EVENT_TIME        CURRENT_SCN COMMIT_SCN     XIDUSN     XIDSLT     XIDSQN
----------------- ----------- ---------- ---------- ---------- ----------
EVENT                                                                            STATUS_CODE
-------------------------------------------------------------------------------- -----------
STATUS
------------------------------------------------------------------------------------------------------------------------------------------------------
29-03-05 10:58:23  3910598215 3910598216          4         28     262321
SMS_USER.REJECT_USER_LIST (Oper=INSERT)                                                    1
ORA-00001: unique constraint (SMS_USER.IDX_REJECT_USER) violated

和alert.log裡的錯誤吻合，OK，已經找到導致SQL apply操作停止的原因了


處理辦法：

1。重啟SQL apply程式：
SQL>alter database start logical standby apply;

2。檢視檢視v$logstdby，看各個程式的工作是否正常

3。又過了一會，執行語句
SQL>select * from dba_logstdby_events where rownum=1 order by event_time desc;
檢視apply的情況，發現過了好久SCN都沒有增加，難道程式又死掉了？
檢視os程式ora_lsp0_sms已經不在了，LSP程式又死掉，是不是由於日誌裡記錄了大量的上述錯誤操作資訊，當LSP執行錯誤操作到一定數目之後就掛掉？（原因還需要進一步弄清楚）
只好再次手動重啟LSP程式
SQL>alter database start logical standby apply;

OK，同步正常，查詢檢視dba_logstdby_progress，APPLIED_SCN和APPLIED_TIME逐漸增加

3個小時後，同步完畢！！



後記：

看了看Oracle Data Guard Concepts and Administration想查詢SQL apply失敗的原因，也沒有太詳細解釋，於是到metalink上搜了一把
看到logical standby由於遇到unique constraint的錯誤導致SQL apply中止，是Oracle 9204版本的一個BUG（bug# 3427176 ），我使用的是9205版本的，這個bug在9205版本中並沒有被修正，具體參照這個BULLETIN：