Oracle实用技巧

　　1.找出无用索引:

　　DML 性能低下，其中最严重的原因之一是无用索引的存在。所有SQL的插入，更新和删除操作在它们需要在每一行数据被改变时修改大量索引的时候会变得更慢。许多Oracle 管理人员只要看见在一个SQL 查询的WHERE语句出现了一列的话就会为它分配索引。虽然这个方法能够让SQL运行得更快速，但是基于功能的Oracle 索引使得数据库管理人员有可能在数据表的行上过度分配索引。过度分配索引会严重影响关键Oracle 数据表的性能。

　　在Oracle9i出现以前，没有办法确定SQL查询没有使用的索引。Oracle9i有一个工具能够让你使用ALTER INDEX命令监视索引的使用。然后你可以查找这些没有使用的索引并从数据库里删除它们。

　　下面是一段脚本，它能够打开一个系统中所有索引的监视功能:

　　spool run_monitor.sql

　　select 'alter index '||owner||'.'||index_name||' monitoring usage;'

　　from dba_indexes

　　where owner not in ('SYS','SYSTEM');

　　spool off;

　　@run_monitor

　　你需要等待一段时间直到在数据库上运行了足够多的SQL语句以后，然后你就可以查询新的V$OBJECT_USAGE视图。

　　select index_name,table_name,mon,used

　　from v$object_usage;

　　在下面，我们可以看见V$OBJECT_USAGE有一列被称作USED，它的值是YES或者NO。它不会告诉你Oracle使用了这个索引多少次，但是这个工具对于找出没有使用的索引还是很有用的。

　　SQL> select * from v$object_usage where rownum < 10;

　　INDEX_NAME TABLE_NAME MONITORING USED START_MONITORING END_MONITORING

　　------------------------------ ------------------------------ ---------- ---- ------------------- -------------------

　　ASD DIM_ACCT_ITEM_TYPE_TEMP YES NO 01/15/2004 13:50:59

　　IDX_ACCOUNT_ACCESSORY_TARIFF1 ACCOUNT_ACCESSORY_TARIFF YES NO 01/15/2004 13:50:59

　　IDX_ACCOUNT_QUOTA_LOG1 ACCOUNT_QUOTA_LOG YES NO 01/15/2004 13:50:59

　　IDX_ACCOUNT_SYSTEM_PARAMETERS1 ACCOUNT_SYSTEM_PARAMETERS YES NO 01/15/2004 13:50:59

　　IDX_ACCT2 ACCT YES NO 01/15/2004 13:50:59

　　IDX_ACCT3 ACCT YES NO 01/15/2004 13:51:00

　　IDX_ACCT4 ACCT YES NO 01/15/2004 13:51:00

　　IDX_ACCT_BIND_DISCT1 ACCT_BIND_DISCT YES NO 01/15/2004 13:51:00

　　IDX_ACCT_BIND_DISCT2 ACCT_BIND_DISCT YES NO 01/15/2004 13:51:00

　　2.查看一个很长的操作已经做了多少:

　　v$session_longops视图可以使Oracle专家减少运行时间很长的DDL和DML语句的运行时间。例如在数据仓库环境中，即使使用并行索引创建技术，构建一个很多G字节大的索引需要耗费很多个小时。这里你就可以查询v$session_longops视图快速找出一个特定的DDL语句已经完成了多少。其实v$session_longops视图也可以用于任何运行时间很长的操作，包括运行时间很长的更新操作。

　　下面的脚本将显示一个状态信息，说明了运行时间很长的DDL操作已经使用的时间。注意你必须从v$session中取得SID并将其插入到下面的SQL语句中:

　　select sid,start_time,elapsed_seconds,message

　　from v$session_longops

　　where sid = 13

　　order by start_time;

　　这里是一个输出的例子，显示了运行时间很长的CREATE INDEX语句的运行过程。

　　SID MESSAGE

　　--- ---------------------------------------------------------------

　　11 Table Scan: CUST.PK_IDX: 732 out of 243260 Blocks done