'Performance tuning' Tag

• Access and Filter Predicates

  10月 28, 2009

  关于执行计划中的谓词信息（access and filter）的文章链接： SQL Tuning Improvements in Oracle 9.2 Access vs Filter Predicates - Webinar 对于查看共享池中的执行计划，有SQL_ID最好，没有可以先执行，然后去v$sql中查找该语句的sql_id: select sql_id,child_number,sql_text from v$sql where sql_text like '%xxx%'; 然后根据获取好的sql_id和child_number通过dbms_xplan包来读取： select * from table(dbms_xplan.display_cursor('sql_id',child_number)); 这样就可以查出SQL的执行计划，也是更准确，在共享池中缓存的SQL PLAN。

  posted in Oracle 知识杂记 by | 编辑

• 直方图和BIND PEEKING

  10月 24, 2009

  一、直方图和BIND PEEKING 1、创建一个列上数据有倾斜的表 SQL> create table t1 (value number ,flag number,pad varchar2(2000)); 表已创建。 SQL> insert into t1 select rownum,mod(rownum,2000),lpad('x',1000,'x') from dba_objects; 已创建50465行。 SQL> commit; 提交完成。 SQL> insert into t1 select rownum,3000,lpad('x',1000,'x') from dba_objects where rownum< =10000; 已创建10000行。 SQL> commit; 提交完成。 SQL> create index t1_idx on t1(flag); 索引已创建。 SQL> exec dbms_stats.gather_table_stats(ownname=>user,tabname=>'T1',cascade=>true,method_opt=>'for all indexed columns'); PL/SQL 过程已成功完成。 [...]

  posted in Oracle 知识杂记 by | 编辑

• COMMIT的开销

  10月 9, 2009

          如果能够只在必要的时候进行提交（即逻辑工作单元结束时），不仅能够提高性能，还能减少对共享资源的竞争（日志文件、各种内部的闩等）。 commit的开销存在两个因素：         （1）会增加与数据库的往返通信。如果每个记录都提交，生成的往返通信量就会大得多。         （2）每次提交时，必须等待redo写至磁盘。这个会导致“等待”（log file sync）。         另外，不管事务的大小，commit的响应时间一般都很“平”。如果1行的commit要X时间单位，1000行的commit也同样需要X时间单位，但是，每行提交一次共执行1000次commit，就会需要1000*X个时间单位才能完成。

  posted in Oracle 知识杂记 by | 编辑