SGA設定過大造成的系統效能問題

SGA設定過多造成的系統效能問題
2010-2-3
深圳

中午，突然接到Manager的電話，說SAP測試環境有效能問題，需要我緊急接入電話會議。這個環境平時不是我管理的，可能是老大沒有找到人，臨時把我call上了。
沒有辦法，頂著頭皮上啊。
在電話會議上，一群人在說個不停。Manager把帳號資訊發給我，我登入到系統中，檢視下系統資源使用情況，發現實體記憶體使用了90%，IO有些大，有幾個DISK處於100%的繁忙，CPU比較閒。他們說現在不是Performance的問題，而是在SAP前端系統沒有響應。
檢視了等待事件，鎖，ALERT的日誌，都沒有特殊的情況。在等待事件中，發現還是有些IO有關的事件。
除了我的檢查外，使用者還建議去看下SQLNET等日誌檔案，檢視下是否SAP不能連線到資料庫。
看了檔案，沒有任何發現，還看下相關的SQLNET的引數配置，也是正常的。
除此之外，沒有發現有價值的線索。
對於陌生的系統，我習慣性的看下系統的配置。我在他們一籌莫展的時候去檢視系統配置，問題就暴露出來了。
檢視了系統配置了32G的記憶體，那SGA分配了多少，最高不能超過25G啊。
去檢視SGA的引數，不看還好，一看嚇一跳。分配了32G的記憶體給sga_max_size.
這是誰做的好事啊.沒有一點Oracle的概念啊.Oracle的推薦是分配80%的記憶體給SGA+PGA。好傢伙，全部都給了SGA，那PGA還怎麼跑啊。
和Manager說了後，他們討論後給出建議：給Lpar分配14G的記憶體（這是Ibm的P570，做了LPAR，可以做到動態調整記憶體），或者調小SGA的size；
@￥#@￥#￥#@！@#一番討論後，最後決定給Lpar分配14G的記憶體。
在觀察30分鐘，系統恢復正常。
後來得知，他們這個PFILE檔案是從生產庫中拷貝過來的，沒有修改就直接使用在測試環境中了。而生產環境的記憶體是64GB。DBA在做時候沒有考慮到環境的差異性，才導致這次危機。
問題找到了，危機解除了。可認為這種情況不應該發生啊。
俗話說，陽光底下無新鮮事啊，類似的問題很多DBA們都遇到，但是這種問題“屢禁不止”。對於DBA來說，細心、多問個為什麼、多思考下問題才能儘可能減少出錯的機率。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/40239/viewspace-628422/，如需轉載，請註明出處，否則將追究法律責任。