主庫千萬級的資料更新後，STANDBY日誌應用大量延遲的問題處理

因為業務需要，不得不在生產上更新一個千萬級的大表，更新過程中產生了4個G左右的日誌後發現此更新會導致其他問題，取消更新，然後更正更新的邏輯後，重新對這千萬級的資料進行更新，產生6個多G的日誌後，更新完成，但是卻造成了其他兩個邏輯STANDBY的大量延遲。如何加快這些日誌的應用，是一個比較嚴重的問題。

[@more@]

1、首先是加快主庫的更新操作，那麼首先關閉主庫對STANDBY的歸檔，減少主庫寫STANDBY庫日誌對主庫產生的壓力，這需要在更新開始前在主庫設定log_archive_dest_state_N引數為DEFER，然後主庫切換日誌來啟用這個新的引數設定。注意：如果是RAC的主庫，則每個庫都需要設定此引數，並且每個庫都進行一次日誌切換操作。

2、主庫更新完成後，可以在備用庫做一些設定來加速日誌應用的更新，引數如下：
APPLY_SERVERS＝16－－可以設定更多的並行應用的進行來提高應用的速度
PREPARE_SERVERS＝8－－可以設定更多的準備程式來提高應用速度
MAX_SERVERS＝40－－設定最大可使用的程式數，要大於所有的APPLY、PREPARE、ANALYZE等程式之和
－－－－設定以上並行引數的時候，要注意PARAMETER中的PARALLEL引數相關的設定也要能支援上面的調整。
_EAGER_SIZE＝4001－－這個是一個隱含的引數，用來設定大事務和小事務時間的分界線，更新記錄行數大於此值的被認為是大事務，提高這個引數的設定對大事務的應用有提高。查詢v$logstdby_stats檢視，如果沒有很多的bytes paged out的話，說明這個引數還可以設定的更大。
MAX_SGA＝2048－－LCR可使用的SGA大小，如果過小則會產生很多的PAGE OUT，可以調整此SGA的大小，此SGA是資料SHARED POOL中的一部分的，所以要保證SHARED POOL也足夠大
PRESERVE_COMMIT_ORDER = FALSE－－設定事務不按照嚴格的主庫上事務發生的順序來進行應用，也可以提高應用的速度。

3、如果以上招數都不能解決問題，那可能就是碰到了ORACLE的BUG了，參考5327658.8，上面說到如果更新百萬級大表的話，可能造成STANDBY的應用非常慢，可以透過升級來解決問題，需要升級到10.2.0.4或者11.1.0.6。

4、我這次千萬級的更新使用了2的方法後，還是應用很慢，整整一天應用都沒有同步過來，後來發現可以把一個表的DML操作SKIP掉，然後重新同步這個表來實現。於是先使用dbms_logstdby.skip把這個表所有的DML操作全部忽略，加速應用，等到積累的日誌全部應用完成後，使用dbms_logstdby.instantiate_table進行表的同步，結果發現這個同步操作也是很慢，半個多小時了還是在進行中，於是取消操作。後來發現dbms_logstdby.instantiate_table基本上就是在STANDBY庫先把表刪除，然後再使用IMPDP把這個表的資料透過DBLINK導過來。既然這樣可以，那就手工做吧。

5、把STANDBY的APPLY停下來，然後查詢STANDBY的V$LOGSTDBY_PROGRESS，得到當前的APPLY_SCN，那麼利用主庫的FLASHBACK特性，先把STANDBY的表TRUNCATE掉，然後使用INSERT /*+ APPEND*/ INTO TABLE SELECT * FROM AS SCN OF XX把資料導過來，其中的XX就是上面查到的APPLY_SCN。這當中其實就是大家很熟悉的導資料操作了，可以使用先刪除索引，匯入完了再重建，使用APPEND提示等等多種手段來提高匯入的速度。

6、經過10多分鐘，資料導完，建完索引，整個過程不到半個小時，比dbms_logstdby.instantiate_table還快一些，雖然繁瑣，但是過程比較透明，出現問題也容易處理的多。

建議和總結：
1、方法2中的很多引數在平時的日誌應用中就可是設定好來加速日誌應用速度。
2、對於大批次的資料更新，儘量使用分批提交的方式，把大事務拆分成小的事務，而且進行要比_EAGER_SIZE引數設定的要小一些
3、PRESERVE_COMMIT_ORDER引數在日誌同步完成後，為了保證事務和生產上的順序一致，最好把這個引數使用DBMS_LOGSTDBY.APPLY_UNSEGT取消。
4、因為主庫的一個DML的操作在STANDBY庫會被分解成一個個單獨的更新的sql，所以可以合理利用規則來SKIP這些DML，然後再手工同步的方式來進行
5、有可能的話，升級資料庫系統