使用腳本和查詢來主動監視Oracle 9i的性能

超過250個配置參數、上千個測量值要監視，這些都讓Oracle的管理員監視其Oracle數據庫整體健康的工作不是一項輕松的任務。Oracle提供了各種工具來監視性能，但是這還是太多。要想有效地監視你Oracle數據庫的健康，你就需要熟悉下面的腳本和查詢：

• 數據緩沖區命中率警報會報告數據緩沖區命中率低于預設闕值的次數。
• 重做日志空間請求警報會在請求的數量大于0的時候提示出錯。如果這種情況發生了，你可能需要增加log_buffer參數的值。
• 共享池爭用警報會提示你出現了共享池爭用以及和鎖定相關的問題。
• 系統等待警報查詢會詢問Oracle的事件結構，以確定由于爭用而出現過多等待的事件。
• 庫緩沖失敗警報查詢會查找庫緩沖失敗率。如果庫緩沖失敗率超過.02，你就需要增加shared_pool_size的值來補救。
• 數據庫編寫器爭用警報會查找不良查詢總長的值、寫入請求和數據庫編寫器工具（DBWR）的檢查點。當寫入請求的長度大于3或者大于DBWR 檢查點的等待次數，你就需要調整數據庫編寫器的進程。
• 數據字典失敗率警報會提示你對數據字典元數據請求過高的次數。有時你可以通過增加shared_pool_sizeinit.ora這個參數的值來緩解這個問題。
• 數據字典對象警告報告會揭示對Oracle數據字典的內部爭用和字典元數據請求過高的次數。

仔細研究一下

現在讓我們更加仔細地看一下這些腳本是如何工作的。STATSPACK這個工具按時間來處理Oracle的調配信息，并把這些信息記錄在多個表格里。這些表格的名稱會反映出Oracle內部查看表v$，這些名字諸如stats$sysstat和stats$sql_summary。知道了這一點，你就可以編寫一些簡單的Oracle查詢，它們會顯示性能的走勢信息。然后你就可以處理這些性能信息，并把它們送到預示模型，例如線性回歸，這會準確地告訴你更改你系統全局區域（System Global Area，SGA）內部結構的正確次數。

Listing A包含有使用這些性能信息的例子。這個腳本會生成一個在一段時間內庫緩沖區失敗率的連續總計，還會引用stats$librarycache表格。

這個腳本的輸出會指出，你需要在這一期間內通過cron job或者dbms_job為shared_pool_size計劃安排額外的內存，見圖A。

圖A

庫緩沖失敗率腳本的輸出

動態性能重新配置

Table A高屋建瓴地查看一些主要的事件，這些事件能夠引發動態的調配重新配置。為了說明這一點，我只會把重點放在表格里所出現的SGA的主要區域里。

表A

內存區域	太小的情況	太大的情況
共享池	庫緩沖區失敗	無失敗現象
數據緩沖區	命中率< 90%	命中率> 95%
PGA集合	多次通過執行的次數過高	100%最佳執行

主要的重新配置觸發器

很顯然，庫緩沖失敗率過高表示共享池太小，Oracle七個數據緩沖池中任何一個的數據緩沖命中率低于90%都表示，你應該從數據庫的其他區域里分一部分內存出來，重新分配給數據緩沖區。對于排序這樣的操作，你要看一下程序全局區域（Program Global Area，PGA）里最佳執行的百分率，并在碰到排序操作的最佳執行率低于95%的時侯增加PGA集合目標參數的值。

針對數據緩沖區和共享池大小的規則是直接了當的，而新的pga_aggregate_target參數能夠確保（對這些信息）更進一步的研究。作為一個通用的規則，當下列情況發生的時候，你就要更改pga_aggregate_target的值：

• 當v$sysstat的值――用于一次通過的估計PGA靜態內存（estimated PGA memory for one-pass）超過pga_aggregate_target時，你就要增加pga_aggregate_target的值。
• 當v$sysstat的值――用于靜態工作區執行-多次通過（workarea executions—multipass）大于1%時，數據庫就能夠從額外的內存獲益。

你可能會為PGA分配過多的內存，這樣在v$sysstat數據列的值――工作區執行-最佳（workarea executions—optimal）達到100%的時候，可能就要考慮減少pga_aggregate_target的值。

正如你能夠看到的那樣，對Oracle數據庫的主動監視會是相當復雜的。由于有上百個測量值和參數需要監視和重新設置，所以對Oracle的調整將會是非常具有挑戰性的。但是有了Oracle的性能測試工具和主要幾個重新配置激發器的知識，你就可以開始調整好所有的事了。

　　

原文轉自：http://www.kjueaiud.com