2
結落在資料庫或應用程式，這時 DBA 跟程式設計師可能因各自立場不同而互踢皮 球，無法合力解決問題，那麼問題就不能早一點被解決。
根據市場研究機構 Unisphere 在 2011 年對 Oracle 產品與技術用戶的調查 (《Managing the Rapid Rise in Database Growth: 2011 IOUG Survey on Database Manageability》[1]指出，因為效能問題導致停機的狀況中，60%為 SQL（Structured Query Language）語法的調優(圖 1)。可見，SQL 影響效能的程度不能小覷。對於 一些程式設計師而言，著重於資料存取及處理結果的正確，忽略資料存取的效率，
這點往往是埋下日後系統出現瓶頸的地雷。因為系統開發時，沒有大量資料可以 測試，程式設計師僅用少許的幾筆資料來測試程式邏輯，無法測出潛在的問題。
日後當系統運行一段時間後，資料量到達一定的數量，問題就可能顯現出來了。
現行常見的資料庫多數有自家的效能監控工具和 SQL 優化工具，例如：Oracle 、 SQL Server、DB2 UDB，且市面上也有不少資料庫管理工具，例如：Quest Toad、
Embarcadero。使用這些工具對於資料庫管理確實有很大的幫助，但其取得的成本 高。對於一些小企業，在經費的考量下購置的資料庫也許就沒有包含效能監控工 具可以使用。
3
圖 1 造成非計劃停機是何種性能問題
資料來源：2011 IOUG Survey on Database Manageability
1.2. 研究目的
在系統效能監控工具中強調 SQL 語句在某段時間區間佔用了多少系統資源，
並根據 CPU Time 排序 TOP SQL，以幫助資料庫管理者針對 TOP SQL 做調校。資 料庫管理者分析這個 SQL 語句、改寫、加上必要的索引、測試，以新的 SQL 語句 取代了原來有問題的 SQL 語句執行。但為什麼系統還是出現效能不佳的情形？原 因出在單從系統資源的觀點來解決問題，而忽略了其他需要考慮的重要因素，而
4
出現的盲點。例如，一個查詢消耗了很多系統資源，可是他一天才執行一次而且 都是在凌晨 2~4 點完成，那麼針對這個查詢我們去做調校，對整體系統效能不會 有太大的提昇。另一個情況，如果從系統資源消耗的程度來看，這個查詢並不會 消耗太多系統資源，可是頻繁的執行這個查詢，也會使得系統整體效能受到影響。
因此，除了系統資源的數據可以參酌，跟效能最相關的莫過於查詢 SQL 語句 的寫法及相關索引是否建立，此時可能還需要查詢計畫成本來了解是否還有更好 的方法來改善效能。
不同的資料庫系統所提出的介面是各式各樣的，除了系統資源的資訊外，會 有約略的不同，那麼資料庫管理者還需要哪些重要的訊息，能供其判斷哪個 SQL 語句有改善的必要。若能一併將判斷問題查詢語句的資訊整合，以系統資源的消 耗為排序，就是本研究的目的。因此本研究將發展出一套簡單、實用、低成本的 TOP SQL 使用者介面，藉由記錄下來的 SQL Statement 運行狀況，從中剖析效能瓶 頸的問題，找出可能的問題 SQL，必要時從 TOP SQL 中選擇進行長時間的觀察。
效能數據化的呈現可作為資料庫管理者與程式設計師共同解決問題的輔助工具。
5
DBMS 將資料從輔助儲存體(SS)經由記憶體層次結構(memory hierarchy) 分別包括 I/O、 主記憶體、 L2 cache 、L1 cache，送到處理器執行， DB 效能研究大部份 著重在 SS 跟 L2 cache 之間, 稱為「Smart data storage techniques」[5]。近年來記憶 體取得的代價越來越低，因此乾脆把所有的資料存放在記憶體上，不用再到磁碟 搜尋資料，In-Memory Database 油然而生[10]。因為將所有的資料載入到記憶體上，
資料查詢速度快為其主要優點，但現今的資料量動輒好幾 TB，遇到如此龐大的資 料量時，In-Memory Database 並不適用。另一種與資源問題，是發生死結(deadlock) 兩程序互搶佔資源的情形，不過現在的資料庫系統針對死結的情形都有其解決的