關于快照的采樣時間間隔問題:

我們知道，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 LengthStart 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，性能分析無從說起。