===========================================================
常见的wait等待事件及处理(zt)
===========================================================
常见的wait等待事件及处理 查看全文
===========================================================
一个简单的sql优化例子
===========================================================
今天网友liosun问到虚拟索引，想起以前给SDE优化的一个例子涉及到，顺便贴出优化的一个简单过程（摘自办公邮件）： 查看全文
===========================================================
ORACLE诊断案例
===========================================================
一个小问题的诊断： 查看全文
===========================================================
Oracle Tuning的一些总结2(zt)
===========================================================
===========================================================
Oracle Tuning的一些总结1(zt)
===========================================================
关于Oracle的性能调整，一般包括两个方面，一是指Oracle数据库本身的调整，比如SGA、PGA的优化设置，二是连接Oracle的应用程序以及SQL语句的优化。做好这两个方面的优化，就可以使一套完整的Oracle应用系统处于良好的运行状态。
本文主要是把一些Oracle Tuning的文章作了一个简单的总结，力求以实际可操作为目的，配合讲解部分理论知识，使大部分具有一般Oracle知识的使用者能够对Oracle Tuning有所了解，并且能够根据实际情况对某些参数进行调整。关于更加详细的知识，请参见本文结束部分所提及的推荐书籍，同时由于该话题内容太多且复杂，本文必定有失之偏颇甚至错误的地方，请不吝赐教，并共同进步。 查看全文
本文主要是把一些Oracle Tuning的文章作了一个简单的总结，力求以实际可操作为目的，配合讲解部分理论知识，使大部分具有一般Oracle知识的使用者能够对Oracle Tuning有所了解，并且能够根据实际情况对某些参数进行调整。关于更加详细的知识，请参见本文结束部分所提及的推荐书籍，同时由于该话题内容太多且复杂，本文必定有失之偏颇甚至错误的地方，请不吝赐教，并共同进步。 查看全文
===========================================================
ALTER SYSTEM FLUSH BUFFER_POOL
===========================================================
在Oracle9i里，Oracle提供了一个内部事件，用以强制刷新Buffer Cache，其语法为:
alter session set events 'immediate trace name flush_cache level 1';
或者:
alter session set events = 'immediate trace name flush_cache';
类似的也可以使用alter system系统级设置:
alter system set events = 'immediate trace name flush_cache';
在Oracle10g中，Oracle提供一个新的特性，可以通过如下命令刷新Buffer Cache:
alter system flush buffer_cache;
alter session set events 'immediate trace name flush_cache level 1';
或者:
alter session set events = 'immediate trace name flush_cache';
类似的也可以使用alter system系统级设置:
alter system set events = 'immediate trace name flush_cache';
在Oracle10g中，Oracle提供一个新的特性，可以通过如下命令刷新Buffer Cache:
alter system flush buffer_cache;
===========================================================
tkprof格式化后的trace文件(转)
===========================================================
10046诊断事件和tkprof工具是SQL优化中必不可少的工具，对于新手来说，如何读懂格式化以后的trace文件是一个首先要过的门槛。本文来自metalink上的一篇文档 查看全文
===========================================================
软解析、硬解析的一个小测试
===========================================================
看到这个帖子http://www.itpub.net/744933.html 的提问，做两个简单测试，由于近期较忙，文中解释内容比较少，希望抛砖引玉，
大家讨论。
===========================================================
buffer busy wait 等待事件说明(转)
===========================================================
当会话想要访问缓冲存储器中的数据块，而该数据块正在被其它会话使用时产生buffer busy
waits事件。其它会话可能正在从数据文件向缓冲区存储器度曲同样的数据块，或正在缓冲存储器
中对其进行修改。
为了确保读取器会话拥有与获得所有更改或无更改的数据块一致的映像，正在修改该数据块
的会话在其标题中标记一个标志，让其他会话知道有一个更改正在进行而等候更改的的完成。
视图v$waitstat不是OWI的组件，但其为没一类缓冲区提供了有用的等待统计。遭遇buffer
busy等待事件最常见的缓冲区类为块、段标题、撤消块、撤消标题。 查看全文
===========================================================
Oracle中表的连接及其调整(转)
===========================================================
在日常基于数据库应用的开发过程中，我们经常需要对多个表或者数据源进行关联查询而得出我们需要的结果集。那么Oracle到底存在着哪几种连接方式？优化器内部又是怎样处理这些连接的？哪种连接方式又是适合哪种查询需求的？只有对这些问题有了清晰的理解后，我们才能针对特定的查询需求选择合适的连接方式，开发出健壮的数据库应用程序。选择合适的表连接方法对SQL语句运行的性能有着至关重要的影响。下面我们就Oracle常用的一些连接方法及适用情景做一个简单的介绍。 查看全文
===========================================================
Statspack分析报告详解(转)
===========================================================
调整STATSPACK 的收集门限
Statspack 有两种类型的收集选项：
级别（level）：控制收集数据的类型
门限（threshold）：设置收集的数据的阈值。
1．级别（level）
Statspack 共有三种快照级别，默认值是5
a.level 0: 一般性能统计。包括等待事件、系统事件、系统统计、回滚段统计、行缓存、SGA、会话、
锁、缓冲池统计等等。
b.level 5: 增加SQL 语句。除了包括level0 的所有内容，还包括SQL 语句的收集，收集结果记录在
stats$sql_summary 中。
c.level 10: 增加子锁存统计。包括level5 的所有内容。并且还会将附加的子锁存存入
stats$lathc_children 中。在使用这个级别时需要慎重，建议在Oracle support 的指导下进行。
可以通过statspack 包修改缺省的级别设置
SQL>execute statspack.snap(i_snap_level=>0,i_modify_parameter=>’true’);
通过这样的设置，以后的收集级别都将是0 级。
如果你只是想本次改变收集级别，可以忽略i_modify_parameter 参数。
SQL>execute statspack.snap(i_snap_level=>10);
2．快照门限
快照门限只应用于stats$sql_summary 表中获取的SQL 语句。
因为每一个快照都会收集很多数据，每一行都代表获取快照时数据库中的一个SQL 语句，所以
stats$sql_summary 很快就会成为Statspack 中最大的表。
门限存储在stats$statspack_parameter 表中。让我们了结一下各种门限：
a. executions_th 这是SQL 语句执行的数量(默认值是100)
b. disk_reads_tn 这是SQL 语句执行的磁盘读入数量（默认值是1000）
c. parse_calls_th 这是SQL 语句执行的解析调用的数量（默认值是1000）
d. buffer_gets_th 这是SQL 语句执行的缓冲区获取的数量（默认值是10000）
任何一个门限值超过以上参数就会产生一条记录。
通过调用statspack.modify_statspack_parameter 函数我们可以改变门限的默认值。
例如：
SQL>execute statspack.modify_statspack_parameter(i_buffer_gets_th=>100000,i_disk_reads_th=>100000;
Statspack分析报告详解：
statspack 输出结果中必须查看的十项内容
1、负载间档(Load profile)
2、实例效率点击率(Instance efficiency hit ratios)
3、首要的5个等待事件(Top 5 wait events)
4、等待事件(Wait events)
5、闩锁等待
6、首要的SQL(Top sql)
7、实例活动(Instance activity)
8、文件I/O(File I/O)
9、内存分配(Memory allocation)
10、缓冲区等待(Buffer waits
===========================================================
statspack report分析(转)
===========================================================
一、statspack 输出结果中必须查看的十项内容
1、负载间档(Load profile)
2、实例效率点击率(Instance efficiency hit ratios)
3、首要的5个等待事件(Top 5 wait events)
4、等待事件(Wait events)
5、闩锁等待
6、首要的SQL(Top sql)
7、实例活动(Instance activity)
8、文件I/O(File I/O)
9、内存分配(Memory allocation)
10、缓冲区等待(Buffer waits)
===========================================================
orcle性能调整(转)
===========================================================
数据库的等待事件，发现前几名是：
log file parallel write
db file scattered read
log file sync
db file sequential read
SQL*Net more data to client
发现前面的4项都是影响到数据库性能的问题：
log file sync：
这个等待时间是指等待oracle的前台的commit和rollback操作进程完成，有时候这个等待时间也会包括等待LGWR进程把一个会话事务的日志记录信息从日志缓冲区中写到磁盘上的重做日志文件中。因此当前台进程在等待这个事件的时候，LGWR进程同时也在等待事件log file parallel write。
理解什么造成这个等待事件的关键在于：对比这个等待事件和log file parallel write等待事件的平均等待时间：
l 如果他们的等待时间差不多，那么就是重做日志文件的I/O引起了这个等待事件，则需要调整重做日志文件的I/O，
l 如果log file parallel write等待事件的平均等待时间明显小于log file sync等待事件的等待时间，那么就是一些其他写日志的机制在commit和rollback操作时引起的等待，而不是I/O引起的等待。例如重做日志文件的latch竞争，会伴随出现latch free或者LGWR wait for redo copy等待事件
在V$SESSION_WAIT中，这个等待事件有3个参数：
P1 | 代表在日志缓冲区中需要被写入到重做日志文件中的缓存数量，写入的同时会确认事务是否已经被提交，并且保留提交信息到实例意外中断前，因此必须等待LGWR将P1数量的缓存写入重做日志文件为止。 |
P2 | 无用 |
P3 | 无用 |
如果这个等待事件在整个等待事件中占了比较大的比重，可以从3个方面来进行调整
1. 调整LGWR进程时期具有更好的磁盘I/O吞吐量，例如不要将日志文件放在RAID5的磁盘上
2. 如果存在很多执行时间很短的事务，可以考虑将这些事务合并成一个批量事务以减少提交的次数，因为每次提交都需要确认相关的日志写入重做日志文件，因此使用批量事务来减少提交的次数是一种非常行之有效的减少I/O的方法
3. 产看是否有一些操作可以安全的使用NOLOGGING或者UNRECOVERABLE选项，这样可以减少日志文件的产生
Log file parallel write
这个等待事件出现在党LGWR后台进程从日志缓冲区写日志信息到磁盘上的重做日志文件的时候。只有启用了异步I/O的时候，LGWR进程才会并行写当前日志组内的充作日志文件，否则LGWR指挥循环顺序逐个的写当前日志组重做日志文件。LGWR进程不得不等待当前日志组所有的重做日志文件成员全部写完，因此，决定这个等待事件的等待时间长短的主要因素是重做日志文件所在磁盘的I/O读写速度。
如果是当前LGWR进程写的速度不够快导致这个等待事件，可以通过查看一些和重做日志相关的统计值来判定当前的LGWR进程是否效率低下，具体的可以看 redo writes, redo blocks written, redo write time, rdo wastage, redo size等统计值，这些都是和LGWR进程性能直接相关的一些统计值。
在V$SESSION_WAIT中，这个等待事件的3个参数：
P1 | 代表正在被写入的重做日志文件组中的重做日志文件号 |
P2 | 代表需要写入重做日志组中每个重做日志文件的重做日志block数量 |
P3 | 代表I/O请求次数，需要被写入的block会被分成多次分别请求 |
如果这个等待事件占用比较多的时间，可以做如下调整
1． 采用UNRECOVERABLE/NOLOGGING操作尽量减少重做日志的产生
2． 在保证不会同时对市重做日志文件的前提下，尽量减少重做日志组中的成员个数，减少每次写重做日志文件的时间
3． 除非在备份情况下，否则不要在江表空间置于热备份的模式下，因为在表空间处于热备的模式下会产生更多的重做日志文件
4． 对于使用LogMiner、Logical Standby或者Streams，在能够满足要求功能的前提下，尽量使用最低级别的追加日志以减少重做日志的产生
5． 尽量将同一个日志组内的重做日志文件分散到不同的硬盘上，减少并行写重做日志文件时产生的I/O竞争
6． 不要将重做日志文件置于RAID5的磁盘上，最好放在裸设备上。
7． 如果设置了归档模式，不要将归档日志的目的地设置为存放重做日志的磁盘上，避免引起I/O竞争
关于Log的这2个问题的总结
通过上述对Log这2个问题的描述，以及产生的原因，除了Log file sync可能有其他方面的因素引起的（Latch），主要还是磁盘和使用习惯
1． 磁盘由于这些都是写磁盘所引起的，所以只有从减少写磁盘（指数据库本身的角度，和下列提到的用户操作习惯不一样）和加快写磁盘来减少这些等待时间
a) 尽量不要在RAID5的磁盘上保存重做日志文件，RAID5写的速度属于比较慢的
b) 在安全性保证的基础上，减少重做日志组成员的个数
c) 同一个日志组中的不同成员放在不同的磁盘上，加速写的速度。
d) 对可以采用NOLOGGING/UNRECOVERABLE的操作，使用这些选项减少log的产生
e) 有归档的，不要将归档的和在线重做日志放在一个磁盘上
2． 使用习惯如果用户不断的进行commit或者rollback，这样必定引起一次log日志的写操作。因此可以通过一些统计信息判断是否每次的日志的写操作数据量很小，这样通过调节用户的操作，将大量的数据更新合并到一个事务中来，这样增加每次日志的操作量，减少对日志的不断调用，提高LGWR的写的效率。
db file scattered read
这是一个非常常见的等待时间。当oracle从磁盘上读取多个block到不连续的高速缓存区的缓存中就会发生这个等待事件，Oracle一次最多能够读入的block数量由初始化参数DB_FILE_MULTIBLOCK_READ_COUND决定，这个时间一般伴随着全表扫描或者Fast Full Index 扫描一起出现。
在V$SESSION_WAIT中，这个等待事件的几个参数：
P1 | 代表oracle的文件号 |
P2 | 代表从这个文件中开始读取的block号 |
P3 | 代表从这个block开始需要读取的block数量 |
一般从这个3个参数，就可以回头查询到是在读取数据库的哪个对象，然后分析对这个对象的操作来进行优化Sql语句。
如果这个等待事件占的比重比较厉害，可以通过以下方法来调整
方法一
找出执行全表扫描或者Fast Full index扫描的Sql语句，判断这些扫描是否是必要的，是否导致了比较差的执行计划，进行调整。
从oracle9i开始，提供了一个视图V$SQL_PLAN，可以通过它帮助我们找到那些全表扫描或者Fast Full Index扫描的Sql语句：
查找全表扫描的SQL语句
Select sql_text from v$sqltext t, v$sql_plan p Where t.hash_value=p.hash_value And p.operation=’TABLE ACCESS’ And p.option=’FULL’ Order by p.hash-value, t.piece; |
查找Fast Full index 扫描的Sql语句可以这样；
Select sql_text from v$sqltext t, v$sql_plan p Where t.hash_value=p.hash_value And p.operation=’INDEX’ And p.option=’FULL SCAN’ Order by p.hash-value, t.piece; |
如果是Oracle8i的数据库，可以通过v$session_event视图中找到关于这个等待事件的进程sid，然后根据这个sid来跟踪相应会话的SQL
Select sid, event from v$session_event Where event=’db file sequential read’ |
或者可以通过查看物理读取最多的SQL语句的执行计划，看是否里面包含了全表扫描和Fast Full Index扫描，可以通过以下语句获取物理读取最多的SQL语句
Select sql_text from Select *from v$sqlarea Order by disk_reads) Where rownum<10 |
方法二：
有时候执行计划很好也会出现多block扫描的情况，这个时候可以通过调整Oracle数据库的多block的I/O，来设置一个合理的DB_FILE_MULTIBLOCK_READ_COUNT,使得尽量满足；
Db_block_size * DB_FILE_MULTIBLOCK_READ_COUNT = max io size of system
这个参数也不是设置的越大越好，设置这个参数之前需要了解一下应用的类型，如果是OLTP类型的，一般来说全表扫描较少，这个时候如果设置了比较大反而会降低数据库的性能，因为CBO在某些情况下会因为多block读取导致COST比较低从而错误的选用了全表扫描。
其他方法
还可以采用对表和索引使用分区、将缓存区的LRU末端的全表扫描和FastFullIndex扫描的block放入到Keep缓存池等方法来进行