定制脚本 runstats

runstats
runstats 是开发的一个工具，能对做同一件事的两个不同方法进行比较，得出孰优孰劣的结果。
你只需提供两个不同的方法，余下的事情都由runstats 负责。runstats 只是测量3 个要素：
 墙上时钟（wall clock）或耗用时间（elapsed time）：知道墙上时钟或耗用时间很有用，不过这
不是最重要的信息。
 系统统计结果：会并排显示每个方法做某件事（如执行一个解析调用）的次数，并展示二者之差。
 闩定（latching）：这是这个报告的关键输出。
你在本书中会了解到，闩（latch）是一种轻量级的锁。锁（lock）是一种串行化设备，而串行化设
备不支持并发。如果应用不支持并发，可扩缩性就比较差，只能支持较少的用户，而且需要更多的资源。
构建应用时，我们往往希望应用能很好地扩缩，也就是说，为1 位用户服务与为1,000 或10,000 位用户服
务应该是一样的。应用中使用的闩越少，性能就越好。如果一种方法从墙上时钟来看运行时间较长，但是
只使用了另一种方法10%的闩，我可能会选择前者。因为我知道，与使用更多闩的方法相比，使用较少闩
的方法能更好地扩缩。
runstats 最后独立使用，也就是说，最好在一个单用户数据库上运行。我们会测量各个方法的统计
结果和闩定（锁定）活动。runstats 在运行过程中，不希望其他任务对系统的负载或闩产生影响。只需一
个小的测试数据库就能很好地完成这些测试。例如，我就经常使用我的台式机或手提电脑进行测试。
注意我相信所有开发人员都应该有一个自行控制的试验台（test bed）数据库，可以在它上面尝试
自己的想法，而不必要求DBA 参与。假定数据库的个人开发版本称“如果数据库用来开发和测试，
但不进行部署，那你可以放心使用”。只要有此许可，开发人员都应该在自己的台式机上建立一个
数据库。这样你就不会漏掉任何细节！另外，我在会议和讲座上做过一些非正式的调查，发现几
乎每个DBA 都是从开发人员做起的。通过控制自己的数据库，开发人员能积累丰富的经验并得到
最好的培训，能够了解数据库到底是怎样工作的，从长远来看这绝对是一笔不小的财富。
要使用runstats，需要能访问几个V$视图，并创建一个表来存储统计结果，还要创建runstats 包。
为此，需要访问3 个V$表（就是那些神奇的动态性能表）：V$STATNAME、V$MYSTAT 和V$LATCH。以下是我
使用的视图：
create or replace view stats
as select 'STAT...' || a.name name, b.value
from v$statname a, v$mystat b
where a.statistic# = b.statistic#
union all

select 'LATCH.' || name, gets
from v$latch;

 

如果你能得到V$STATNAME、V$MYSTAT、V$LATCH 和V$TIMER 的直接授权，就能直接对这些表执行SELECT
操作（相应地可以自行创建视图）；否则，可以由其他人对这些表执行SELECT 操作为你创建视图，并授予
你在这个视图上执行SELECT 的权限。
一旦建立视图，接下来只需要一个小表来收集统计结果：

create global temporary table run_stats
( runid varchar2(15),
name varchar2(80),
value int )
on commit preserve rows;
最后，需要创建runstats 包。其中包含3 个简单的API 调用：
 runstats 测试开始时调用RS_STAT（runstats 开始）。
 正如你想象的，RS_MIDDLE 会在测试之间调用。
 完成时调用RS_STOP，打印报告。
创建runstats 包的规范如下：

create or replace package runstats_pkg
 as
 procedure rs_start;
 procedure rs_middle;
 procedure rs_stop( p_difference_threshold in number default 0 );
 end;
Package created.
参数P_DIFFERENCE_THRESHOLD 用于控制最后打印的数据量。runstats 会收集并得到每次运行的统计
结果和闩信息，然后打印一个报告，说明每次测试（每个方法）使用了多少资源，以及不同测试（不同方
法）的结果之差。可以使用这个输入参数来控制只查看差值大于这个数的统计结果和闩信息。由于这个参
数默认为0，所以默认情况下可以看到所有输出。