Teradata - отчет для лучших сборщиков статистики

Пытаюсь составить отчет "Хоггеры статистики". Все те пользователи, которые загружали статистику загрузки процессора
На каком «table.cols» (или col1, col2 и т. д.) они запускали статистику и когда они ее запускали.

Я написал приведенный ниже отчет, но вижу, что он далек от реального

  • Он не «разделяет» ЦП по заданному запросу на некоторую долю весов в таблице. Таким образом, если в статистической операции самый дорогой ЦП был в таблице FACT.BILLION_DOLLAR, но была также таблица DIMENSION.DWARF, DIMENSION.DWARF ложно отобразится на диаграмме, что делает отчет недостоверным.
    Я также пытаюсь составить еще один отчет, в котором мне нужен ТОП ЦП по ТАБЛИЦЕ. Это не «строго» возможно, потому что ЦП предназначен для запроса, а не для объекта, но внутри запроса я хочу «разделить» ЦП пропорционально (я думаю, что количество (*) будет 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 ;


person user1874594    schedule 21.01.2016    source источник


Ответы (1)


В 1-м списке отсутствует условие соединения: s.queryID = a.queryID

Collect Stats всегда одна таблица, нет необходимости разделять ЦП.

person dnoeth    schedule 22.01.2016
comment
Ты прав. TY ... Какая плохая мисс. Мне нужна новая пара очков..... или что там за ними... или что там за ними (за ними)... Я видел PI как Logdate и ProcID на PI (не уверен, почему QueryID там не было , Если есть queryID, это будет объединение PI-PI с идентификатором запроса, обеспечивающим лучшее распределение и часть соединения) ... и захватить их ... при условии, что кроме них ничего нет. OBJECT , LOG и SQL все 3 таблицы имеют QueryID. Почему бы не сохранить его в PI . Спасибо за информацию Дитер - person user1874594; 22.01.2016
comment
@ user1874594: PI таблиц DBQL в dbc предназначен только для эффективной записи кэшированных данных в виде одного блока данных. Вот почему данные должны ежедневно перемещаться в таблицу истории, иначе все соединения по QueryId будут работать очень плохо. - person dnoeth; 22.01.2016
comment
Привет Дитер. Как следствие, если мне нужно знать таблицы с максимальным числом обращений к ЦП. Как мне их получить - есть несколько таблиц на запрос - person user1874594; 24.01.2016
comment
Невозможно разделить ЦП между таблицами. - person dnoeth; 24.01.2016
comment
Я думаю использовать такую ​​логику. Если в таблице статистики есть значение количества строк, которому меньше 5 дней... выберите значение или выполните подсчет (*) . Затем используйте формулу, которая использует ЦП для идентификатора запроса для каждой строки в таблице. Итак, для запроса. Если есть 3 факта и 5 измерений.....и есть высокий ЦП... Факты получают более высокий вес. Это не идеальное изображение .... но это помогает избежать вводящей в заблуждение информации о ЦП ... например, простая таблица системного календаря, используемая в запросе с высокой загрузкой ЦП, имеет очень большое количество обращений к ЦП. - person user1874594; 24.01.2016
comment
В этой последней части, как мне получить логику подсчета строк внутри оператора case. Например. Select tablename , case when tablename like '%bigtb%' then sel count ( '1' ) from databasename.tablename else 'dropped' end. Это определенно не то, что сработает.... но это просто логика голых костей, которая вошла бы в вышеупомянутый тип запроса. Я задавался вопросом, как мне это сделать. Большое спасибо еще раз - person user1874594; 24.01.2016
comment
Простая таблица системного календаря может быть причиной высокой загрузки ЦП, в зависимости от фактического запроса (я видел очень глупые вещи в календарях). Так что не заботьтесь об отдельных таблицах, проверяйте отдельные запросы, вызывающие высокое использование ресурсов. - person dnoeth; 24.01.2016