在Oracle9i及之前,DBA们已经拥有了很多很好用的性能分析工具,比如,tkprof、sql_trace、statspack、set event 10046&10053等等。这些工具能够帮助DBA很快的定位性能问题。但这些工具都只给出一些统计数据,然后再由DBA们根据自己的经验进行优化。
那能不能由机器自动在统计数据的基础上给出优化建议呢?Oracle10g中就推出了新的优化诊断工具:数据库自动诊断监视工具(Automatic Database Diagnostic Monitor ADDM)和SQL优化建议工具(SQL Tuning Advisor STA)。这两个工具的结合使用,能使DBA节省大量优化时间,也大大减少了系统宕机的危险。简单点说,ADDM就是收集相关的统计数据到自动工作量知识库(Automatic Workload Repository AWR)中,而STA则根据这些数据,给出优化建议。例如,一个系统资源紧张,出现了明显的性能问题,由以往的办法,做个一个statspack快照,等30分钟,再做一次。查看报告,发现’ db file scattered read’事件在top 5 events里面。根据经验,这个事件一般可能是因为缺少索引、统计分析信息不够新、热表都放在一个数据文件上导致IO争用等原因引起的。根据这些经验,我们需要逐个来定位排除,比如查看语句的查询计划、查看user_tables的last_analysed子段,检查热块等等步骤来最后定位出原因,并给出优化建议。但是,有了STA以后,它就可以根据ADDM采集到的数据直接给出优化建议,甚至给出优化后的语句(抢了DBA的饭碗喽)。
ADDM能发现定位的问题包括:
· 操作系统内存页入页出问题
· 由于Oracle负载和非Oracle负载导致的CPU瓶颈问题
· 导致不同资源负载的Top SQL语句和对象——CPU消耗、IO带宽占用、潜在IO问题、RAC内部通讯繁忙
· 按照PLSQL和JAVA执行时间排的Top SQL语句.
· 过多地连接 (login/logoff).
· 过多硬解析问题——由于shared pool过小、书写问题、绑定大小不适应、解析失败原因引起的。
· 过多软解析问题
· 索引查询过多导致资源争用.
· 由于用户锁导致的过多的等待时间 (通过包dbms_lock加的锁)
· 由于DML锁导致的过多等待时间(例如锁住表了)
· 由于管道输出导致的过多等待时间(如通过包dbms_pipe.put进行管道输出)
· 由于并发更新同一个记录导致的过多等待时间(行级锁等待)
· 由于ITL不够导致的过多等待时间(大量的事务操作同一个数据块)
· 系统中过多的commit和rollback(logfile sync事件).
· 由于磁盘带宽太小和其他潜在问题(如由于logfile太小导致过多的checkpoint,MTTR设置问题,过多的undo操作等等)导致的IO性能问题I
· 对于DBWR进程写数据块,磁盘IO吞吐量不足
· 由于归档进程无法跟上redo日至产生的速度,导致系统变慢
· redo数据文件太小导致的问题
· 由于扩展磁盘分配导致的争用
· 由于移动一个对象的高水位导致的争用问题
· 内存太小问题——SGA Target, PGA, Buffer Cache, Shared Pool
· 在一个实例或者一个机群环境中存在频繁读写争用的热块
· 在一个实例或者一个机群环境中存在频繁读写争用的热对象
· RAC环境中内部通讯问题
· LMS进程无法跟上导致锁请求阻塞
· 在RAC环境中由于阻塞和争用导致的实例倾斜
· RMAN导致的IO和CPU问题
· Streams和AQ问题
· 资源管理等待事件
有一点要记住:AWR收集的数据时放到内存中(share pool),通过一个新的后台进程MMON定期写到磁盘中。所以10g的share pool要求比以前版本更大,一般推荐比以前大15-20%。另外,还要求系统参数STATISTICS_LEVEL设置为TYPICAL(推荐)或ALL;
ALTER SESSION SET STATISTICS_LEVEL= TYPICAL;Oracle10g提供了一个图形化的界面(通过OEM),使这个工具使用起来非常简单。下面这里介绍一下如何通过sqlplus使用这个工具。这个工具的使用非常简单,它是不需要安装的。
SQL> CREATE TABLE bigtab AS SELECT rownum as "id", a.* FROM dba_objects a; Table created.
SQL> create table smalltab as select rownum as "id", a.* FROM dba_tables a;
Table created.
SQL> ALTER TABLE bigtab MODIFY (empno NUMBER); Table altered.
SQL> DECLARE
2 n NUMBER;
3 BEGIN
4 FOR n IN 1..100
5 LOOP
6 INSERT INTO bigtab SELECT rownum as "id", a.* FROM dba_objects a;
7 COMMIT;
8 END LOOP;
9 END;/ PL/SQL procedure successfully completed.
SQL> begin 2 dbms_workload_repository.create_snapshot('TYPICAL'); 3 end; 4 / PL/SQL procedure successfully completed.DECLARE
v_var number;
BEGIN
FOR n IN 1..6
LOOP
select count(*) into v_var from bigtab b, smalltab a;
END LOOP;
END;
/
PL/SQL procedure successfully completed.
要注意的是:两次快照之间的间隔时间必须足够(一般推荐30分钟左右),否则得到的ADDM报告中就会提示:THERE WAS NOT ENOUGH DATABASE TIME FOR ADDM ANALYSIS.
SQL> begin 2 dbms_workload_repository.create_snapshot('TYPICAL'); 3 end; 4 / PL/SQL procedure successfully completed.先获取到两次快照的ID:
SQL> select snap_id from 2 (SELECT * FROM dba_hist_snapshot 3 ORDER BY snap_id desc) 4 where rownum <=2; SNAP_ID-------- 66 65然后创建优化任务,并执行。
DECLARE
task_name VARCHAR2(30) := 'DEMO_ADDM01';
task_desc VARCHAR2(30) := 'ADDM Feature Test';
task_id NUMBER;
BEGIN
dbms_advisor.create_task('ADDM', task_id, task_name, task_desc, null);
dbms_advisor.set_task_parameter(task_name, 'START_SNAPSHOT', 65);
dbms_advisor.set_task_parameter(task_name, 'END_SNAPSHOT', 66);
dbms_advisor.set_task_parameter(task_name, 'INSTANCE', 1);
dbms_advisor.set_task_parameter(task_name, 'DB_ID', 1712582900);
dbms_advisor.execute_task(task_name);
END;
/
PL/SQL procedure successfully completed.其中,set_task_parameter是用来设置任务参数的。START_SNAPSHOT是起始快照ID,END_SNAPSHOT是结束快照ID,INSTANCE是实例号,对于单实例,一般是1,在RAC环境下,可以通过查询视图v$instance得到,DB_ID是数据库的唯一识别号,可以通过查询v$database查到。
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/9650775/viewspace-920373/ ,如需转载,请注明出处,否则将追究法律责任。