原文：http://jonathanlewis.wordpress.com/2006/12/27/analysing-statspack-8/

作者：Jonathan Lewis

?

在前面的關于statspack的文章中，我引用了Don Burleson發表的文章中的一些數字。

這是oracle 10g的數據庫設置了過小的log buffer的例子，大小為512K.

Top 5 Timed Events ~~~~~~~~~~~~~~~~~~ % Total Event Waits Time (s) DB Time Wait Class log file parallel write 9,670 291 55.67 System I/O log file sync 9,293 278 53.12 Commit CPU time 225 43.12 db file parallel write 4,922 201 38.53 System I/O control file parallel write 1,282 65 12.42 System I/O

在Burleson的站點上，我發現了這個片段的出處。

　　報告是一個word文檔，在這個鏈接this URL處，是在Burleson Consulting Oracle Forum的一個回帖中被引用，在繼續寫這篇博客之前，應該好好看看這個帖子，其中討論了許多報告中的統計信息，和一些前瞻性的建議。為了達到互相借鑒的目的，你可以在閱讀本篇博客的時候再開一關于這個報告的窗口。

　　更新14th Nov 2007：盡管論壇的帖子還在，但文檔已經從站點移除了，帖子的最新版本現在生成了一個7頁得pdf文檔，早些的版本還能在google的緩存中發現。

　　首先，這是一個有4GB內存和raid-5磁盤配置的linux系統，這是一個專用的服務器，沒有其它的任務在處理，在閱讀statspack報告時，不要忽略這些信息，這些信息通常可以告訴你那些統計是合理的，哪些不合理。

　　報告同時顯示，機器有兩顆cpu，快照的間隔時間是一個小時。在看load profiles和waits之前，先看一下buffer cache（124M）, shared pool(136M)的大小，現在系統還留下大約3.7GB大小的內存未使用，快速的check一下參數列表，?pga_aggregate_target參數顯示，傳言oracle對于進程的內存使用有一個92MB的限制，另外在看sga_target設置是280MB大小，所以看到數據庫僅僅300MB大小。

　　所以，擁有4GB大小的內存，但卻使用300M大小的數據庫，況且系統再沒有其它任務在運行，為什么不把buffer cache設置的更大一些，讓整個數據庫的操作都在內存中完成呢！（這是在閱讀awr report時我記錄下的一個問題，后面可以繼續跟蹤一下，雖然它不能解決性能問題，但這個一個在設置參數的策略問題）.

　　下面來看一個load profile：每秒7KB大小的redo日志，每秒464個邏輯I/O，52個塊更改，1個物理讀，2個物理寫，2.66個事務。平均下來數據庫是很空閑的。再看一下top 5的等待時間，（兩顆cpu，意味著7,200s的cpu時間，但僅僅有226s在使用），所以平均下來數據庫依然沒有什么壓力。

　　但是這個是statspack的一個缺點，平均值會丟失一些重要的信息，或許這個系統的問題就是有大量的活動觸發而造成在短時間內數據庫很慢。而報告，作為一個健康性檢查，通常情況下就是粗略的review。所以，如果沒有特別具體的問題去跟蹤，那么就找下效率不高的地方。

　　看一下load profile和wait events，好像沒有什么好說的，我們已經得到一個事實，系統沒有太多的任務處理，平均的I/O比較慢（可能跟raid-5的配置有關）。

　　查看第六頁（service statistisc），我們發現DBA已經啟動系統來來使用數據庫的服務，大部分的任務都是通過服務來完成。

　　再回到系統的統計上，唯一例外的數據就是“index fast full scan（fast）”，如果這是一個OLTP系統的話，那么這是一個資源密集型的執行計劃路徑，一個小時內有2,941次。

　　再看一下解析的數量，一個小時72,000次，平均下來20次/s，這并不是大的災難，但或許可以避免，所以看一下統計信息“session cursor cache hits”, 數組是0；然后再看一下參數session_cached_cursors設置成了0，這可能是一個錯誤，最好是設置是像50這樣的數字，這會使用一點內存（實質上我們有很多），來消除花費在parse call上的cpu時間。

