ITPub博客

首页 > 数据库 > Oracle > [20231012]奇怪的执行时长.txt

[20231012]奇怪的执行时长.txt

原创 Oracle 作者:lfree 时间:2023-10-16 21:24:27 0 删除 编辑

[20231012]奇怪的执行时长(sql_id=dtt2yfpx8jhp4).txt

--//今天例行检查,我发现一个奇怪的sql语句,实际上以前也遇到过,太久不做维护了,有点忘记了!!

1.环境:
SYS@192.168.100.235:1521/orcl> @ver1
SYS@192.168.100.235:1521/orcl> @ pr
==============================
PORT_STRING                   : x86_64/Linux 2.4.xx
VERSION                       : 19.0.0.0.0
BANNER                        : Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
BANNER_FULL                   : Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.3.0.0.0
BANNER_LEGACY                 : Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
CON_ID                        : 0
PL/SQL procedure successfully completed.

2.分析:
SYS@192.168.100.235:1521/orcl> @ ashtop sql_id 1=1 &day
    Total                                                                         Distinct Distinct
  Seconds     AAS %This   SQL_ID        FIRST_SEEN          LAST_SEEN           Execs Seen  Tstamps
--------- ------- ------- ------------- ------------------- ------------------- ---------- --------
    43254      .5   51% |               2023-10-11 08:35:40 2023-10-12 08:35:35          3    19604
     3687      .0    4% | dtt2yfpx8jhp4 2023-10-11 15:40:01 2023-10-11 16:41:35          1     3687
     2696      .0    3% | cyqv7gknyf7bh 2023-10-12 01:41:36 2023-10-12 08:34:38       1533     2696
     1864      .0    2% | 1p68ys9y3582r 2023-10-11 08:40:25 2023-10-12 08:30:44       1857     1521
     1393      .0    2% | g1v8dts358gq5 2023-10-11 08:35:39 2023-10-12 08:30:18        316     1205
     1152      .0    1% | 8p09mg2dsvvfa 2023-10-11 08:40:07 2023-10-12 08:33:38        606     1015
     1074      .0    1% | 3uzhsvstyytm2 2023-10-11 08:58:23 2023-10-11 23:52:26        148     1044
     1052      .0    1% | bfcjfb3yhz8rt 2023-10-11 08:36:07 2023-10-12 08:34:57        779     1032
      987      .0    1% | gxak7guzxkwbh 2023-10-11 08:37:05 2023-10-12 08:35:27        747      951
      880      .0    1% | 89u3urxj9zs1x 2023-10-11 08:37:50 2023-10-12 08:33:04        179      880
...
30 rows selected.
--//dtt2yfpx8jhp4仅仅执行1次,竟然要1个小时,而且是w3wp.exe执行的。

SYS@192.168.100.235:1521/orcl> @ sql_id dtt2yfpx8jhp4
--SQL_ID = dtt2yfpx8jhp4
select *from  lis_sample_operate where barcode=:Barcode and EXECUTE_STATE_TEXT='锁定报告'  
--//建立了barcode的索引,应该执行很快啊.

SYS@192.168.100.235:1521/orcl> @ dpc dtt2yfpx8jhp4 '' ''
PLAN_TABLE_OUTPUT
-------------------------------------
SQL_ID  dtt2yfpx8jhp4, child number 0
-------------------------------------
select *from  lis_sample_operate where barcode=:Barcode and
EXECUTE_STATE_TEXT='锁定报告'
Plan hash value: 2118786184
----------------------------------------------------------------------------------------------------------------------
| Id  | Operation                           | Name                          | E-Rows |E-Bytes| Cost (%CPU)| E-Time   |
----------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                    |                               |        |       |    12 (100)|          |
|*  1 |  TABLE ACCESS BY INDEX ROWID BATCHED| LIS_SAMPLE_OPERATE            |      1 |   127 |    12   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN                  | IX_LIS_SAMPLE_OPERATE_BARCODE |      8 |       |     4   (0)| 00:00:01 |
----------------------------------------------------------------------------------------------------------------------
Query Block Name / Object Alias (identified by operation id):
-------------------------------------------------------------
   1 - SEL$1 / LIS_SAMPLE_OPERATE@SEL$1
   2 - SEL$1 / LIS_SAMPLE_OPERATE@SEL$1
Peeked Binds (identified by position):
--------------------------------------
   1 - :1 (VARCHAR2(30), CSID=852): '1801158810'
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter("EXECUTE_STATE_TEXT"=U'\9501\5B9A\62A5\544A')
   2 - access("BARCODE"=SYS_OP_C2C(:BARCODE))
