简介面向 Oracle 数据库管理员与 SQL 性能调优开发者这是一套覆盖 Oracle 10g 至 19c 多个版本的调优工具资源包可帮助定位 SQL 执行效率低、执行计划不稳定等常见问题。压缩包共 205 个文件以 160 个 SQL 脚本为核心另有 19 个包体、19 个包规范、5 个说明文档及 2 个网页格式报告整体仅 927KB轻量紧凑便于快速部署和日常使用。当前已有 413 人学习适合数据库管理员和开发人员在日常维护、故障排查时参考。资源中既包含 SQLT 调优助手工具也涵盖 SQL 概要文件迁移脚本支持跨环境传递并应用更优执行计划从而减少语句响应时间与资源消耗同时附有包体源码与说明文档便于理解内部逻辑可在开发、测试与生产环境之间复用调优策略有效提升数据库运行的稳定性与整体效率。 手头有条SQL从秒级响应退化到分钟级应用方连环催业务方盯得紧我在终端里翻执行计划、查统计信息、导10053 trace忙活一个多小时才把诊断材料凑齐。后来同一场景我用SQLT处理十分钟内拿到一份打包好的HTML报告问题一目了然。最近整理工具包又翻出 sqlt_10g_11g_12c_18c_19c_5th_June_2020.zip借这个机会把这套Oracle官方SQL诊断工具的安装、方法选型、实战过程和踩坑经验从头到尾梳理一遍给同样被慢SQL折磨的DBA和性能工程师做个参考。文件名看着像补丁包其实是SQLTXPLAIN圈内通常叫SQLT的标准发行包。它的作用很简单你给它一条SQL可以是SQL_ID、HASH_VALUE也可以是SQL全文它自动收集这条SQL相关的执行计划、对象统计信息、绑定变量、初始化参数、等待事件、优化器trace等十几类诊断数据最后打包成一个zip里面是结构化的HTML报告。你把这个zip发给Oracle Support或者自己打开报告分析都能高效还原这条SQL在数据库里的完整运行情况。包名里每个字段都有讲究sqlt是工具名10g_11g_12c_18c_19c代表支持的数据库版本区间5th_June_2020是构建日期。所以只需保留这一个压缩包就能覆盖从10.2.0.4到19c的大多数主流版本不用为每个大版本单独找工具这在维护多套不同版本数据库的环境里非常省心。这篇文章按“是什么、怎么装、方法怎么选、实战怎么做、报告怎么看、坑怎么避”的顺序展开适合三类人被慢SQL追着跑的一线DBA做性能优化的数据库顾问以及对Oracle优化器工作机制感兴趣的开发人员。1. SQLT到底是什么和AWR、ASH、SQL Monitor有什么区别先说定位。SQLT做的是SQL级的“全景体检”。Oracle自带工具里AWR看的是系统层面的历史性能快照ASH看的是某个时间窗口内活跃会话在干什么SQL Monitor看的是某条SQL执行期间的实时和历史性能。SQLT则完全不同它聚焦“一条SQL”把这条SQL在优化器眼中的一切重要信息都捞出来回答三个问题它为什么慢CBO看到的统计信息到底是什么样子换执行计划甚至换种写法能不能变快SQLT是Oracle Support团队维护的PL/SQL程序集最早由Carlos Sierra开发后来并入官方工具序列。它用纯SQL和PL/SQL实现不装Agent、不重启库、不额外起进程对生产环境的侵入很小。下载需要MOS账号官方文档入口是Doc ID 215187.1工具本身免费。为什么文件名要覆盖10g到19c这么多版本因为SQLT大量使用内部视图和DBMS包而10g的优化器模型和19c之间差异巨大脚本必须做版本兼容。解压后你会看到utl目录下按版本区分的许多脚本安装时工具会自动识别当前库版本选择合适的逻辑执行。这也提醒我一件事这套脚本虽然兼容面广但生产库上装SQLT最好还是在每个目标库里单独装一份别指望用19c库跑出的SQLT包去诊断10g库的SQL——库版本不同收集到的部分内部信息不可比。我自己用SQLT最频繁的场景是这几类应用升级后SQL执行计划突变同一套SQL在测试库正常、生产库缓慢以及需要向Oracle Support提交性能问题时用SQLT生成的zip作为标准附件。它不负责改写SQL但能把问题压缩成一份“可交付”的诊断产物。2. 安装与初始化十分钟搞定但有几个前提SQLT的安装相当轻量在SQL*Plus里执行两个脚本即可但前提条件要先满足。2.1 环境要求数据库版本必须是10.2.0.4以上这套包正好覆盖10g到19c。还要有SYSDBA权限的账号因为安装脚本要建用户、建角色、建视图。磁盘空间要求不高默认表空间留出50MB到100MB就够。整个过程不需要重启实例这点对生产环境很友好。如果数据库是12c以上的多租户架构要特别注意SQL在哪个容器里执行就要在哪个容器里安装SQLT对象。只装在CDB根容器到PDB里调用会报ORA-00942反过来只装在PDB根容器又会缺对象。我习惯的做法是CDB和业务PDB各装一遍成本很低省得后面排查权限问题。2.2 安装步骤解压后进入目录用SYS登录执行unzip sqlt_10g_11g_12c_18c_19c_5th_June_2020.zip cd sqlt_10g_11g_12c_18c_19c_5th_June_2020 sqlplus / as sysdba在SQL*Plus里依次执行SQL install/sqlt_create_sys.sql SQL install/sqlt_create_user.sql第一个脚本创建SQLT自己用的辅助表比如plan表和一些统计信息采集视图这些对象建在SYS schema下。第二个脚本创建专用用户sqltxpl默认密码也是sqltxpl并授予sqltxpl_role角色这个角色囊括了运行诊断SQL所需的各类视图和包的执行权限。安装完成后日常使用不建议再用SYS登录而是用sqltxpl用户操作sqlplus sqltxpl/sqltxplorclpdb1注意sqlt_create_user.sql执行时如果提示用户已存在说明之前装过此时要决定是drop掉重建还是复用现有用户补授权。我一般直接drop user sqltxpl cascade重建避免权限残留导致奇怪问题。安装后可以跑一下demo目录里的测试脚本确认环境正常也可以直接开始用。说实话我见过不少同事卡在安装这一步大多是因为在CDB和PDB之间搞混了容器或者用了普通账号执行安装脚本注意这两点就没什么坑了。3. 模式与方法选型XPLORE、XECUTE、XTRXPLORE到底怎么选用SQLT时的核心入口是sqltxtract.sql调用语法大致是SQL sqltxtract.sql SQL输入 工作模式 统计信息处理级别SQL输入可以是SQL_ID、HASH_VALUE或SQL全文。工作模式决定SQLT要不要真正执行你的SQL这是最需要想清楚的选择。三种主要模式对比如下模式是否执行SQL收集内容适用场景XPLORE不执行基于现有统计信息分析优化器生成多种执行计划与CBO诊断信息SQL非常慢、不能随便重复执行的场景XECUTE执行默认限制返回行数真实执行计划、实际等待事件、会话统计、运行时资源消耗常规首选能拿到最接近真实情况的信息XTRXPLORE执行并附加trace在XECUTE基础上再做10053等优化器trace深挖需要追根溯源弄清优化器为什么这么选第三个参数是统计信息处理级别它控制SQLT是否重新收集统计信息常见取值0不碰统计信息完全使用现有的CBO统计适合只想看当前状态的情况1对SQL涉及的表和索引重新收集统计信息推荐默认值能排除“统计信息过期导致选错计划”的干扰2在级别1基础上进一步收集直方图等细粒度统计适合字段分布极度不均、需要看数据倾斜的场景。举个例子一条报表SQL跑了半小时都出不来你肯定不想用XECUTE再让它跑一遍。这时选XPLORE加级别0SQLT只做静态分析基于现有统计信息生成CBO眼中的执行计划既安全又能定位问题。反过来如果SQL只是从50毫秒退化到5秒完全可以接受再执行一次那就用XECUTE获取真实运行时的等待和资源数据诊断价值比纯静态分析高得多。选择的核心逻辑就一句话你愿意承受多大代价就换取多接近真实的数据。级别越高、模式越激进数据越全但对目标SQL的影响也越大。我给客户的建议是没有把握的SQL先用XPLORE看计划再决定要不要升级到XECUTE。4. 实战演示给一条19c上的慢SQL做一次完整体检下面用一次实际诊断过程说明完整操作。环境是一套19c单实例业务反馈某张订单汇总表的查询越来越慢我在库里查到这条SQL的SQL_ID是b2x7k6j1m0r9z示例值执行计划已经从索引扫描变成了大表全扫。4.1 执行SQLT用sqltxpl用户登录目标PDBsqlplus sqltxpl/sqltxplorclpdb1然后执行SQL set long 200000 SQL set pagesize 0 SQL set linesize 300 SQL sqltxtract.sql b2x7k6j1m0r9z XECUTE 1工具开始后会在终端打印进度大致经历几个阶段读取SQL文本和绑定变量、创建内部临时表、收集涉及对象的统计信息、执行SQL并抓取真实执行计划、最后打包生成zip文件。整个过程大概几分钟取决于SQL复杂度和对象大小。结束后在SQLT的日志目录下会生成一个类似sqlt_s_b2x7k6j1m0r9z_202606051015.zip的压缩包。4.2 从终端输出能先看出什么SQLT在终端里会先展示一段SQL本身的信息包括SQL文本、绑定变量、所在schema。这一步非常重要我建议先确认抓到的SQL确实是要诊断的那条尤其是通过SQL_ID匹配时如果SQL不在共享池里工具会直接报错提示找不到。绑定变量那边也能看出问题比如变量值传入后优化器估算的选择性明显偏离实际返回行数这类基础信息在终端就能快速获取不用等报告生成。4.3 打开HTML报告找根因打开zip里的主HTML我先看“CBO Execution Plan”板块。这份报告中的计划对比很清楚计划来源访问路径估算行数实际行数Cost当前执行计划ORDER_DETAILS全表扫描12,400,00011,800,00018,432替代计划AORDER_DETAILS索引SK_ORDER_DT范围扫描86,00078,5002,841替代计划B索引SK_ORDER_DT回表排序86,00078,5003,102差异非常明显CBO估算全表扫描12,400,000行实际返回11,800,000行说明扫描路径本身没问题问题在于统计信息或者执行路径选择逻辑。再切到“Object Statistics”板块发现ORDER_DETAILS表的LAST_ANALYZED是一年多以前且PURGE_FLAG‘Y’的数据占全表42%旧统计完全没反映这批数据。根因基本锁定统计信息过期加上大量已标记删除的数据导致优化器认为全扫更便宜。处理措施就很直接了先按业务规则清掉或归档PURGE_FLAG‘Y’的历史数据再对ORDER_DETAILS及相关索引重新收集统计信息最后让SQL重新解析。这套操作做完SQL回到秒级。SQLT在这里的真正价值不是替我做决定而是把“计划差异、统计信息过期、数据分布异常”这三条线索一次性摆到桌面上省去了逐项手工排查的时间。4.4 生产库不能随便跑SQL怎么办有的场景下生产SQL涉及超大表或者本身就是UPDATE/DELETE直接XECUTE风险太高。我一般用两个替代方案一是改用XPLORE模式让SQLT只做静态分析不真正执行二是SQLT支持“异地诊断”思路把目标schema用Data Pump导出到一套测试库在测试库上安装SQLT后再跑XECUTE。虽然导入导出有些额外工作量但对核心生产环境而言这个隔离是值得的。5. 报告拿到手优先看哪六个板块SQLT生成的HTML报告信息量很大第一次看容易迷失在大量表格里。我按自己的使用频率排个序新手按这个顺序看基本不会跑偏。5.1 SQL Text与绑定变量先确认诊断对象。报告开头会展示SQL全文和绑定变量快照同时标注SQL所在schema、执行频率、平均执行时间等元信息。绑定变量的实际值要重点看——很多执行计划问题都源于变量值导致的选择性误判。这份报告里会把每个绑定变量的值、数据类型、是否在SQL中被隐式转换标出来能少走很多弯路。5.2 CBO Execution Plan这是核心板块。SQLT会展示多套执行计划当前正在使用的计划、基于现有统计信息重新生成的计划、以及加上不同hint后的替代计划。每套计划的Cost、基数估算、物理读写、访问路径都列在表格里。我通常会先定位Cost最高的那步操作再看它对应的对象是否有索引可用、统计信息是否新鲜。这个板块基本替代了手工执行EXPLAIN PLAN再加各种hint试错的流程。5.3 Differential Report这是SQLT最让我惊喜的功能没有之一。它能把两套执行计划并排对比差异项用颜色标出基数估算变了多少、访问路径换了哪个、哪个hint导致了变化一目了然。比如你怀疑是某个参数改动导致计划翻转SQLT可以直接生成改动前后的计划差异报告省去自己拿两个spool文件逐行核对的时间。5.4 Optimizer Environment这个板块列出SQL执行时优化器相关的初始化参数包括optimizer_features_enable、optimizer_mode、各种adaptive参数等。很多计划问题是参数层面的比如某套库被人改了optimizer_features_enableSQLT会在报告里直接标注出“当前参数与默认值的差异”这比你在库里逐个show parameter高效得多。5.5 Object Statistics统计信息是执行计划的地基。SQLT会列出SQL涉及的所有表和索引的统计信息包括行数、块数、直方图、最后分析时间并和实际值做对比。如果发现某张表的统计信息显示1万行实际查询返回100万行这就是明显的统计信息失真。报告里还会标注哪些对象完全没有统计信息——在19c上动态采样有时能兜底但复杂SQL一旦基数估算错计划就容易翻车。5.6 Waits与SQL MonitorXECUTE模式下SQLT会抓取SQL执行期间的真实等待事件比如db file sequential read、direct path read、enq: TX等并统计等待次数和总耗时。配合SQL Monitor板块12c以上可用能还原SQL执行的时间线看出瓶颈到底在I/O、CPU还是锁等待。我遇到过很多案例SQL本身不慢慢在等一个被锁的行这种问题只看执行计划是发现不了的必须看等待事件。报告里其实还有10053 trace、10046 trace等原始材料属于进阶内容。想研究优化器为什么选A计划而不选B计划时打开10053 trace看cost计算过程收获很大但不适合新手入门。6. 常见问题与避坑实录SQLT用熟练之后很顺手但初期有几个坑我基本每次培训都会遇到整理成速查表现象可能原因处理办法报ORA-20000: SQLT找不到SQL_IDSQL_ID不在共享池或SQL已被淘汰改用SQL全文输入或先让SQL跑一次再诊断安装时报ORA-00942用非SYS用户执行了安装脚本用SYSDBA身份重新执行install脚本输出了报告但没生成zip日志目录无UTL_FILE写权限检查并创建SQLT要求的目录对象赋读写权限XECUTE执行时间过长SQL本身代价极高返回行数虽限制但排序/全扫仍耗时改用XPLORE模式或配合MAXROWS参数进一步限制12c/19c多PDB下报对象不存在目标PDB里没有安装SQLT对象在对应PDB里重跑sqlt_create_sys.sql和sqlt_create_user.sql报告中的SQL文本含敏感业务数据这是正常现象SQL全文会被记录外发Oracle Support前手动检查必要时脱敏处理几个实战经验再单独说说。第一不要把SQLT当成“自动优化器”。它不生成改写建议也不自动改SQL它做的是高质量的信息收集和呈现。最终判断还是靠人。但也正因为这样它非常客观不会像某些优化工具那样给出拍脑袋的建议。第二用SQL全文做输入时匹配是精确的空格、换行、大小写都会影响匹配结果。我通常优先用SQL_ID只有在共享池里找不到时才用全文并且会从AWR或历史会话里复制完整文本避免手输漏字符。第三在RAC环境下一个SQL_ID可能对应多个实例上的不同版本SQLT默认诊断当前连接的实例。如果需要分析其他实例上的SQL要么连接到对应实例执行要么在参数里指定instance_id别在一个节点上诊断另一个节点的问题容易拿到不完整的数据。第四SQLT运行前最好确认默认表空间余量。它要创建一些临时表来模拟SQL对象如果表空间撑满诊断过程会报错前功尽弃。我在大表环境下习惯先看dba_data_files确认余量再看diagnostic_dest的磁盘空间因为最终zip也要写在那里。最后聊一点我的个人体会。刚开始用SQLT时我也觉得它的报告太厚、信息太杂一度还是习惯手工查视图。但用多了之后我反而把SQLT当成一个“学习优化器的教具”每次拿到一份计划异常的XECUTE报告我都会顺着它的Differential提示打开10053 trace看看CBO到底因为哪一项统计信息差异改变了cost判断。这样积累下来的经验比单纯背调优技巧要扎实得多。也正因为如此我这个10g用到19c的老包一直没删每次版本更新也只是在这个命名基础上替换新日期而已。如果你还没用过SQLT建议下次遇到慢SQL时别急着加班手动翻数据字典先把它跑一遍很多问题自己就浮出来了。本文还有配套的精品资源点击获取
