Statspack使用存在的幾個誤區(qū)
2024-07-21 02:38:29
供稿：網(wǎng)友
Statspack 是 Oracle 提供的一個實例級的Tuning工具。很多DBA都喜歡用這個工具來進(jìn)行數(shù)據(jù)庫的優(yōu)化調(diào)整。不過在交流中發(fā)現(xiàn)很多朋友對這個工具的的運用還有一些 問題。下面就其中比較輕易出問題的幾個方面進(jìn)行一下簡單的分析。 快照的采樣時間間隔問題
我們知道，Statspack的report實際上也就是對比兩個快照 (Snapshot，也就是數(shù)據(jù)庫當(dāng)前狀態(tài) ) 得出的結(jié)果。 一般情況下，專家建議生成Statspack報告的快照時間間隔為15-30分鐘。 試想，一個人去醫(yī)院看病，醫(yī)生對其測量體溫，一般也就是5-10分鐘左右就可以了， 為什么是這麼長的時間？因為5-10分鐘這段時間基本可以近似的得到你的體溫。假如時間過短，可能達(dá)不到既定的目的，測到的體溫會偏低，時間過長，甚至長達(dá)幾 個小時的話(假設(shè)有這種情況)，病人可能都昏迷幾次了 ;) 。 對生成Statspack報告的快照時間間隔也是這樣，假如兩個Snap Time時間過短，數(shù)據(jù) 庫的一些主要周期性事務(wù)可能還沒有運行，信息收集不完全。假如間隔過長，數(shù)據(jù)一樣會有偏差。 假設(shè)如下的情況：系統(tǒng)一直正常，但是最近幾天有用戶反映，在A時間段應(yīng)用程序執(zhí)行 很慢。B時間段正常，而 A時間段有一個主要的事務(wù)X運行（也是用戶使用到的事務(wù)）。 B時間段有另外一個比較消耗資源的事務(wù)Y在運行。A和B時間段的跨度比較大。本來你的 快照假如覆蓋A時間段內(nèi)就已經(jīng)能夠的收集到比較準(zhǔn)確的數(shù)據(jù)了，但不巧的是，你的Report 所用的兩個Snap ID的時間跨度太長，從而把B時間段內(nèi)的統(tǒng)計數(shù)據(jù)也收集了進(jìn)來。 Statspack 經(jīng)過比較，“認(rèn)為”事務(wù)Y是對系統(tǒng)有主要影響(這也會在Report上體現(xiàn)出來)，而你，經(jīng)過分析，認(rèn)為Y才是罪魁禍?zhǔn)?，接下來，你不遺余力的對Y進(jìn)行了tuning...... 問題出現(xiàn)了！調(diào)整了B之后，用戶繼續(xù)報告，A時間段內(nèi)系統(tǒng)不但沒有變快，反而變得更慢，甚至不可忍受。這種情況是很危險 的，可能會對系統(tǒng)造成不同程序的損害。在比較嚴(yán)格的環(huán)境中，這已經(jīng)構(gòu)成了一次比較嚴(yán)重的事故。 或許你也要承認(rèn)，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)。這么長的時間跨度，即使數(shù)據(jù)庫在一定時間間隔內(nèi)有問題，在這里的體現(xiàn)也會有偏差。
下面的這個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分鐘? 這么長時間內(nèi)的數(shù)據(jù)采集分析，怕是絕大部分內(nèi)容都是不能相信的了。 還要注重的是，我們說的時間間隔，是Begin Snap和End Snap之間的間隔，而不是相鄰兩個Snap 之間的間隔。對于Snap收集的間隔，建議以不要影響性能為準(zhǔn)，收集的太過于頻繁，會對性能和 存儲都造成壓力。對于所謂的15-30分鐘，不能墨守成規(guī)。具體的環(huán)境下應(yīng)該加以調(diào)整。 以偏概全
Statspack從本質(zhì)上說，是對系統(tǒng)的性能統(tǒng)計數(shù)據(jù)進(jìn)行采樣，然后進(jìn)行分析，采樣，就會有偏差。如何消除偏差？統(tǒng)計學(xué)指出差值隨樣品個數(shù)的增加而降低。所以，只憑借一個Report文檔就斷定數(shù)據(jù)庫的性能問題出在某處，是比較武斷的做法（個別情況除外）。需要DBA創(chuàng)建多個Report，包括不同時間段，對比進(jìn)行分析，這樣才會起到很好的效果。在尋求技術(shù)支持的時候也最好能夠多提交幾份Report，便于支持人員迅速幫助解決問題。 有關(guān)Timed_statistics參數(shù)
雖然這算是一個低級的錯誤，還是很遺憾，經(jīng)?？吹揭恍┡笥褜@個參數(shù)的忽略．假如在 Timed_statistics的值設(shè)置為False的時候進(jìn)行收集，可以說，收集到的東西用處不是很大 (我想你不會只想看一些實例名字、初始化參數(shù)之類的信息吧)。甚至可以說，假如該參數(shù)不設(shè)置為True，性能分析無從說起。 你成了泄密者?
Statspack 報告會匯集到你的數(shù)據(jù)庫系統(tǒng)比較全面的信息，假如不對報告加以"偽裝"就隨意發(fā)布到一些技術(shù)論壇上尋求支持，無疑給一些黑客以可乘之機(jī)。你的數(shù)據(jù)庫名字、實例名字、主機(jī)名、數(shù)據(jù)庫版本號、兼容參數(shù)、要害的表名字、文件路徑等等，尤其是要害的SQL都是黑客們或是惡意入侵者的最好的參考信息。
商業(yè)競爭對手也可能正在對你的數(shù)據(jù)庫虎視眈眈。假如你有意積極配合這些惡意窺探者，那么就把你的Statspack公之于眾吧