Note
-----
   - Warning: basic plan statistics not available. These are only collected when:
       * hint 'gather_plan_statistics' is used for the statement or
       * parameter 'statistics_level' is set to 'ALL', at session or system level
--//应该执行很快啊.

--//查看传入的绑定变量值。
SYS@192.168.100.235:1521/orcl> @ bind_cap_awr dtt2yfpx8jhp4 ''
@bind_cap_awr sql_id [column]
SNAP_ID INSTANCE_NUMBER SQL_ID        WAS LAST_CAPTURED       NAME       POSITION MAX_LENGTH DATATYPE_STRING VALUE_STRING
------- --------------- ------------- --- ------------------- -------- ---------- ---------- --------------- ---------------
  24195               1 dtt2yfpx8jhp4 YES 2023-09-01 17:12:17 :BARCODE          1         32 VARCHAR2(32)    _
  24196               1 dtt2yfpx8jhp4 YES 2023-09-01 17:12:17 :BARCODE          1         32 VARCHAR2(32)    _
  24310               1 dtt2yfpx8jhp4 YES 2023-09-06 12:52:53 :BARCODE          1         32 VARCHAR2(32)    _
  24311               1 dtt2yfpx8jhp4 YES 2023-09-06 12:52:53 :BARCODE          1         32 VARCHAR2(32)    _
  24886               1 dtt2yfpx8jhp4 YES 2023-09-30 12:11:24 :BARCODE          1         32 VARCHAR2(32)    7211153713
  24887               1 dtt2yfpx8jhp4 YES 2023-09-30 12:11:24 :BARCODE          1         32 VARCHAR2(32)    7211153713
  25153               1 dtt2yfpx8jhp4 YES 2023-10-11 15:59:32 :BARCODE          1         32 VARCHAR2(32)    20231011001256
  25154               1 dtt2yfpx8jhp4 YES 2023-10-11 15:59:32 :BARCODE          1         32 VARCHAR2(32)    20231011001256
8 rows selected.

--//查询带入绑定变量的值马上明白为什么,存在带入'_'的情况,开发程序将'_'当作空值.(注意是下划线而非减号)
SYS@192.168.100.235:1521/orcl> select count(*) from lis.LIS_SAMPLE_OPERATE where barcode='_';
  COUNT(*)
----------
    598071

SYS@192.168.100.235:1521/orcl> select count(*) from lis.LIS_SAMPLE_OPERATE;
  COUNT(*)
----------
 136678697

--//598071/136678697 = .00437574408541515434
--//程序在操作时没有做输入检查或者需求就是这样,导致索引要扫描大量数据,导致执行缓慢,我记忆里以前也遇到过.再次做一个记录.
--//我顺便查了几个数据块,几乎每个数据块都有barcode='_'的记录,走索引比全表扫描还慢.再看看表大小.

SYS@192.168.100.235:1521/orcl> @ segsum lis.lis_sample_operate
    SEG_MB OWNER                SEGMENT_NAME                   SEGMENT_TYPE         SEG_TABLESPACE_NAME            SUM(BLOCKS)
---------- -------------------- ------------------------------ -------------------- ------------------------------ -----------
     21062 LIS                  LIS_SAMPLE_OPERATE             TABLE                LIS_DATA                           2695936

--//21G呢? 要建立索引估计给包括EXECUTE_STATE_TEXT字段,放弃!!
--//正常的业务应该看不到带入_的查询,开发应该在程序中限制这样的情况出现.
--//我自己做一个推测,这个值应该不是键盘输入的,而是通过手持扫描器输入的,可能在扫描时出现问题,比如出现非法字符,应用自动重置为_.
--//操作员没看继续查询,出现问题,或者是扫描后马上自动执行。不过从执行次数上看仅仅1次,说明这个功能很少使用。

SYS@192.168.100.235:1521/orcl> select count(*), EXECUTE_STATE_TEXT  from lis.LIS_SAMPLE_OPERATE where barcode='_'   group by EXECUTE_STATE_TEXT;
  COUNT(*)  EXECUTE_STATE_TEXT
----------  ------------------------
    156204 标本归档
     10382 锁定报告
    ~~~~~~~~~~~~~~~~~

       339 复制样本

...

54 rows selected.
--//如果查询返回10382条,这样的操作属于无效查询,没有任何意义.
--//我总觉的在dba与开发之间存在一条无法跨越的鸿沟,沟通存在问题.

来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/267265/viewspace-2989214/ ,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
熟悉oracle相关技术,擅长sql优化,rman备份与恢复,熟悉linux shell编程。

注册时间:2008-01-03

  • 博文量
    4006
  • 访问量
    7969769