通过oracle 自动优化任务dbms_sqltune进行SQL优化的实战

服务概述

用户的数据库系统在2026年3月31日上午排业务部门反馈，HIS数据库一条语句查询卡顿，运行速度较慢，影响了正常的业务。在此情况下需要排查出问题的深层原因，从而从根本上解决问题。

工程师在发现语句卡顿后，及时进行响应，通过相应的性能数据信息对数据库及问题进行分析排查，通过对数据库历史性能信息进行分析，明确问题原因并针对性的提出了优化建议；根据整个排查分析过程汇总整理此文档。

问题分析
1. 空间问题
  1. 服务器本地空间

服务器本地空间使用率正常。

1. 1. 查看CPU使用率

服务器CPU使用率正常。

1. 数据库AWR报告分析

客户反馈该语句卡顿

首要瓶颈：单次执行耗时极长的SQL

SQL ID: bsbjasa37qr7u

问题: 这条SQL虽然只执行了1次，但其单次执行耗时高达 1,557.35秒 (约26分钟)，占总消耗时间的 4.77%。这是一个非常严重的性能问题，需要立即关注。

处理过程
1. 问题分析总结

通过对AWR报告和操作系统分析，可以发现这条SQL虽然只执行了1次，但其单次执行耗时高达 1,557.35秒 (约26分钟)，SQL语句需要进行优化处理。

1. 处理建议
优化业务语句
1.
1. SQL优化过程

利用oracle自带的sql自动优化功能，对需要优化的sql进行处理。

SQL> set long 999999

SQL> set LONGCHUNKSIZE 999999

SQL> set serveroutput on size 999999

SQL> set linesize 200 pagesize 1000

SQL> SELECT dbms_sqltune.report_tuning_task('TASK_348499') FROM dual;

DBMS_SQLTUNE.REPORT_TUNING_TASK('TASK_348499')

GENERAL INFORMATION SECTION

Tuning Task Name : TASK_348499

Tuning Task Owner : SYS

Workload Type : Single SQL Statement

Scope : COMPREHENSIVE

Time Limit(seconds): 1800

Completion Status : COMPLETED

Started at : 03/31/2026 10:26:36

Completed at : 03/31/2026 10:27:20

Schema Name: ZJHIS

SQL ID : 8mupz6ybr3huu

SQL Text : --3115030190077ʾϸ

SELECT distinct B.PATIENT_NO,

b.bah,

b.name,

b.social_id,

T.Jz_Date ʱ

..................

AND z.CHARGE_DATE between

to_date('2024-01-01 00:00:00', 'YYYY-MM-DD HH24:MI:SS')

and

to_date('2024-06-30 23:59:59', 'YYYY-MM-DD HH24:MI:SS')

and z.charge_code in(1377)

and z.old_jlxh is null

and z.jlxh not in

