嘗試編譯「統計Hoggers」報告。所有那些佔用CPU運行統計數據的用戶
關於什麼「table.cols」(或col1,col2等),他們是否運行統計信息以及何時運行它們。Teradata - 報告頂級「stats hoggers」
我寫了下面的報告,但我可以在其遠離現實
- 看到它沒有「分」的通過權重表一定比例給定的查詢CPU。因此,如果在統計操作中 - 最昂貴的CPU在FACT.BILLION_DOLLAR表上,但也有一個DIMENSION.DWARF表,DIMENSION.DWARF將虛假地顯示在圖表上 - 這會使報告產生誤導。
我也試圖編譯另一份報告,我想通過表的TOP CPU。它不是「嚴格」的位置,因爲CPU是查詢不是對象,但在查詢內我想按比例「拆分」CPU(我猜count(*)將是1條件)。那麼我怎麼做到這一點 它「拉過了錯誤的人」 - 用於運行統計操作的用戶名顯示不正確。我們的運行統計信息的產品ID是SWPRDUSR,但最高統計信息用戶顯示爲系統範圍產品SYSPRDUSR。用戶,他真的不會惹我們的東西 - 所以我知道這裏有什麼不對勁。
這是我正在運行 我運行這個報告沒有系統寬,但只爲我的我的數據庫,級聯sel a.username, s.ObjectTableName, s.objectdatabasename, --s.ObjectColumnName, cast (s.CollectTimeStamp as date) , CAST(SUM((((a.AmpCPUTime(DEC(18,3)))+ ZEROIFNULL(a.ParserCPUTime)))) AS DECIMAL(18,3)) as Total_CPU from
DBC.DBQLogtbl a join DBC.DBQLoBJTBL s on ( s.ProcID = a.ProcID and cast (s.CollectTimeStamp as date) = cast (a.CollectTimeStamp as date)) where objectdatabasename in ( sel child
from dbc.children where parent ='FINDB'
group by 1) and ObjectType='tab' and statementType='collect statistics' group by 1,2,3,4 UNION ALL sel a.username, s.ObjectTableName, s.objectdatabasename, s.Logdate, --s.ObjectColumnName, CAST(SUM((((a.AmpCPUTime(DEC(18,3)))+ ZEROIFNULL(a.ParserCPUTime)))) AS DECIMAL(18,3)) as Total_CPU from
PDCRinfo.DBQLogtbl a join PDCRinfo.dbqlobjtbl_hst s on ( s.queryID = a.queryID and s.Logdate = a.Logdate)
where objectdatabasename in ( sel child
from dbc.children where parent ='FINDB'
group by 1) and ObjectType='tab' and statementType='collect statistics' group by 1,2,3,4 order by 5 desc , 3 asc, 2 asc, 1 asc ;
你說得對。 TY ...多麼糟糕的小姐。我需要新的眼鏡.....或任何背後的......或任何背後(在那些)後面...我看到PI作爲Logdate和ProcID在PI(不知道爲什麼QueryID不是那裏。如果queryID在那裏,它會有一個PI-PI連接,查詢ID給予更好的分配和連接的一部分),並抓住那些......假設除此之外沒有任何東西。 OBJECT,LOG和SQL所有3個表中都有QueryID。爲什麼不把它放在PI中。感謝您的信息Dieter – user1874594
@ user1874594:dbc中DBQL表的PI僅用於將緩存數據有效寫入單個數據塊。這就是爲什麼必須每天將數據移動到歷史記錄表的原因,否則QueryId上的所有聯接表現都非常糟糕。 – dnoeth
再次感謝Dieter。你搖滾! – user1874594