　　快速的看下redo的指標：redo大小加上redo的浪費的大約31M, redo的block寫大約是63,698，所以redo block的大小是512bytes，“redo synch writes”是9,280，與“redo writes” 9,678非常相近，（與后面的“user commits“ 的數量非常相近，平均每次7個block的大小，非常的類似于有很多小事務的OLTP系統）。

　　到table scan的部分，會發現有些震驚的數據，通過rowid獲取了138,713行數據，75million fetched 通過table scan（大約是1.17Million的塊掃描）。大部分的tablescans是小表的掃描，所以基本上是緩存的。少量的大表table scans（忽略特殊的情況，小表占了2%的buffer cache，即26MB的空間，大約3,300個塊）。

　　如果在這片報告中（除了慢的磁盤）還有一些東西需要client知道的話，那就是開發應用程序人員需要review一些他們的數據和代碼，看下是否有合適的索引來滿足需求。如果有合適的索引，需要檢查一下統計信息，看下為什么oracle沒有使用索引。

　　在第十一頁的Instance Activity Stats上，log files的大小是10M,對于大多數系統來說還是設置的略顯小了，但在一個小的系統上，每小時3次的log switch看起來也是合適的，或許我們要想客戶提一下參數archive_lag_target，并解釋下如何設置這個參數來保證在每N s的時候保證一次log switch。

　　在第十四頁的Buffer Pool Advisory顯示了一個有趣的模型，當把buffer cache從60M調整到72M的時候，物理讀會顯著的下降。如果你贊同這樣的建議，你肯定系統調整下cache的大小。

　　PGA Aggr Histogram的意義通常都沒那么大，在這個例子中更是特別小。這個指標可能給我們一個警示，對于真正的OLTP系統sort/hash操作會有點太多，這里pga_aggregate_target僅僅96M，對于processes設置成150而言，或許有點小了，對于OLTP系統來說，每個process合適的大小是2M-4M大小。這個建議分配更多一點內存給pga和sga。

　　Latch的活動指標或許沒有什么興趣，值得一看的是“row cache objects“相對比”library cache latch“要大。這可能是過度的優化的指示(a.k.a.?“hard”?parsing)，但是因為沒有太多的hard parse，并且高的指標主要來自dc_global_oids,?dc_object_ids, and?dc_users?caches。這可能在object table類型上使用cast()函數而帶來的負影響，對于高性能，高并發的系統而言，這不是oracle里親和的技術。

　　Library Cache Activity顯示了一些reloads操作，可能意味著要增加shared pool的大小，也有可能是使用了字面量，但是在當前的系統負載壓力下，這不會是一個大問題，cursor_sharing參數設置為force，所以要堅持一下代碼中時候摻雜了綁定變量和字面量。這是一個該指令不適用于在更高版本的Oracle的代碼風格。
?? 再看下其它參數，我們可能想處理db_file_mulitblock_read_count這個參數，并且保證每一個進程db_cache_size大小都至少1M.

?

總結：

如果你想對數據庫進行快速的檢查：

磁盤寫的速度比較慢-可能是因為RAID-5.

因為index的錯誤，不合適的統計信息，或者代碼的問題，導致一些查詢非常低效。你可以使用機器的內存，把更多的數據放進sga和pga中，目前這種方式因為大量的資源浪費在tablescan上，而不會有很大的改觀。

參數session_cached_cursor?設置成非零的值，可能節省一點cpu。

保證代碼的風格是正確的，而不再使用cursor_sharing = force。

在使用包括類似于cast函數這樣的sql時要特別小心。

這個是花費了90分鐘的review（包括了打字時間），所以如果你任務還有一些東西值得提起，或者是文章的一些東西不相關，下面可以進行自由評論。

轉載于:https://www.cnblogs.com/xpchild/p/3694949.html

總結

以上是生活随笔為你收集整理的statspack系列8的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。