Попытка скомпилировать отчет статистики Hoggers. Все те пользователи, которые отталкивали статистику запущенных процессоров
На что «table.cols» (или col1, col2 и т. Д.), Они запускали статистику и когда запускали ее.Teradata - отчет за верхние "статистики хоггеров"
я написал ниже доклад, но я могу видеть его далеко от реального
- Это не «Split» процессор на данном запросе на некоторую долю веса в таблице. Так что, если в режиме статистики - самый дорогой процессор был в таблице FACT.BILLION_DOLLAR, но также была таблица DIMENSION.DWARF, DIMENSION.DWARF будет ложно отображаться на диаграмме, что делает сообщение вводящим в заблуждение.
Я также пытаюсь скомпилировать другой отчет, в котором я хочу получить ТОП-процессор от TABLE. Это не «строго», потому что процессор предназначен для запроса, а не для объекта, но внутри запроса я хочу «разделить» процессор пропорционально (я думаю, что count (*) будет 1 критерий). Итак, как это сделать? Это «натягивает неправильного парня» - неправильное имя пользователя для запуска статистики. Наш идентификатор производства, который запускает статистику, - 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 ;
Вы правы. ТЫ ... Какая неудачная мисс. Мне нужны новые очки ... или что-то еще за ними ... или что-то еще (за ними) ... Я видел PI как Logdate и ProcID на PI (не знаю, почему QueryID не был там . Если queryID существует, это будет PI-PI-соединение с идентификатором запроса, дающим лучшее распределение и часть соединения) .. и схватил их ... если предположить, что ничего не выходит за рамки этого. OBJECT, LOG и SQL все 3 таблицы имеют QueryID. Почему бы не сохранить его в ИП. Спасибо за информацию Dieter – user1874594
@ user1874594: PI таблиц DBQL в dbc предназначен только для эффективного кэширования данных в виде единого блока данных. Вот почему данные должны ежедневно перемещаться в таблицу истории, иначе все соединения в QueryId будут работать очень плохо. – dnoeth
Еще раз спасибо Дитер. Ты жжешь !!! – user1874594