Thinking in Robert

在多次處理資料庫效能瓶頸的經驗中，有幾點是重要的方向：主機、Storage、作業系統、網路、資料庫、應用程式，有些是因，有些是果，當整體系 統效能不彰時，系統工程師可能會去監看主機磁碟、網路、記憶體的使用，可能會得到一個方向是指向資料庫，接著DBA去監看資料庫，從記憶體、效能、連線等 資訊的蒐集分析，又可能指向主機記憶體或不足導致SWAP，這樣的結論，看起來是買個記憶體來插上去就行了吧！當然不是，這些都可能是某些原因產生的結 果。

在我的工作環境中，有一些效能瓶頸是廠商DBA無法驗證或分析的，廠商DBA能提供大量的系統效能分析報告，但都僅止於資料庫與主機之間，某些點是 無法觀察到的，幾次經驗分析後結果是這樣的：
1.寫程式的人， 沒有把SQL語法寫好，導致資料庫效能不彰。
Oracle是個很奇妙的東西，寫SQL查資料，一定得搭配索引，這對數十萬筆以上的 資料表來說，有無「用到」索引效能的差異非常大，更進階的，如果去研究他的優化器，你才會發現，要讓DBA加班，SQL隨便寫就行了，他晚上會留下來找找 為什麼這麼慢 。另一個會讓寫程式的人犯的錯誤就是忽略程式開發過程與資料表索引的同步，在系統開發初期，因為沒什麼資料，Table有無索引，或是SQL有無撰寫正 確，沒人能感受出來差異，日子一久，正確的SQL沒搭配Table Index，或是根本沒把SQL寫對，系統自然而然的就變慢，效能瓶頸就來了。

2.寫程式的人，沒有好好思考資料庫連線資源，因此消耗掉主機記 憶體資源。
在專屬模式下的Oracle服務，每一個Client端的程式連到資料庫都必須先連線通道，這樣的連線建立會在主機的作 業系統消耗掉些許的記憶體，Oracle的Service也會消耗掉一些記憶體，因此，在主機資源(尤其是記憶體)較不充沛的環境下，節省連線 Session是很有效的，否則當作業系統實體記憶體耗盡時，將會進行大量需擬記憶體的I/O動作，，這時所有系統將感受到效能低落，更慘的情況則是部分 使用者因記憶體不足無法連線。因此，Oracle才有另一種共享模式的服務，軟體部分也能有三層式來解決這類問題。

3.許多台資料庫主機為了方便與資料一致性，使用DB-Link 互相開View導致，同一系統重複使用掉兩台主機連線資源。
DB-Link在Oracle中確實是好用，而且效能還不錯。在一個龐 大複雜的IT環境中，可能會把資料庫切分為數個，各個都是屬性相近的，但資料庫相互之間確有部分Table是必須在多個資料庫中出現並被運用，因此 DB_Link能讓Oracle跨資料庫主機開View，這麼方便的功能卻必須使用主機資源來交換。明明主機A只提供給HRS系統來使用，使用HRS的使 用者並不多，為何A主機卻效能不足？如果仔細去觀察，原來B主機上面的ERP系統有許多的資料表(View)來自A主機，因此，當大量的ERP系統使用者 登入B主機時，可能也會有不少的連線由B連向A，耗掉A主機的資源。這樣的問題我稱他做資料庫耦合性，該如何解決？切斷耦合性就行，但實務上卻不簡單，切 斷耦合性勢必在兩台主機都開立實體Table，但資料一致性問題卻又必須被重視，而且如果不只兩台Oracle DB都必須同步呢，這樣的問題將會考驗著DBA對工作環境整體系統架構的瞭解深度，哪些該是Table存在，哪些該是View存在，方便、效能與正確性， 是DBA必須去抉擇的。

上述的問題，換了主機加了記憶體，或許能解決當下的問題，但是卻無法擊中核心，系統在規劃時決定了資料庫架構，耦合性問題就是當時種下的因，資料庫 交易程式的開發，SQL語法只佔程式碼的極小部分，不見得每個程式設計師都能十分重視，當軟體系通規模一龐大之後，「資料庫效能不好」的聲音就會悄悄的圍 繞在大家身邊。真正問題在哪裡？花錢解決，還是靠技術來解決？見仁見智，因環境而異，有些系統的歷史包袱大到不如建議老闆花錢買新主機，但個人還是期待根 本原因解決的一天。