Oracle中资源的共享与竞争及问题定位

核心提示： 上面的数据库操作开销的计算仅限于对时间消耗的计算,对同时使用同一数据库的其它应用软件的影响,对磁盘操作的频繁程度,数据库操作所采取的具体策略等等因素 , 都未考虑在内 , 高级语言也不可能提供这样的参考数据，而数据库本身提供的监测手段弥补了这一不足，Oracle中资源的共享与竞争及问题定位

上面的数据库操作开销的计算仅限于对时间消耗的计算,对同时使用同一数据库的其它应用软件的影响,对磁盘操作的频繁程度,数据库操作所采取的具体策略等等因素 , 都未考虑在内 , 高级语言也不可能提供这样的参考数据。而数据库本身提供的监测手段弥补了这一不足。最简单的操作控制台 :

sqlplus
SQL> set timing on

将为每次执行的数据库操作进行计时,精度为 1/100 秒 , 笔者对该功能的使用中发现其时间的计算也有一定的偏差。而且时间偏差很大,严格说来,已不属于误差的范围,该归错误了,下面是一个例子中得到的数据 :

[bash$] cat tmp.sql
set timing on
host date;
select count(*) from users;
host date;
SQL> @tmp.sql
Wed Dec 5 00:21:01 CST 2001
COUNT(*)
----------
1243807
Elapsed: 00:00:06.16
Wed Dec 5 00:21:05 CST 2001

从系统的时间差来看,为 4 秒左右 , 但 ORACLE 却报告了 6.16 秒 ! 如果说 ORACLE 工具在时间计算上太差强人意的话,在 SQL 语句的执行方案上可算是对 SQL 语句如何执行的最权威的诠释了。解读这样的信息需要对 ORACLE 内部对 SQL 操作的过程有一定了解,下面是该功能的一样典型示例 :

SQL> set autotrace on
SQL> select count(*) from users;
COUNT(*)
----------
1243807
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=4 Card=1)
1 0 SORT (AGGREGATE)
2 1 INDEX (FAST FULL SCAN) OF 'USER_BASEINFO$NAME' (UNIQUE)
(Cost=4 Card=1244840)
Statistics
0 recursive calls
4 db block gets
3032 consistent gets
3033 physical reads
0 redo size
370 bytes sent via SQL*Net to client
424 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed