關於閃回區溢位導致的資料hang（r11筆記第12天）

對於Oracle資料庫的閃回區的設定，之前和一個同事和討論過，總體來說有一些不同的意見。

首先這個閃回區是一個邏輯的概念，閃回區的大小不會嚴格依賴於磁碟空間的情況，比如磁碟空間目前剩餘100G,但是你設定閃回區為200G是沒有問題的。

如此一來，和只使用歸檔引數想比，這個閃回區似乎有一點問題，總體來說閃回區的管理還是比較方便的，可以監控管理閃回區中的歸檔，閃回日誌，備份等的大小。

使用的檢視為v$flash_recovery_area_usage，在11g做了簡化，為v$recovery_area_usage

一個檢視閃回區的使用率的結果如下：

select *from v$flash_recovery_area_usage;

FILE_TYPE               PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES
----------------------- ------------------ ------------------------- ---------------
CONTROL FILE                             0                         0               0
REDO LOG                               .18                         0               2
ARCHIVED LOG                         40.09                         0             320
BACKUP PIECE                             0                         0               0
IMAGE COPY                               0                         0               0
FLASHBACK LOG                        59.08                         0             366
FOREIGN ARCHIVED LOG                     0                         0               0閃回區的使用有幾個地方比較糾結，那就是關於閃回hang的問題。

簡單來說，可以歸為以下幾類。

首先是閃回區空間設定大於磁碟實際空間大小，這種情況下，竟然閃回區可用，但是磁碟空間不足，這種情況下就會造成歸檔無法生成或切換，影響會很大，當然系統的監控是必要的，如果疏忽了，那麼資料庫層面的這一道防線就會因為閃回區的這種設定而被突破。

第二種情況下是閃回區的大小溢位，比如設定閃回區大小為100G,剛好達到了臨界值，這個時候很可能出現兩種情況，一種是無響應，表現為登入，登出都會完全沒有響應，資料庫直接被卡住，這種情況下很可能是有線上的事務在執行。而另外一類則是非常經典的錯誤。

SQL> conn test/xxxx
ERROR:
ORA-00257: archiver error. Connect internal only, until freed.

想必這個問題大家都見過很多次了，這個問題其實相比資料庫hang的影響要略微小一些。至少應用連不進來，而第一種會造成的結果是，如果應用不斷嘗試連線，但是無響應，就會短時間內造成大量會話阻塞，然後消耗系統資源殆盡。如果有的伺服器抗不了瞬間的壓力，還可能瞬間當機。

第二類問題其實還算是相對溫和的，登入不了，連線直接被拒絕。

解決方法其實就很簡單了，一種是擴大閃回區，另外一種是刪除一些不需要的歸檔檔案等，釋放閃回區的空間。

當然還有一種場景會把這個問題放大，那就是核心系統一旦出現這類問題，這個影響就會非常大，這句話怎麼理解，如果因為閃回區過小導致了資料庫hang的問題，在5分鐘的時間內是完全沒有響應的，儘管你使用sysdba修改了閃回區大小，調整了空間，但是問題會短時間內（預設5分鐘）記憶體在，如果碰上這樣的情況，絕對會讓人格外抓狂，在我的職業生涯中還真碰到過。在很緊急的關頭，你的第一反應和冷靜處理就絕對反映出了你真正的技能和知識儲備。說不緊張那都是騙人的，只能讓自己的心裡平復一下，想明白該怎麼做，避免錯上加錯的操作讓問題向另外一個方向走去。

這個5分鐘是怎麼得來的，我是專門做了下這類測試，開啟了多個視窗，加上人工的操作延時，抓取到的時間戳如下：

SQL*Plus: Release 11.2.0.4.0 Production on Wed Dec 14 17:52:18 2016
SQL*Plus: Release 11.2.0.4.0 Production on Wed Dec 14 17:57:38 2016從這個結果可以基本看出是一個5分鐘的頻率，因為有手工的延遲問題。

當然這只是猜測，有什麼其他的方式來論證呢，我首先檢視了資料庫的隱含引數。發現還真有幾個隱含引數的設定是300秒的。

_hang_ignored_hangs_interval
_flashback_max_standby_sync_span
_dbwr_scan_interval
_hang_monitor_archiving_related_hang_interval

當然要做嚴謹的測試，還是很有難度，自己反覆嘗試沒有得到一個確鑿的證據指向這幾個引數會直接影響Hang的問題，那還有什麼問題呢。

還有一個就是資料庫的歸檔引數，歸檔引數有一個屬性是reopen，預設是300秒。

自己測試了幾個場景，有的表現要好一些，有的則達不到預期效果，所以這個引數作為備選。

還有一個引數是,這個引數還是值得好好琢磨一番，但是目前來看，經過大量的測試沒有完全驗證。

所以經過我的一番測試，達到臨界值的情況下，有些場景中以上的隱含引數和歸檔引數設定都會有一定的影響，但是沒有產生立竿見影的效果。

這個測試還要繼續進行，大家有什麼更好的建議也希望一併指出。