系統瓶頸分析
一、系統瓶頸分析示例
例1：
交易的響應時間如果很長，遠遠超過系統性能需求，表示消耗CPU的數據庫操作，例如排序、執行aggregate functions（例如sam、min、max、count）等較多，可以考慮是否有索引以及索引建立的是否合理；盡量使用簡單的表聯接；水平分割大表格等方法來降低該值。
例2：
分段排除錯誤。測試工具可以模擬不同的虛擬用戶來單獨訪問web服務器、應用服務器和數據庫服務器，這樣就可以在web端測出的響應時間減去以上各個分段測出的時間就可以知道瓶頸在哪並着手調優。
例3：
unix資源監控（NT操作系統同理）中指標內存頁交換速率（Paging rate），如果該值偶爾走高，表明當時有線程競爭內存。如果持續走高，則內存可能是瓶頸。也可能是內存訪問命中率低。“swap in rate”和“swap out rate”也有類似的解釋。
例4：
unix資源監控（NT操作系統同理）中指標CPU占用率（cpu utilization），如果該值持續超過95%，表明cpu是瓶頸，可以考慮增加一個處理器或換一個更快的處理器。合理使用范圍在60%至70%。
例5：
unix資源監控（NT操作系統同理）中指標磁盤交換率（Disk rate），若果該值參數值一直很高，表明I/O有問題。可考慮更換更快的硬盤系統、重新部署業務邏輯等，另外設置Tempdb in RAM，減低“max async IO”，“max lazy writer IO”等措施都會降低該值。
例6：
tuxedo資源監控中指標列隊中的字節數（Bytes on queue），隊列長度應不超過磁盤數的1.5~2倍。要提高性能，可增加磁盤。注意：一個raid disk實際有多個磁盤。
例7：
sqlserver資源監控中指標緩存點擊率（cache hit ratio），該值越高越好。如果持續低於80%，應考慮增加內存。注意該參數值是從sql server啟動后，就一直累加記數，所以運行一段時間后，該值不能反映系統當前值。
二、系統優化調整設置
1、CPU問題：
考慮使用更高級的CPU代替當前的CPU。
對於多CPU,考慮CPU之間的負載分配。
考慮在其他體系上設計系統，例如增加前置機，設置並行服務器等。
2、內存和高速緩存：
內存的優化包括操作系統、數據庫、應用程序的內存優化。
過多的分頁與交換可能降低系統的性能。
內存分配也是影響系統性能的主要原因。
保證保留列表具有較大的鄰接內存塊。
調整數據塊緩沖區大小（用數據塊的個數表示）是一個重要內容。
將最頻繁使用的數據保存在存儲區中。
3、磁盤（I/O）資源問題
磁盤讀寫進度對數據庫系統是至關重要的，數據庫對象在物理設備上的合理分布能改善性能。
磁盤鏡像會減慢磁盤寫的速度。
通過把日志和數據庫對象分布在獨立的設備上可以提高系統的性能。
把不同的數據庫放在不同的硬盤上，可以提高讀寫速度。經常把數據庫、回滾段、日志放在不同的設備上。
把表放在一塊硬盤上，把飛簇的索引放在另一塊硬盤上，保證物理讀寫更快。
4、調整配置參數
包括操作系統和數據庫的參數配置。
並行操作資源限制的參數（並發用戶的數目、會話數）。
影響資源開銷的參數。
與I/O有關的參數。
5、優化應用系統網絡設置
可以通過數組接口來減少網絡呼叫。不是一次提取一行，而是在單個往來往返中提取10行，這樣做效率較高。
調整會話數據單元的緩沖區大小。
共享服務器進程比專用服務進程提供較好的性能。
三、數據庫服務器性能問題及原因分析
1、單一類型事務響應時間過長
數據庫服務器負載、糟糕的數據設計、事務粒度過大、批任務對普通用戶性能的影響。
2、並發處理能力差
3、鎖沖突嚴重
資源鎖定造成的數據庫事務超時、數據庫死鎖。
四、數據庫相關
1、數據庫性能問題的一般解決辦法
監視性能相關數據。
定位資源占用較大的事務並做出必要的優化或調整。
定位鎖沖突，修改鎖沖突發生嚴重的應用邏輯。
對規模較大的數據或者無法通過一般優化解決的鎖沖突進行分布。
2、oracle與提高性能有關的特性
索引、並行執行、簇與散列簇、分區、多線程服務器、同時讀取多塊數據。
3、oracle配置的關鍵參數
MAX_DSPATCHERS：這個參數指定了系統允許同時進行的調度進程的最大數量。
MAX_SHARED_SERVERS：這個參數指定了系統允許同時進行的共享服務器進程的最大數量。如果系統中出現的人為死鎖過於頻繁，那么管理員應該增大這個參數的值。
PARALLEL_ADAPTIVE_MULTI_USER：當這個參數的值為TRUE時，系統將啟動一個能提高使用並行執行的多用戶系統性能的自適應算法。這個算法將根據查詢開始時的系統負載自動降低查詢請求的並行度。
PARLLEL_MIN_SERVERS：這個參數指定了實例並行執行進程的最小數量。其值就是實例啟動時Oracle創建的並行執行進行數。
PARLLEL_THREADS_PER_CPU：這個參數指定了實例默認的並行度和並行自適應以及負載平很算法。它指明了並行執行過程中一個CPU能處理的進程或線程數。
PARTITION_VIEW_ENABLED：這個參數指定了優化器是否使用分區視圖。oracle推薦用戶使用分區表（這個在oracle8之后引入的）而不是分區視圖。分區視圖只是為了提供oracle的后向兼容性。
REVOVERY_PARALLELISM：這個參數指定了恢復數據庫系統時使用的進程數。
4、oracle的並行執行特性
RDBMS的絕大多數操作都可以分為以下3類：
被CPU限制的操作：這類操作的速度和單CPU運行的速度一樣。通過並行化操作，多個CPU可並行處理系統負載，因為可以更快完成該操作。
被I/O限制的操作：這類操作花了絕大部分時間等待系統完成I/O操作。當系統中同時出現多個I/O請求時，絕大多數RAID控制器將很好工作。另外，當一個線程需要等待完成I/O操作時，可充分利用CPU來處理另一個線程的CPU部分。
被競爭限制的操作：並行處理不能改善由資源競爭所限制的操作。
5、應當首先根據如下一些因素考慮並行度：
計算機的CPU能力：CPU的數量和能力將影響系統能運行的查詢進程數量。
系統處理大量進程的能力：一些操作系統能處理很多並發線程，而另一些操作系統則沒有這方面的能力。
系統負載：如果系統現在的運行已經達到了極限，那么對並行度的調整不會有太大的效果。如果系統運行已達其能力極限的90%，那么大多的查詢進程將使系統不堪重負。
系統處理的查詢數量：如果系統的大部分操作是更新操作，但仍有少量的重要查詢存在，那么開發人員可能希望系統運行多個查詢進程。
系統的I/O能力：如果磁盤上的數據是分片或是使用磁盤陣列存儲的，那么系統能夠處理多個並行查詢。
操作類型：系統是否需要處理很多的全表掃描或排序：並行查詢服務器非常有助於這類操作。
6、關於並行度的一些建議：
諸如排序之類的需要大量CPU資源的操作應當使用較低的並行度。其原因是這類受限於CPU的操作已經充分利用的CPU，而不需要等待系統的I/O操作。
諸如全表掃描之類的需要大量磁盤I/O的操作應當采用較高的並行度。需要等待磁盤I/O的操作越多，系統就越能受益於並行操作。
如果系統中有大量的並發進程，那么應當采用較低的並行度。因為太多的進程將使系統不堪重負。
7、Oracle同時讀取多塊數據
當系統執行表掃描時，oracle具備同時讀取多個數據塊的能力，這種能力提高了系統的I/O速度。通過同時讀取多塊數據，oracle能夠從磁盤上讀取更大的數據塊，從而避免了對磁盤上數據進行搜索的操作。通過降低磁盤搜索和讀取更大的數據塊，可以降低系統的I/O開銷和CPU開銷。
8、oracle 的分區
分區方案：
Range Partitioning：這種方案根據數據的范圍，比如月、年等對表中的數據進行分區。
List Partitioning：這種方案和Range Partitioning分區方案很類似，但這種方案是按照數據的值而不是數據的范圍來進行分區划分的。
Hash Partitioning：這種分區方案使用散列函數來實現對數據的自動分區。
Sub-Partitioning：這種方法就是開發人員熟悉的復合分區方法。這種方法允許開發人員同時使用多種分區方案。
分區有以下幾方面的好處：
對能被分區的大尺寸表進行掃描時，分區可降低I/O操作和CPU的使用率。
可在分區的層次上而不是表的層次上加載數據。
能以刪除分區的方式刪除數據，而不必使用select語句來刪除大量數據。
對用戶和應用程序而言，分區是完全透明的。
可在分區層次上而不是在表層次上維護數據。
9、oracle的多線程服務器
用戶可以通過專用服務器進程連接到oracle實例，也可以通過多線程服務器進程連接到oracle實例。因為每一個專用的服務器進程都將占用大量的內存資源和系統資源，所以有必要對多用戶連接采用多線程服務器進程。
多線程服務器進程允許多個用戶使用一定數量的共享服務器進程。共享服務器進程使用共享緩沖池對用戶請求進行排隊並返回數據，從而大大減少CPU和內存的使用。
10、oracle故障診斷
數據庫故障診斷通過獲得系統sql語句執行性能數據，例如每一條sql語句在oracle數據庫中執行的平均時間，來識別問題發生位置。
為了分析故障位置，將故障診斷數據（oracle Diagnostics）與交易執行響應時間（Transaction Response Time）數據關聯起來。例如：某交易“enter”的平均響應時間高，使用故障診斷（Oracle diagnostics），就可以查找到是什么原因導致了這個問題。