前导发端：网海拾贝
运用扩展 SQL 跟踪数据来了解是什么在花费这么长的时辰。
要是有一天你开车去上班，但末了仍是没能及时列入一个重要会议。你无法将你的革命性的想法出现给客户，所以他们也不会回收。你的拖拖沓拉使你感到懊丧，你赌咒决不再犯异样的错误。那么，为了不再产生发火相通环境，你怎样判别成绩的缘由呢？凭据上面这个列表截至搜寻怎样样？
搜寻汽车内里能否有缺陷，由于内里有缺陷会使汽车的最高速率低落 1% 或更多。
搜寻车轮定位，由于外倾角、后倾角或前束角不相宜城市招致汽车的垄断不活络并且花费时辰。
搜寻提议机，以确保达到额定马力的 99% 或更高。要是不是这样，则要考虑重装或更换提议机。
不，你可以或许不会回收这种搜寻究法；那样太好笑了。你可以或许会以完全差别的设施来判别成绩之所在，可以或许只是问你自己一个简朴的成绩：什么事故让我花了这么长时辰？
从这个角度开航，成绩就迎刃而解了。要是开车需求 40 分钟，而你在会议起头前 20 分钟才开航，那么下次就要延迟 30 分钟开航。要是由于交通拥堵浪费了 20 分钟，那么，下重要么再早一些开航，换条门路，要么更仔细地查察早 7 点的路况通知。要是是你迷了路，下场浪费了 20 分钟去兜圈子，那么下次你大体就要事前看看地图。如斯等等。
我感到别致的是，那些善于料理一样寻常服从优化成绩的数据库专业职员在任务中却运用完全差别的设施来料理数据库服从成绩。许大都据库 " 调优职员 " 从来不问， " 是什么让这个法度运转了这么长时辰？ " 相反，他们会参考搜寻内容清单，并试图避免错误产生发火：
搜寻通通 Oracle 块乞求能否都由数据库缓存供应效力
搜寻能否有全表扫描
搜寻通通排序能否都在内存中截至
搜寻重做日志能否与其他通通数据库文件截至了恰当的隔离
等等。
关于某些任务来说，运用搜寻内容清单或许很好。可是关于判别服从成绩这样的任务，试图确定实践上可以或许会出错的每一件事，从而对这个成绩截至措置的做法的效用会很低。更有效的设施便是找到这个简朴成绩的答案：
是什么花了这么长时辰？
用于优化 Oracle 法度的好的计谋就如统一样寻常生活生计顶用到的计谋。就像这样：
• 运用专门的仪器来测定法度的服从，从而看守运转速率慢的法度。
• 为运转慢的法度设立扶植资本描绘，把法度的呼适时辰细分为几种有效的类型。
• 经过议定起首措置呼适时辰最长的部分来收缩法度的呼适时辰。
当你了解了几许手艺细节之后，这个设施就很是简朴了。要是你真的这样做，那么每次你都能得到一个有效的设施，一朝一夕，你将能在截至服从改进之前预知其下场。
跟踪
要是你有效于搜集法度中每个执行步调的时辰统计信息的初级器械，那就用吧。但只搜集汇总数据（如经过议定对体系全局区 [SGA] 或其根蒂共享存储段采样得到的数据）的器械关于某些类型的成绩就不恰当。
运用昂贵的监控器械时最罕有的汇总错误是它们会跨整个 Oracle 数据库实例来汇总某一给准时距离绝内资本的运用环境。可是，运转速率慢的法度幻想上可以或许不受资本争用成绩的影响，而这个成绩却完全节制着体系中一些不太重要的法度的服从。
即使是那些在 Oracle 数据库会话级上汇总信息的器械在诊断一些重要的成绩类型时也存在着缺陷。例如，假定一个法度运转 10 分钟，挪用了 10000 次 Oracle SQL*Net message from client 这一 " 等候事故 " ，会话等候该事故的总用时为 8.3 分钟。这意味着会话对 SQL*Net message from client 事故的等候时辰平均为 3 秒。可是单从汇总数据看，你无法知道这 10000 次挪用能否每次都用 3 秒，仍是这些挪用中或许有一个用了 5 分钟，而其他 9999 次挪用每次只用 0.02 秒。这两种环境需求截至完全差别的措置。
在这种环境下最能为你供应辅佐的诊断数据是 Oracle 的扩展 SQL 跟踪数据。扩展 SQL 跟踪文件定时辰次序递次浮现了 Oracle 数据库内核在指准时辰内所完成任务的逐条记录。搜集扩展 SQL 跟踪数据的确是收费的。最大的花销是存储每一个需求惹起注意的跟踪文件所需磁盘空间（很少跨越几兆字节）的费用。
跟踪自己的代码。要是能访问法度的源代码，则翻开其扩展 SQL 跟踪就很是随意。起首必须确保会话的 TIMED_STATISTICS 和 MAX_DUMP_ FILE_SIZE 参数设置切确：
alter session
set timed_statistics=true
alter session
set max_dump_file_size=unlimited
要是没有设置 TIMED_STATISTICS=TRUE ，则数据库内核将把 0 值而不是真正的接连时辰发送到跟踪文件中。要是对 MAX_DUMP_ FILE_SIZE 严加限制，则会在跟踪文件中天生上面这样的动态，而不是你想要的时辰数据：
奸淫 DUMP FILE SIZE IS LIMITED TO 1048576 BYTES 奸淫
接上去是激活跟踪。有几种设施可以回收。曩昔的设施是运用 ALTER SESSION 号令，如下所示：
alter session set events
'10046 trace name context forever, level 12'
/* code to be traced goes here */
alter session set events
'10046 trace name context off'
更好的设施是运用 DBMS_SUPPORT 包来激活扩展 SQL 跟踪：
dbms_support.start_trace(waits=>true, binds=>true)
/* code to be traced goes here */
dbms_support.stop_trace()
请注意 DBMS_SUPPORT 没有文档阐明');，可以或许也不是数据库默许安装的一部分。要了解 DBMS_SUPPORT 的信息，请参考 MetaLink ( metalink.oracle.com ) 。
跟踪别人的代码。
要是你想跟踪没有读 / 写权限的代码，则激活扩展 SQL 跟踪就有点贫苦了。但也不会难许多。你起首要得到你想跟踪的会话的 V$SESSION.SID 和 V$SESSION.SERIAL# 值。然后运用上面的历程挪用，可以设置所选会话的 TIMED_STATISTICS 和 MAX_DUMP_FILE_SIZE 参数：
dbms_system.set_bool_param_in_session(
sid => 42,
serial# => 1215,
parnam => 'timed_statistics',
bval => true)
dbms_system.set_int_param_in_session(
sid => 42,
serial# => 1215,
parnam => 'max_dump_file_size',
intval => 2147483647)
（关于 Oracle8 8.1.6 早年的版本，你可以用 ALTER SYSTEM 号令措置这些参数。）
接上去要激活跟踪。有几种设施可以回收，包罗上面两个：
设施一是运用 DBMS_SUPPORT ：
dbms_support.start_trace_in_session(
sid => 42,
serial# => 1215,
waits => true,
binds => true)
/* code to be traced executes during this time window */
dbms_support.stop_trace_in_session(
sid => 42,
serial => 1215)
若想激活扩展 SQL 跟踪，请不要运用名为 SET_SQL_TRACE_IN_SESSION 的 DBMS_SUPPORT 历程。该历程不许可在跟踪文件中指定等候和绑定的数据。
第二种设施更为大雅，但在 Oracle 数据库 10g 之前的版本中并不支撑这种设施。 DBMS_MONITOR 包的引入料理了许多庞大诊断数据搜集成绩，这些成绩是由连接共享和多线程垄断所惹起的。你可以在 Oracle 数据库 10g 中指定要跟踪的效力、模块或设施，而不指定要跟踪的 Oracle 数据库会话：
dbms_monitor.serv_mod_act_trace_enable(
service_name => 'APPS1',
module_name => 'PAYROLL',
action_name => 'PYUGEN',
waits => true,
binds => true,
instance_name => null)
/* code to be traced executes during this time window */
dbms_monitor.serv_mod_act_trace_disable(
service_name => 'APPS1',
module_name => 'PAYROLL',
action_name => 'PYUGEN')
运用 DBMS_MONITOR 包， Oracle 可为要跟踪的特定的营业垄断供应完全支撑激活或中止诊断数据搜集的设施。
测试扩展 SQL 跟踪。试一试吧。查察第一个跟踪文件只需运用一个简朴的 SQL*Plus 会话，就仿佛上面这样：
alter session
set timed_statistics=true;
alter session
set max_dump_file_size=unlimited;
alter session
set tracefile_identifier='Hello';
/* only in Oracle Database 8.1.7
and later */
alter session
set events '10046 trace name context forever, level 12';
select 'Howdy, it is '||sysdate from dual;
exit;
然后在由 USER_DUMP_DEST 实例参数的值命名的目次中寻觅文件名中包罗字符串 "Hello" 的最新写入的 .trc 文件。用你最喜爱的文本编纂器翻开它。 阅读 Oracle MetaLink 注释 39817.1 或（ Optimizing Oracle Performance ，《优化 Oracle 服从》）一书，以便大体了解原始跟踪文件中有些什么。必然要运转跟踪文件上的 tkprof ，并钻研其输出，但也不要由于有了 tkprof 就不再看原始的跟踪文件。跟踪文件中另有许多 tkprof 没有向你展现的内容。
要是你不但需求一个由简朴的 SELECT from DUAL 天生的跟踪文件，还需求一个更感兴趣的跟踪文件，那么需求跟踪上面这条 SQL 语句：
select object_type, owner, object_name from dba_objects;
由此得到的跟踪数据会让你感到很得意，由于 Oracle 数据库内核替你完成了惊人的任务量。
设立扶植资本描绘
有了切确而具体的诊断数据之后，你需求以摘要的情势对其截至查察，这有助于你以最快的速率做出照应。至少是从 20 世纪 70 年月起头，计算机法度员运用的摘要款式便是资本描绘。资本描绘只是一张表，它将所用时辰阐明为几许有效的子集，并按各子集所用时辰降序摆列。上面是一个资本描绘的例子：
Response Time Component Duration
-------------------------- ----------
Freeway at <50% speed limit 28.3m 59%
Finding a parking spot 7.2m 15%
Waiting at traffic lights 5.2m 11%
Freeway at ≥50% speed limit 4.0m 8%
Other 3.1m 6%
-------------------------- ----------
Total 47.8m 100%
这个资本描陈阐明');买一辆速率更快的车不会使你可以更快地抵达任务地址。
要从跟踪文件设立扶植资本描绘，有两种设施可以回收。
自己下手。《 Optimizing Oracle Performance 》一书中有所阐明');。
运用别人的器械。 Oracle 的 tkprof 和 trcanalyzer （跟踪阐明器）器械可为你完成一部分任务，但不是通通。
对数据做出照应
有了具体的诊断数据及其要点，就要决定对所看到的器械若何做出照应。对资本描绘做出照应的履历做法很是牢靠且相等简朴：起首增加破耗时辰最长的部分，设施是增加挪用它的次数。
这种设施的确总是切确的。了解理会增加给定组件的挪用次数的设施，需求对差别等候事故称呼的含义有所了解。例如，当被跟踪的 Oracle 会话等候 "buffer busy waits" 这个等候事故时，该会话会向跟踪文件发送会天生足够多的信息，并显匡正在等候哪一个缓冲区以及为什么要等候。当一个会话等候 SQL*Net message from client 事故时，跟踪文件中天生的数据的位置会通知你执行过的数据库挪用哪个是多余的。
在 Oracle9i 第 2 版中，有 350 多个差别的等候事故。在 Oracle 数据库 10g 中，的确有 700 个等候事故。但不消担忧：你根蒂不消知道它们都是什么意思。你只需知道你的重要法度破耗大部分时辰所等候的那些事故是什么意思。
看看你能做些什么
有了相宜的诊断数据，你就能敏捷料理相应的成绩，或许证明这些成绩不值得料理。
上面给出诊断数据可以料理的一部分成绩清单：
整个体系的成绩以及一样寻常用户（营业）垄断的具体成绩
查问错误，包罗写得欠好的 SQL 语句、有成绩的索引以及数据密度成绩
A 使用法度错误，包罗阐明过度、不运用数组运算等等在内的使用法度
串行化错误，包罗不消要的频仍产生发火或费时的锁定、锁存或存储缓冲区举动
搜集错误，如选择的协议不妥、搜集装备有成绩
磁盘输出 / 输出错误，如高速缓存大小不恰当、负载不服衡以及扶植不妥
容量缺乏，如交换、分页和 CPU 占用过多
运用 Oracle 的扩展 SQL 跟踪数据以及提出 " 什么如斯费时？ " 这种成绩的设施能带来的最好下场是在起头诊断和料理成绩之前你将不消再推想服从成绩会是什么。
Cary Millsap ( cary.millsap@hotsos.com ) 是 Optimizing Oracle Performance （ O'Reilly & Associates 公司出书， 2003 ）一书的作者（与 Jeff Holt 共同编写）。 Cary 与别人共同兴办了 Hotsos 公司（ hotsos.com ），这是一家贩卖产品、供应教育和征询效力的公司，去世力于提高 Oracle 的服从。
版权声明： 原创作品，许可转载，转载时请务必以超链接情势标明文章 原始来由 、作者信息和本声明。否则将深究轨则责任。