【问题标题】:Teradata - report for top "stats hoggers"Teradata - 顶级“统计数据爱好者”的报告
【发布时间】:2016-04-28 09:38:14
【问题描述】:

试图编制一份“统计数据”报告。所有那些占用 CPU 运行统计数据的用户
关于什么“table.cols”(或 col1、col2 等),他们是否运行了统计信息以及何时运行。

我写了下面的报告,但我可以看到它与真实相去甚远

  • 它不会将给定查询中的 CPU 按一定比例的权重“拆分”到表中。因此,如果在统计操作中 - 最昂贵的 CPU 在 FACT.BILLION_DOLLAR 表上,但还有一个 DIMENSION.DWARF 表,则 DIMENSION.DWARF 将虚假地显示在图表上 - 这会使报告产生误导。
    我也在尝试编译另一个报告,其中我希望按 TABLE 获得 TOP CPU。它不是“严格”的,因为 CPU 用于查询而不是对象,但在查询中我想按比例“拆分”CPU(我猜 count(*) 将是 1 个条件)。那我该怎么做呢
  • 它“拉错了人”- 反对运行统计操作的用户名显示不正确。我们运行 stats 的生产 ID 是 SWPRDUSR,但最高的 stats 用户显示为 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 ;

【问题讨论】:

    标签: sql database report teradata sql-tuning


    【解决方案1】:

    在第一个选择中缺少连接条件:s.queryID = a.queryID

    Collect Stats 始终是单表,无需拆分 CPU。

    【讨论】:

    • 你是对的。 TY ...真是个糟糕的小姐。我需要一副新眼镜.....或者那些后面的东西......或者后面的任何东西(在那些后面)......我在 PI 上看到了 PI 作为 Logdate 和 ProcID(不知道为什么 QueryID 不存在. 如果queryID 在那里,它将是一个PI - PI 连接,查询ID 提供更好的分布和连接的一部分).. 并抓住了那些......假设除了这些之外没有任何东西。 OBJECT 、 LOG 和 SQL 所有 3 个表都有 QueryID。为什么不把它保存在 PI 中。感谢迪特提供的信息
    • @user1874594: dbc 中的 DBQL 表的 PI 仅用于将缓存的数据作为单个数据块高效写入。这就是为什么必须每天将数据移动到历史记录表的原因,否则 QueryId 上的所有联接都会执行得非常糟糕。
    • 你好迪特。对此的推论 - 如果我需要知道具有 Max CPU Hits 的表。我该如何获取这些 - 每个查询有多个表
    • 无法在表之间拆分 CPU。
    • 我正在考虑使用这种逻辑。如果 stats 表的行计数值小于 5 天...继续选择该值,否则进行计数 (*) 。然后使用一个公式,该公式为每个表的每行查询 ID 执行 CPU。所以进行查询。如果有 3 个事实和 5 个维度......并且 CPU 很高......事实得到更高的重量。它并不完美....但它有助于避免误导 CPU 信息...例如,在高 CPU 查询中使用的简单 sys 日历表具有非常高的 CPU 命中率。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2010-09-18
    • 1970-01-01
    • 2022-10-16
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多