邏輯STANDBY負載高，應用緩慢的解決

一個邏輯STANDBY庫提供些報表業務，不過最近發現這個庫的負載有點偏高，而且SQL APPLY也有些緩慢。想著這個庫是執行在NAS上的，而且只是一個千兆的網路，如果使用者太多或者壓力太大，響應緩慢是正常的，但是登陸系統卻發現 IOWAIT很小，但CPU資源佔用很多，而且奇怪的是佔用CPU資源多的還都是P開頭的並行程式，並行程式為啥佔用這麼多CPU呢？[@more@]

首先想到的是有表或者索引PARALLEL開的太高，但查詢後發現這些程式並不是使用者前臺程式，而是系統後來SQL APPLY使用的程式，並且等待的都是CACHE BUFFER CHAINS的事件。這個問題以前處理過，因為表沒有主鍵或者唯一索引，導致SQL被挖掘出來後，不得不進行一個全表掃描去APPLY這個SQL，全表掃描多了就會導致這個問題，但看看主庫和STANDBY庫，這表確是有主鍵的。透過V$SESSION抓了半天，抓到了一個UPDATE的SQL，語句很簡單，根據主鍵去進行更新，但從AWR報表中去看，這麼簡單的一個語句每次執行的邏輯讀居然有19893，這肯定就不對了。去V$SQL_PLAN查詢執行計劃，發現是一個全表掃描，而這個表已經一個多G了。這個SQL經過挖掘後，ORACLE會給它加上/*+ streams restrict_all_ref_cons */這樣的提示，於是開始懷疑這些提示有問題，或者撞上BUG了，導致SQL的執行計劃不正確。

無從下手之時發現執行計劃很奇怪，全表掃描的COST非常低，看來估計是統計資訊出現問題了。於是到DBA_TABLES中查詢，發現這個表根本都沒有分析過。而且檢視其他表，發現很多表都沒有分析過，於是作了個全庫的統計資訊收集。收集後SQL的執行計劃自動變成了對PK的唯一掃描，問題得到解決。

在10G中，ORACLE會自動建立收集統計資訊的schedule來進行統計資訊的收集，但是在邏輯STANDBY上，因為schedule的不支援，會導致統計資訊沒有被收集（同時EXPDP等依賴schedule的功能也都不能使用）。手工新增一個後臺的CRONTAB來定期收集統計資訊就搞定了。