Statspack使用中存在的幾個誤區
2024-07-21 02:38:09
供稿：網友
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公之于眾吧 :-)
