偶然間發現,幾年前，馮老師關于statspack的一篇文章，寫的不錯，收下了先。

http://www.dbanotes.net/Oracle/AboutStatspack.htm

Statspack 是 Oracle 提供的一個實例級的Tuning工具。很多DBA都喜歡用這個工具來進行數據庫的優化調整。不過在交流中發現很多朋友對這個工具的的運用還有一些 問題。下面就其中比較容易出問題的幾個方面進行一下簡單的分析。

快照的采樣時間間隔問題

我們知道，Statspack的report實際上也就是對比兩個快照 (Snapshot，也就是數據庫當前狀態 ) 得出的結果。

一般情況下，專家建議生成Statspack報告的快照時間間隔為15-30分鐘。

試想，一個人去醫院看病，醫生對其測量體溫，一般也就是5-10分鐘左右就可以了， 為什么是這麼長的時間？因為5-10分鐘這段時間基本可以近似的得到你的體溫。如果時間過短，可能達不到既定的目的，測到的體溫會偏低，時間過長，甚至長達幾 個小時的話(假設有這種情況)，病人可能都昏迷幾次了 ;) 。

對生成Statspack報告的快照時間間隔也是這樣，如果兩個Snap Time時間過短，數據 庫的一些主要周期性事務可能還沒有運行，信息收集不完全。如果間隔過長，數據一樣會有偏差。

假設如下的情況：系統一直正常，但是最近幾天有用戶反映，在A時間段應用程序執行 很慢。B時間段正常，而 A時間段有一個主要的事務X運行（也是用戶使用到的事務）。 B時間段有另外一個比較消耗資源的事務Y在運行。A和B時間段的跨度比較大。本來你的 快照如果覆蓋A時間段內就已經能夠的收集到比較準確的數據了，但不巧的是，你的Report 所用的兩個Snap ID的時間跨度太長，從而把B時間段內的統計數據也收集了進來。 Statspack 經過比較，“認為”事務Y是對系統有主要影響(這也會在Report上體現出來)，而你，經過分析，認為Y才是罪魁禍首，接下來，你不遺余力的對Y進行了tuning......

問題出現了！調整了B之后，用戶繼續報告，A時間段內系統不但沒有變快，反而變得更慢，甚至不可忍受。這種情況是很危險 的，可能會對系統造成不同程序的損害。在比較嚴格的環境中，這已經構成了一次比較嚴重的事故。

或許你也要承認，Statspack的快照的采樣時間間隔還真需要重視呢......

這是一個Oracle　8.1.7.0.1　版本下的Statspack報告：

                      Snap Id          Snap Time Sessions
------- ------------------ --------
Begin Snap:            637 04-Aug-03 11:59:33       25
End Snap:              646 04-Aug-03 16:29:06       25
Elapsed:                        269.55 (mins)

從中可以看到快照637和快照646之間為269.55 (mins)。這么長的時間跨度，即使數據庫在一定時間間隔內有問題，在這里的體現也會有偏差。
下面的這個Statspack 報告的時間有點不靠譜了：

	                                                                Snap Length
Start Id  End Id              Start Time  End Time                (Minutes)
--------  --------  --------------------  --------------------  -----------
314  1053        11-Dec-03 18:07:13  19-Dec-03 10:53:02      11,085.82

11,085.82分鐘? 這么長時間內的數據采集分析，怕是絕大部分內容都是不能相信的了。

還要注意的是，我們說的時間間隔，是Begin Snap和End Snap之間的間隔，而不是相鄰兩個Snap 之間的間隔。對于Snap收集的間隔，建議以不要影響性能為準，收集的太過于頻繁，會對性能和 存儲都造成壓力。對于所謂的15-30分鐘，不能墨守成規。具體的環境下應該加以調整。

以偏概全

Statspack從本質上說，是對系統的性能統計數據進行采樣，然后進行分析，采樣，就會有偏差。如何消除偏差？統計學指出差值隨樣品個數的增加而降低。所以，只憑借一個Report文檔就斷定數據庫的性能問題出在某處，是比較武斷的做法（個別情況除外）。需要DBA創建多個Report，包括不同時間段，對比進行分析，這樣才會起到很好的效果。在尋求技術支持的時候也最好能夠多提交幾份Report，便于支持人員迅速幫助解決問題。

有關Timed_statistics參數

雖然這算是一個低級的錯誤，還是很遺憾，常常看到一些朋友對這個參數的忽略．如果在 Timed_statistics的值設置為False的時候進行收集，可以說，收集到的東西用處不是很大 (我想你不會只想看一些實例名字、初始化參數之類的信息吧)。甚至可以說，如果該參數不設置為True，性能分析無從說起。

你成了泄密者?

Statspack 報告會匯集到你的數據庫系統比較全面的信息，如果不對報告加以"偽裝"就隨意發布到一些技術論壇上尋求支持，無疑給一些黑客以可乘之機。你的數據庫名字、實例名字、主機名、數據庫版本號、兼容參數、關鍵的表名字、文件路徑等等，尤其是關鍵的SQL都是黑客們或是惡意入侵者的最好的參考信息。

商業競爭對手也可能正在對你的數據庫虎視眈眈。

如果你有意積極配合這些惡意窺探者，那么就把你的Statspack公之于眾吧 :-)