關鍵業務系統的最佳化小技巧

關鍵業務系統的效能最佳化對於企業的業務發展來說至關重要，在十五年前，我們給某運營商做最佳化的時候，當時使用者說，因為系統效能的問題，營業廳排隊經常排長隊。有一次中午午休的時候，還有十多名顧客沒有辦結，於是客戶和營業員發生了衝突，把營業臺上的電腦都砸了。這個例子雖然十分極端，不過也從另外一方面說明瞭高效執行的業務系統對企業核心業務的影響。前陣子去醫院做核酸檢測，發現現在醫院已經沒有了排長隊的問題，大量的自助服務終端替代了以往排著長隊的視窗。我發現了一處自助終端區沒什麼人，跑過去發現這組終端都關閉了，於是無奈只能去有人排隊的終端辦理掛號。雖然前面只是排了兩個人，不過掛號的時間還是挺長，因為掛號應用十分慢。後來和醫院的熟人聊起這個事，他告訴我因為系統很慢，所以只好再增加一組自助終端，業務忙的時候開起來。我當時就很奇怪，既然已經增加了一組終端，為什麼平時不開。他說這也是無奈之舉，那組終端開了，系統就更慢了，實際上總體來說也快不了多少，只是能讓排隊的每個隊伍短一些而已，所以平時排隊不是很長的時候，那組終端是關閉的。

事實上，對於核心業務系統的問題，企業都是十分關注的，只是解決問題採用的手段不同而已。對於大多數傳統企業的核心業務系統的問題，很可能都與資料庫的效能有關。特別是HIS之類的結構比較簡單的系統，大多數HIS系統都是PowerBuilder開發的應用，後面連了一個Oracle或者sql server資料庫。企業的核心繫統的核心模組往往都是比較穩定的，只要確保這些核心模組的效能穩定，就能夠保證核心系統資料庫的效能穩定。對於核心系統的核心業務模組，花點功夫去保證其效能穩定還是十分有價值的。

回到我們今天的正題，如何才能確保核心業務系統資料庫的效能穩定呢？我們能夠透過哪些花費不多的小技巧來確保核心業務系統的資料庫效能穩定呢？其實我們只要重點關注三方的要素，就可以基本上保證核心系統資料庫的穩定了。這三方面分別是：1）關鍵業務模組SQL執行計劃的穩定性；2）資料庫伺服器的IO延時穩定性；3）保證足夠的實體記憶體。

首先，確保核心業務模組SQL執行計劃的穩定性。資料庫應用的突發性效能問題很多都是與執行計劃的變化有關的。本來執行的很好的SQL突然變慢，大多數情況下是與執行計劃的變化有關的。對於很多大企業的核心繫統，在開發的時候，就對核心交易的SQL做了十分嚴格的程式碼走讀，也規定了核心業務系統不能使用過於複雜的SQL，甚至在某些銀行，規定關鍵業務系統的核心交易相關的SQL不允許使用多張表關聯的語法。透過SQL語句的最佳化，可以解決大多數SQL執行計劃突變的問題。

另外一個確保執行計劃穩定的原則是針對核心業務相關的表的索引要做規範的設計，不允許這些表上的索引亂用，系統上線後不允許在核心業務表上隨意建新索引。一張表上有多個相似的索引是引發錯誤執行計劃的常見因素，我們也遇到過多次因為新建一個索引而導致核心業務系統效能受到影響的案例。

制定合理的資料歸檔計劃，定期歸檔核心業務資料，確保核心業務資料表的容量緩慢線性增長是確保核心業務系統效能穩定的另外一個好的方法。在二十多年前，銀行使用者就看到了核心業務表資料增長對效能的重大影響，因此都設計了十分完備的核心業務資料轉儲與歸檔的方案。這三十年的實踐表明，這個方法是十分有效的。

定期重建索引對於穩定核心業務模組的執行計劃和提升關鍵業務模組的效能的效果也是十分好的。十多年前，我給一家銀行做維保服務的時候，向他們的IT部門領導提出了這個觀點。剛開始雖然他們不太相信，不過依然做了一次嘗試。我們利用一個週末的晚上對所有核心業務相關的表上的索引做了一次rebuild，第二天統計出來的核心交易時間證明瞭，這次操作讓第二天的平均核心交易時間縮短了20%，從此他們就把這項工作做成了一個定期任務，每隔三個月做一次。這十多年堅持下來，效果十分不錯。

與第一個問題相比，確保IO延時穩定性的問題，大家可能考慮的並不多。現在大部分核心系統的儲存系統較十多年前都有了巨大的效能提升，往往核心儲存的能力是足以支撐核心業務的。不過持續監控核心業務系統的IO延時，確保其穩定維持在合理的範圍內依然是十分重要的。從資料庫角度、作業系統角度和後端儲存角度三方面監控核心系統IO延時，一旦延時出現異常增長，則儘快找到原因，解決問題，對於確保核心系統效能也是十分關鍵的。十年前，一個銀行客戶升級儲存系統，更換新儲存的時候因為成本問題，把磁碟從老的3.5寸的15000rpm SAS盤換成了2.5寸的10000rpm的SAS盤。新系統上線那天，業務部門發現日結操作的時間下降了50%，最後經過分析，發現就是因為10K的SAS盤的IO延時比15K的高30%左右，導致了日結業務的問題。發現問題的根源後，解決問題的方法也就容易制定了，臨時性的方案是擴大DB CACHE，減少IO的總量，最終的方案是在本儲存上增加一組SSD盤，把和日結相關的資料放到新的磁碟組上。要確保IO延時的穩定性，一定要加強對IO延時的監控工作，從資料庫、作業系統和儲存埠三方面去監控IO延時，任何一方面出現問題都給予足夠的重視，找出問題的原因，是確保核心資料庫系統效能的又一個重要的工作。

確保作業系統有足夠的實體記憶體，不會出現大規模，長時間的換頁是確保核心系統效能穩定的另外一個十分重要的工作。很多使用者只要配置了足夠的實體記憶體就不太關注這個問題了。實際上，隨著我們系統的變化，哪怕配備了足夠的實體記憶體也不一定能保證我們的系統不換頁。幾年前遇到過一個銀行客戶，他們的系統經常在業務高峰期出現效能抖動，原本100毫秒以內完成的核心交易，在效能抖動時高達7/800毫秒。經過電話的溝通，我把問題定位到換頁上，他們也覺得奇怪，系統有512G的記憶體，SGA配置了240G，會話數量也不多，怎麼會出現這麼嚴重的換頁呢？後來我們發現最近他們做過一次最佳化，最佳化廠商建議他們對SGA的擴容，從200G擴充到了240G。於是我讓他們用svmon分析下實體記憶體的使用情況。原來問題十分簡單，他們設定了200G多點的LARGEPAGE，SGA從200G擴容到240G後，LARGEPAGE不夠用了，於是SGA沒有使用LARGEPAGE，而以前配置的200G LARGEPAGE又不能被普通的ORACLE程式使用，於是512G的實體記憶體被廢了200G，當然就經常會出現換頁了。