• 被Oracle全局暂时表坑了


        今天凌晨4点多钟,在客户现场的负责人打电话给我,说非常奇怪,下载功能时快时慢。此下载功能非常复杂,之前一直是我优化,在半梦半醒中打开电脑,通过远程看着现场同事在PL/SQL developer中操作。运行同一条SQL,时快时慢,快的时候大概0.6s,慢的时候超过1分钟。

        这条SQL有调用一个函数,功能是动态生成接近200条查询语句,SQL中都是有绑定变量的。是现场的測试环境,刚刚部署,心想应该不是数据库负载所致。

        1. 抓取数据库AWR报告,全然没有压力,数据库server配置都是杠杠的。此刻心里有点乱,头一次遇到这样的问题。现场9点钟要跟客户演示,此时已经快5点钟了。

        2. 神器出场,打算用10046 trace定位到究竟是那条SQL有问题,trace了多次,仅仅有一次是慢的。期间也有插曲,现场不太会用sqlplus,交互化了非常多时间。从众多的SQL中抽丝剥茧,最终定位到SQL,对照是:

    SELECT DISTINCT D.ID, D.TABLE_NAME, DCT.COLUMN_NAME, GG.DATA_TYPE, 
      GG.TECHPARAM_NAME,DCT.SORT_NO FROM GG_CLASSIFY_TECHPARAM DCT, GG_TECHPARAM 
      GG, GG_CLASSIFY D, REL_OID_CLASSIFY T WHERE DCT.TECHPARAM_ID = GG.ID AND 
      D.ID = DCT.CLASSIFY_ID AND T.CLASSIFY_ID = D.ID
    call     count       cpu    elapsed       disk      query    current        rows
    ------- ------  -------- ---------- ---------- ---------- ----------  ----------
    Parse        0      0.00       0.00          0          0          0           0
    Execute      1      0.00       0.00          0          0          0           0
    Fetch        2     61.00      61.04          0   25968917          0         156
    ------- ------  -------- ---------- ---------- ---------- ----------  ----------
    total        3     61.00      61.04          0   25968917          0         156

    call     count       cpu    elapsed       disk      query    current        rows
    ------- ------  -------- ---------- ---------- ---------- ----------  ----------
    Parse        0      0.00       0.00          0          0          0           0
    Execute      1      0.00       0.00          0          0          0           0
    Fetch        2      0.80       0.81          0       32461         0         156
    ------- ------  -------- ---------- ---------- ---------- ----------  ----------
    total        3      0.80       0.81          0       32461         0         156

       3. 分析问题,第一感觉是SQL逻辑是否有问题,可惜10046里面没有trace到运行计划,只是看逻辑读,慢的那次应该是产生了笛卡尔积。经过简单的检查,SQL逻辑没有问题,人的第一感觉不一定靠谱。

       4. 我在想是什么导致运行计划不准呢,猛然想起REL_OID_CLASSIFY是全局暂时表,高速的想到一种可能,REL_OID_CLASSIFY的统计信息不准导致,通过user_tables查看这张表是没有统计信息的。那就是每次运行都动态採集啰,在Oracle 11g中运行autotrace,发现level=2,我想试试把动态採样的级别,说干就干。

     SELECT /*+ dynamic_sampling(T 10) */DISTINCT D.ID, D.TABLE_NAME, DCT.COLUMN_NAME, GG.DATA_TYPE, 
      GG.TECHPARAM_NAME,DCT.SORT_NO FROM GG_CLASSIFY_TECHPARAM DCT, GG_TECHPARAM 
      GG, GG_CLASSIFY D, REL_OID_CLASSIFY T WHERE DCT.TECHPARAM_ID = GG.ID AND 
      D.ID = DCT.CLASSIFY_ID AND T.CLASSIFY_ID = D.ID;

            发给开发者,改动相关函数。增量后,多次測试后发现问题攻克了。此时已经快7点了,天已经大亮,我有点倦意,但无法再次入睡。

           总结:对于这次暂时表的问题,我想问题在于採样率低了以后造成的恶果。对于全局暂时表要注意两点,一是要锁定暂时表收集统计信息的功能,由于你收集的统计信息肯定是错的;二是使用它时最好是使用动态採用。学习知识,基础非常重要。

  • 相关阅读:
    洛谷 P3138 [USACO16FEB]Load Balancing S(二维前缀和,离散化)
    洛谷 P1052 [NOIP2005 提高组] 过河(dp,数学)
    洛谷 P1955 [NOI2015] 程序自动分析(并查集,离散化)
    洛谷 P3258 [JLOI2014]松鼠的新家(树上差分,lca)
    洛谷 P2296 [NOIP2014 提高组] 寻找道路(反图bfs)
    洛谷 P4141 消失之物(dp方案数)
    洛谷 P5322 [BJOI2019]排兵布阵(dp,分组背包)
    回溯算法
    分治法
    分支限界法
  • 原文地址:https://www.cnblogs.com/lcchuguo/p/4072895.html
Copyright © 2020-2023  润新知