經驗不是絕對，證據才是一切

| | | | | | 8則回應

    

我想，比較好的作法，是在問題發生時、甚至發生前，相關人員就能掌握相關證據。在現今各式各樣的系統裡，其實己經具備這樣的功能。系統管理員可以針對各種不同的可能發生事件，指派負責人員，並透過系統設定的方式，當特定事件發生時，系統就會以E-Mail、甚至是簡訊，在第一時間內馬上通知。

如此一樣，管理人員將可在系統問題繼續惡化前，有較充裕時間來採取必要解決行動。這類的系統事件通知，好一點的通常都會伴隨著系統在事件發生的當下、自行蒐集到的一些相關資訊，所以，管理人員可以馬上縮小所以調查的範圍， 縮短問題解決的時間。像這樣內建的系統功能，應該多加利用才是。

事件發生時馬上被通知，還比不上另一個更好的做法，就是防範未然。

「預防重於治療」，這是每個人保健身體的老生長談，其實這樣的原則，也可適用於管理的電腦系統上。

因為，在系統發生問題前，一定都會有些跡象發生，若是能在跡象發生時就掌握住，那就可以在問題還沒發生前先採取補救措施，而不用等到問題發生時才手忙腳亂。

例如，每個資料庫系統都會利用Logical Log的機制來減少對實體資料表的存取。若Logical Log不是設成動態分配空間(就是空間不夠時，系統自己會再分配空間出來)的話，那麼一旦Logical Log空間被用光，整個資料庫系統就會停擺。

因此，比較積極的做法是，當Logical Log使用率達到某個水準，像是60%時，就要發出警訊。這時候，系統管理員就可以先採取必要措施，看看是不是有某個交易(Transaction)太長， 遲遲未Commit、或是因系統過於忙碌，之前Logical Log分配的空間不夠用等。

無論是那個原因，系統管理員都可以選擇合適的作法(像是強迫中止有問題的交易，或是手動加大Logicl Log的空間)，讓問題發生的機會都沒有。

像這類的預警程式，其實都很簡單。若是在Unix系統上，可以利用作業系統本身己有的 Utility程式，透過Shell Script來撰寫，然後排入Cron Job裡，定期執行。初期預警的對象，可以針對資料庫系統會用到的系統資源，像是作業系統的CPU，Memory以及Disk I/O，資料庫系統本身的Virtual Process、DB Space I/O與Virtual Memory，進行監控。

再加上這類的系統資源，都有一個絕對數值可做為比較的基準，您可以任意指定警戒水準。利用這樣簡便的作法，您不僅可以更稱心愉快的管理軟硬體系統，在發生問題時，系統管理人員也能「有憑有據」的解決問題、排除不必要的紛爭。