(select z.old_jlxh

from ZY_DETAIL_CHARGE z

where z.CHARGE_DATE between

to_date('2024-01-01 00:00:00', 'YYYY-MM-DD

HH24:MI:SS') and

to_date('2024-06-30 23:59:59', 'YYYY-MM-DD

HH24:MI:SS')

and z.old_jlxh is not null)

order by b.patient_no,trunc(z.charge_date)

FINDINGS SECTION (2 findings)

1- SQL Profile Finding (see explain plans section below)

A potentially better execution plan was found for this statement.

Recommendation (estimated benefit: 96.43%)

Consider accepting the recommended SQL profile.

execute dbms_sqltune.accept_sql_profile(task_name => 'TASK_348499',

task_owner => 'SYS', replace => TRUE);

2- Index Finding (see explain plans section below)

The execution plan of this statement can be improved by creating one or more

indices.

Recommendation (estimated benefit: 99.75%)

Consider running the Access Advisor to improve the physical schema design

or creating the recommended index.

create index ZJHIS.IDX$$_551530001 on

ZJHIS.ZY_SFFLXX("PATIENT_NO","PINGTAIID");

Consider running the Access Advisor to improve the physical schema design

or creating the recommended index.

create index SIIM.IDX$$_551530002 on SIIM.YB_ZYDJXX(TO_NUMBER("YYZYHM"));

Rationale

Creating the recommended indices significantly improves the execution plan

of this statement. However, it might be preferable to run "Access Advisor"

using a representative SQL workload as opposed to a single statement. This

will allow to get comprehensive index recommendations which takes into

account index maintenance overhead and additional space consumption.

EXPLAIN PLANS SECTION

1- Original With Adjusted Cost

Plan hash value: 3649751971

| 0 | SELECT STATEMENT | | 1 | 427 | 598K (1)| 01:59:46 |

| 1 | SORT GROUP BY | | 1 | 25 | | |

| 2 | TABLE ACCESS BY INDEX ROWID | BL_BINGRENZDQK | 3 | 75 | 5 (0)| 00:00:01 |

|* 3 | INDEX RANGE SCAN | INDEX_BL_BINGRENZDQK | 3 | | 3 (0)| 00:00:01 |

| 4 | SORT GROUP BY | | 1 | 17 | | |

| 5 | TABLE ACCESS BY INDEX ROWID | ZY_ZDXX | 5 | 85 | 5 (0)| 00:00:01 |

|* 6 | INDEX RANGE SCAN | PK_ZY_ZDXX | 5 | | 3 (0)| 00:00:01 |

|* 7 | TABLE ACCESS BY INDEX ROWID | ZY_SFFLXX | 1 | 27 | 4 (0)| 00:00:01 |

|* 8 | INDEX RANGE SCAN | PK_ZY_SFFLXX | 1 | | 3 (0)| 00:00:01 |

|* 9 | TABLE ACCESS BY INDEX ROWID | ZY_SFFLXX | 1 | 27 | 4 (0)| 00:00:01 |

|* 10 | INDEX RANGE SCAN | PK_ZY_SFFLXX | 1 | | 3 (0)| 00:00:01 |

|* 11 | TABLE ACCESS BY INDEX ROWID | ZY_SFFLXX | 1 | 27 | 4 (0)| 00:00:01 |

|* 12 | INDEX RANGE SCAN | PK_ZY_SFFLXX | 1 | | 3 (0)| 00:00:01 |

|* 13 | INDEX RANGE SCAN | IDX_GY_BRXZ_BRLB_YBXZ1 | 1 | 27 | 2 (0)| 00:00:01 |

| 14 | SORT ORDER BY | | 1 | 427 | 598K (1)| 01:59:46 |

| 15 | HASH UNIQUE | | 1 | 427 | 598K (1)| 01:59:46 |

| 16 | NESTED LOOPS | | 1 | 427 | 598K (1)| 01:59:45 |

| 17 | NESTED LOOPS | | 13 | 427 | 598K (1)| 01:59:45 |

| 18 | NESTED LOOPS | | 1 | 362 | 598K (1)| 01:59:39 |

| 19 | NESTED LOOPS | | 50 | 15550 | 598K (1)| 01:59:39 |

| 20 | NESTED LOOPS | | 50 | 14100 | 598K (1)| 01:59:37 |

| 21 | NESTED LOOPS ANTI | | 2885 | 546K| 592K (1)| 01:58:28 |

|* 22 | TABLE ACCESS BY INDEX ROWID| ZY_DETAIL_CHARGE | 288K| 50M| 5 (0)| 00:00:01 |

|* 23 | INDEX RANGE SCAN | INDEX_CHARGE_DATE | 1 | | 4 (0)| 00:00:01 |

|* 24 | TABLE ACCESS BY INDEX ROWID| ZY_DETAIL_CHARGE | 104K| 1024K| 8 (0)| 00:00:01 |

|* 25 | INDEX RANGE SCAN | PK_ZY_DEATAIL_OLD_JLXH | 9 | | 2 (0)| 00:00:01 |

|* 26 | TABLE ACCESS BY INDEX ROWID | ZY_PATIENT_INFORMATION | 1 | 88 | 2 (0)| 00:00:01 |

|* 27 | INDEX UNIQUE SCAN | PK_ZY_PATIENT_INFORMATION | 1 | | 1 (0)| 00:00:01 |

| 28 | TABLE ACCESS BY INDEX ROWID | ZY_TOTAL_FEE | 1 | 29 | 3 (0)| 00:00:01 |

|* 29 | INDEX RANGE SCAN | PK_ZY_TOTAL_FEE_PJI | 1 | | 2 (0)| 00:00:01 |

|* 30 | TABLE ACCESS BY INDEX ROWID | YB_ZYJSXX | 1 | 51 | 1 (0)| 00:00:01 |

|* 31 | INDEX UNIQUE SCAN | PK_YB_ZYJSXX | 1 | | 0 (0)| 00:00:01 |

|* 32 | INDEX RANGE SCAN | IDX_YB_ZYDJXX_1 | 13 | | 495 (1)| 00:00:06 |

|* 33 | TABLE ACCESS BY INDEX ROWID | YB_ZYDJXX | 1 | 65 | 503 (1)| 00:00:07 |

Predicate Information (identified by operation id):

3 - access("T"."BRXH"=:B1)

filter("T"."ZDLB"=3 OR "T"."ZDLB"=4)

6 - access("X"."PATIENT_NO"=:B1)

7 - filter("FLYWMC"='ZJE198')

8 - access("PATIENT_NO"=:B1 AND "PINGTAIID"=:B2)

9 - filter("FLYWMC"='*JINE07198')

10 - access("PATIENT_NO"=:B1 AND "PINGTAIID"=:B2)

11 - filter("FLYWMC"='*JINE05198')

12 - access("PATIENT_NO"=:B1 AND "PINGTAIID"=:B2)

13 - access("XZDM"=:B1 AND "BRLB"=98)

filter("BRLB"=98)

22 - filter("Z"."OLD_JLXH" IS NULL)

23 - access("Z"."CHARGE_DATE">=TO_DATE(' 2024-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND

"Z"."CHARGE_CODE"=1377 AND "Z"."CHARGE_DATE"<=TO_DATE(' 2024-06-30 23:59:59', 'syyyy-mm-dd hh24:mi:ss'))

filter("Z"."CHARGE_CODE"=1377)

24 - filter("Z"."CHARGE_DATE">=TO_DATE(' 2024-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND

"Z"."CHARGE_DATE"<=TO_DATE(' 2024-06-30 23:59:59', 'syyyy-mm-dd hh24:mi:ss'))

25 - access("Z"."JLXH"="Z"."OLD_JLXH")

filter("Z"."OLD_JLXH" IS NOT NULL)

26 - filter("B"."YBJYLSH" IS NOT NULL AND SUBSTR("B"."BAH",1,1)<>'Q' AND "B"."BRLB"<>1 AND

"Z"."JS_NO"="B"."JS_NO")

27 - access("Z"."PATIENT_NO"="B"."PATIENT_NO")

29 - access("B"."PATIENT_NO"="T"."PATIENT_NO" AND "B"."JS_NO"="T"."JS_NO")

30 - filter("C"."YLBXID"=600 AND "C"."JYCXBZ"=0 AND "C"."YBQRBZ"=1 AND

"T"."PATIENT_NO"=TO_NUMBER("C"."YYZYHM"))

31 - access("C"."ZYJSID"=TO_NUMBER("T"."YBJYLSH"))

32 - access("D"."YLBXID"=600)

filter("B"."PATIENT_NO"=TO_NUMBER("D"."YYZYHM"))

33 - filter("D"."ZYDJZT"=1 AND "D"."YBQRBZ"=1)

2- Using SQL Profile

Plan hash value: 3095748882

| 0 | SELECT STATEMENT | | 23 | 9821 | 21340 (1)| 00:04:17 |