偶然間發(fā)現(xiàn),幾年前，馮老師關(guān)于statspack的一篇文章，寫的不錯(cuò)，收下了先。

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

Statspack 是 Oracle 提供的一個(gè)實(shí)例級(jí)的Tuning工具。很多DBA都喜歡用這個(gè)工具來進(jìn)行數(shù)據(jù)庫(kù)的優(yōu)化調(diào)整。不過在交流中發(fā)現(xiàn)很多朋友對(duì)這個(gè)工具的的運(yùn)用還有一些 問題。下面就其中比較容易出問題的幾個(gè)方面進(jìn)行一下簡(jiǎn)單的分析。

快照的采樣時(shí)間間隔問題

我們知道，Statspack的report實(shí)際上也就是對(duì)比兩個(gè)快照 (Snapshot，也就是數(shù)據(jù)庫(kù)當(dāng)前狀態(tài) ) 得出的結(jié)果。

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

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

對(duì)生成Statspack報(bào)告的快照時(shí)間間隔也是這樣，如果兩個(gè)Snap Time時(shí)間過短，數(shù)據(jù) 庫(kù)的一些主要周期性事務(wù)可能還沒有運(yùn)行，信息收集不完全。如果間隔過長(zhǎng)，數(shù)據(jù)一樣會(huì)有偏差。

假設(shè)如下的情況：系統(tǒng)一直正常，但是最近幾天有用戶反映，在A時(shí)間段應(yīng)用程序執(zhí)行 很慢。B時(shí)間段正常，而 A時(shí)間段有一個(gè)主要的事務(wù)X運(yùn)行（也是用戶使用到的事務(wù)）。 B時(shí)間段有另外一個(gè)比較消耗資源的事務(wù)Y在運(yùn)行。A和B時(shí)間段的跨度比較大。本來你的 快照如果覆蓋A時(shí)間段內(nèi)就已經(jīng)能夠的收集到比較準(zhǔn)確的數(shù)據(jù)了，但不巧的是，你的Report 所用的兩個(gè)Snap ID的時(shí)間跨度太長(zhǎng)，從而把B時(shí)間段內(nèi)的統(tǒng)計(jì)數(shù)據(jù)也收集了進(jìn)來。 Statspack 經(jīng)過比較，“認(rèn)為”事務(wù)Y是對(duì)系統(tǒng)有主要影響(這也會(huì)在Report上體現(xiàn)出來)，而你，經(jīng)過分析，認(rèn)為Y才是罪魁禍?zhǔn)祝酉聛恚悴贿z余力的對(duì)Y進(jìn)行了tuning......

問題出現(xiàn)了！調(diào)整了B之后，用戶繼續(xù)報(bào)告，A時(shí)間段內(nèi)系統(tǒng)不但沒有變快，反而變得更慢，甚至不可忍受。這種情況是很危險(xiǎn) 的，可能會(huì)對(duì)系統(tǒng)造成不同程序的損害。在比較嚴(yán)格的環(huán)境中，這已經(jīng)構(gòu)成了一次比較嚴(yán)重的事故。

或許你也要承認(rèn)，Statspack的快照的采樣時(shí)間間隔還真需要重視呢......

這是一個(gè)Oracle　8.1.7.0.1　版本下的Statspack報(bào)告：

                      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)。這么長(zhǎng)的時(shí)間跨度，即使數(shù)據(jù)庫(kù)在一定時(shí)間間隔內(nèi)有問題，在這里的體現(xiàn)也會(huì)有偏差。
下面的這個(gè)Statspack 報(bào)告的時(shí)間有點(diǎn)不靠譜了：

	                                                                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分鐘? 這么長(zhǎng)時(shí)間內(nèi)的數(shù)據(jù)采集分析，怕是絕大部分內(nèi)容都是不能相信的了。

還要注意的是，我們說的時(shí)間間隔，是Begin Snap和End Snap之間的間隔，而不是相鄰兩個(gè)Snap 之間的間隔。對(duì)于Snap收集的間隔，建議以不要影響性能為準(zhǔn)，收集的太過于頻繁，會(huì)對(duì)性能和 存儲(chǔ)都造成壓力。對(duì)于所謂的15-30分鐘，不能墨守成規(guī)。具體的環(huán)境下應(yīng)該加以調(diào)整。

以偏概全

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

有關(guān)Timed_statistics參數(shù)

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

你成了泄密者?

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

商業(yè)競(jìng)爭(zhēng)對(duì)手也可能正在對(duì)你的數(shù)據(jù)庫(kù)虎視眈眈。

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