详解oracle数据库I/0相关的等待事件和相关竞争等待的处理方法

内容导航：

详解oracle数据库I/0相关的等待事件和相关竞争等待的处理方法

oracle数据库用的是rac 但是性能很差 看awr很多gc block lost等待事件，要如

Oracle数据库中，基于等待事件的性能优化和基于命中率的性能调优方法之间有什么区别？

oracle数据库性能很差，老是有cursor pin s等待事件 请问这个cursor pin

一、详解oracle数据库I/0相关的等待事件和相关竞争等待的处理方法

概述

前面针对awr报告的几个等待事件做了详细介绍，今天主要总结了oracle数据库I/0相关的等待事件和Oracle 数据库 I/O 相关竞争等待的处理方法。

oracle数据库I/0相关的等待事件

1、数据文件 I/O 相关的等待事件包括以下：

ƒ db file sequential read(数据文件顺序读)

ƒ db file scattered read(数据文件多块读)

ƒ db file parallel read(数据文件并行读)

ƒ direct path read

ƒ direct path write

ƒ direct path read (lob)

ƒ direct path write (lob)

2、控制文件 I/O 相关的等待事件包括以下：

ƒ control file parallel write

ƒ control file sequential read

ƒ control file single write

3、重做日志文件 I/O 相关的等待事件包括以下：

ƒ log file parallel write

ƒ log file sync

ƒ log file sequential read

ƒ log file single write

ƒ switch logfile command

ƒ log file switch completion

ƒ log file switch (clearing log file)

ƒ log file switch (checkpoint incomplete)

ƒ log switch/archive

ƒ log file switch (archiving needed)

4、高速缓存区 I/O 相关的等待事件包括以下：

ƒ db file parallel write

ƒ db file single write

ƒ write complete waits

ƒ free buffer wait

下面介绍Oracle 数据库 I/O 相关竞争等待的处理方法

1、优化Oracle数据库的SQL语句来减少数据库对I/O的需求：

如果数据库没有任何用户的SQL运行的话，一般来说只会产生很少的磁盘I/O或者几乎没有磁盘I/O，基本上来说数据库产生I/O的最终原因都是直接或者间接的由于用户执行SQL语句导致的。

这也就意味着可以控制单个SQL语句避免其产生大量的I/O来减少整个数据库对磁盘I/O的需求，通过优化SQL语句改变其执行计划以便让其产生尽可能少的I/O。

一般典型的存在问题的情况仅仅只是很少的几个SQL语句，但是由于其相应的执行计划不理想，会导致产生大量的物理磁盘I/O，从而使得整个数据库的性能非常之差。因此，让用户执行的SQL语句优化产生比较好的执行计划来减少磁盘I/O是一种非常行之有效的方法。

2、调整实例的初始化参数来减少数据库的I/O需求：

一般来说可以通过两种途径：

2.1、通过内存缓存来减少I/O。

数据库的I/O分为两种，一种是实际读取了数据文件的物理I/O，一种是从缓存中读取数据的逻辑I/O，可以通过使用一定数量的内存缓存来减少物理I/O(例如高速缓存区、日志缓存区以及各种排序区等等)。适当的增大高速缓存区，可以有更多的缓存供给数据库的进程使用，从缓存中读取所需要的数据，这样产生的I/O都是逻辑I/O，而不是直接从物理磁盘上读取数据，减少了物理I/O的产生。设置一个适当的排序区，可以减少在排序操作中读取临时表空间数据文件所在磁盘的次数，而尽可能多的使用缓存中的排序区来排序。其他的缓存区的工作原理基本都是一致的，都是通过使用缓存来减少读取物理磁盘的次数来降低I/O。

PS:这里顺便介绍下怎么看高速缓存区是不是值得优化

--测量Database Buffer Cache的性能select 1 - ((physical.value - direct.value - lobs.value) / logical.value) "Buffer Cache Hit Ratio" from v$sysstat physical, v$sysstat direct, v$sysstat lobs, v$sysstat logical where physical.name = 'physical reads' and direct.name = 'physical reads direct' and lobs.name = 'physical reads direct (lob)' and logical.name = 'session logical reads';

当>90%则说明调整充分的。命中率是高的，如果低于90%就需要优化高速缓存区了。

2.2、调整一次读取多个BLOCK的大小

单独的一次多个BLOCK读取的操作的大小是由实例的初始化参数db_file_multiblock_read_count来控制的。如果执行比较大的I/O操作，一次读取的多个BLOCK大小越大，所需要的时间就会越短。

Oracle 10gR2以后会根据相应的操作系统及buffer cache以最优化的方式来自动设定该参数的值。通常情况下该值为1MB/db_block_size。

在最大I/O为1MB的情况下，block的大小为8KB，则参数的值为128。如果在最大I/O为64KB，block为8KB，则参数的值为8。

对于OLTP和batch环境该参数的值为4到16，DSS环境应设置大于16以上或大的值。

该参数的变化对数据库性能产生整体性的影响，过大的设置会导致大量SQL访问路径发生变化，如原先的索引扫描倾向于使用全表扫描。

因此，在配置数据库初始化参数的时候，根据操作系统的I/O吞吐能力都会设置的一次读取多个BLOCK的大小尽量多，以减少读取I/O的次数。

3、在操作系统级别上优化I/O：

在操作系统级别上优化磁盘的I/O，以提高I/O的吞吐量，如果操作系统支持异步I/O，尽量去使用异步I/O；还可以使用高级文件系统的一些特性，例如直接I/O读取，忽略掉操作系统的文件缓存，也就是我们平时所说的使用裸设备。还有一种可行的方法是增大每次传输的最大I/O大小的限制，以便每次能够传输的I/O尽可能的大。

4、通过使用RAID、SAN、NAS来平衡数据库的I/O：

4.1、RAID

RAID是Redundent Array of Independent Disks的缩写，直译为"廉价冗余磁盘阵列"，也简称为"磁盘阵列"。RAID的优点是传输速率高并且可以提供容错功能。在RAID中，可以让很多磁盘驱动器同时传输数据，而这些磁盘驱动器在逻辑上又是一个磁盘驱动器，所以使用RAID可以达到单个磁盘驱动器几倍、几十倍甚至上百倍的速率。因为普通磁盘驱动器无法提供容错功能，如果不包括写在磁盘上的CRC(循环冗余校验)码的话。RAID容错是建立在每个磁盘驱动器的硬件容错功能之上的，所以它提供更高的安全性。

RAID分为以下几个级别：

RAID 0: RAID 0并不是真正的RAID结构,没有数据冗余. RAID 0连续地分割数据并并行地读/写于多个磁盘上.因此具有很高的数据传输率.但RAID 0在提高性能的同时,并没有提供数据可靠性,如果一个磁盘失效,将影响整个数据.因此RAID 0不可应用于需要数据高可用性的关键应用。

RAID 1: RAID 1通过数据镜像实现数据冗余,在两对分离的磁盘上产生互为备份的数据. RAID 1可以提高读的性能,当原始数据繁忙时,可直接从镜像拷贝中读取数据.RAID 1是磁盘阵列中费用最高的,但提供了最高的数据可用率.当一个磁盘失效,系统可以自动地交换到镜像磁盘上,而不需要重组失效的数据。

RAID 2:从概念上讲, RAID 2同RAID 3类似,两者都是将数据条块化分布于不同的硬盘上,条块单位为位或字节.然而RAID 2使用称为"加重平均纠错码"的编码技术来提供错误检查及恢复.这种编码技术需要多个磁盘存放检查及恢复信息,使得RAID 2技术实施更复杂.因此,在商业环境中很少使用。

RAID 3:不同于RAID 2, RAID 3使用单块磁盘存放奇偶校验信息.如果一块磁盘失效,奇偶盘及其他数据盘可以重新产生数据.如果奇偶盘失效,则不影响数据使用.RAID 3对于大量的连续数据可提供很好的传输率,但对于随机数据,奇偶盘会成为写操作的瓶颈。

RAID 4:同RAID 2, RAID 3一样, RAID 4, RAID 5也同样将数据条块化并分布于不同的磁盘上,但条块单位为块或记录. RAID 4使用一块磁盘作为奇偶校验盘,每次写操作都需要访问奇偶盘,成为写操作的瓶颈.在商业应用中很少使用。

RAID 5: RAID 5没有单独指定的奇偶盘,而是交叉地存取数据及奇偶校验信息于所有磁盘上.在RAID5上,读/写指针可同时对阵列设备进行操作,提供了更高的数据流量. RAID 5更适合于小数据块,随机读写的数据.RAID 3与RAID 5相比,重要的区别在于RAID 3每进行一次数据传输,需涉及到所有的阵列盘.而对于RAID 5来说,大部分数据传输只对一块磁盘操作,可进行并行操作.在RAID 5中有"写损失",即每一次写操作,将产生四个实际的读/写操作,其中两次读旧的数据及奇偶信息,两次写新的数据及奇偶信息。

4.2、SAN

SAN(Storage Area Network， 存储局域网)是独立于服务器网络系统之外几乎拥有无限存储能力的高速存储网络，这种网络采用高速的光纤通道作为传输媒体，以FC (Fiber Channel， 光通道)+ SCSI(Small Computer System Interface， 小型计算机系统接口)的应用协议作为存储访问协议，将存储子系统网络化，实现了真正高速共享存储的目标。一个完整的SAN包括： 支持SAN的主机设备，支持SAN的储存设备，用于连接SAN的连接设备，支持SAN的管理软件，支持SAN的服务。

4.3、NAS

网络附加存储设备（Network Attached Storage，NAS）是一种专业的网络文件存储及文件备份设备，或称为网络直联存储设备、网络磁盘阵列。

NAS是基于LAN的，按照TCP/IP协议进行通信，面向消息传递，以文件的I/O方式进行数据传输。在LAN环境下，NAS已经完全可以实现异构平台之间的数据级共享，比如NT、UNIX等平台的共享。

一个NAS包括处理器，文件服务管理模块和多个的硬盘驱动器用于数据的存储。NAS可以应用在任何的网络环境当中。主服务器和客户端可以非常方便地在NAS上存取任意格式的文件，包括SMB格式（Windows）NFS格式(Unix, Linux)和CIFS格式等等。

NAS系统可以根据服务器或者客户端计算机发出的指令完成对内在文件的管理。NAS是在RAID的基础上增加了存储操作系统，因此,NAS的数据能由异类平台共享。

因此，利用RAID、SAN、NAS的技术在多个物理磁盘之间平衡数据库的I/O，尽量避免数据库产生I/O竞争的瓶颈。

5、手工分配数据文件到不同的文件系统、控制器和物理设备来重新调整数据库I/O

如果数据库目前的存储设备不算太好，那么采用这种方法是一个不错的选择。

这样可以让所有的磁盘得到充分的利用，不至于出现某些磁盘的I/O过于太高，而某些磁盘就根本没有被使用的情况，使得在配置较低的情况下得到一个比较好的数据库性能。

篇幅有限，关于oracle数据库I/0等待事件优化就介绍到这了。后面会分享更多关于DBA方面的内容，感兴趣的朋友可以关注下！！

一、oracle数据库用的是rac 但是性能很差 看awr很多gc block lost等待事件，要如

在Oracle RAC环境中，无论我们从AWR自动负载性能报告、Statspack或者Grid Control中都可以找到Oracle数据库软件所收集的全局缓存工作负载统计信息(global cache work load statistics)；其中就包含了全局缓存块丢失(Global cache lost blocks)的统计信息(这些丢失的全局缓存块可能是gc cr block lost或者gc current block lost)，若集群中的任意节点出现大量的全局缓存块丢失(下文简写为gc blocks lost)，则可能意味着内联(private)网络存在问题或者packet网络包处理低效。通过监控和评估这些全局缓存的相关统计信息，可以有效保证内联全局缓存(interconnect Global Cache)和全局队列服务(Global Enqueue Service)(GCS/GES)以及整个集群的正常工作。全局缓存块丢失一般预示着网络包处理存在问题并需要进一步勘察。另外全局缓存块丢失(gc blocks lost)的问题常会伴随着gc cr multiblock waits等待发生(传输多个连续的数据块全局缓存)。
就目前来看最有嫌疑造成或加速gc blocks lost的”元凶”往往是因为错误地或者不当的配置了内联网络(interconnects)。接下来我们会进一步介绍如何找出造成gc blocks lost的原因。
虽然gc blocks lost对集群造成的影响更多的反应在性能方面，但我们也无法保证其没有造成节点/实例被驱逐(eviction)的可能性。Oracle Clusterware集群及Oracle RAC实例的节点成员管理依赖于内联网络的心跳(heartbeats)。假设在网络心跳持续丢失的情况下，节点/实例的驱逐可以发生。以下我们列出gc blocks lost可能造成的主次要症状:
主要症状:
‘gc cr block lost’或’gc current block lost’成为实例中Top 5的主要等待事件
次要症状:
SQL trace报告显示多次出现gc cr requests，gc current request等待事件
出现长时间的gc cr multiblock requests等待
糟糕的应用性能与吞吐量
ifconfig或其他网络工具显示存在大量的网络包packet发送接收(send/receive)错误
netstat报告显示存在errors/retransmits/reassembly等失败
单个或多个节点失败
由网络处理引发的异常CPU使用率

如果自己搞不定可以找ASKMACLEAN专业ORACLE数据库修复团队成员帮您恢复!

二、Oracle数据库中，基于等待事件的性能优化和基于命中率的性能调优方法之间有什么区别？

基于命中率的性能调优方法
如果HIS系统长期以来在业务忙碌的时候运行缓慢，这时候可以指导维护人员生产AWR报告，发现Cache Hit Ratio只有67%，AWR报告Top5 wait主要为db file sequence read和db file scattered read。检查SGA Buffer Cache配置，只有478M。这时候只需要增加Buffer Cache（例如增加到2G）性能问题就会消失。

不过基于命中率调优的方法也具有一定的局限性
1.基于命中率的技术瑞然反映了Oracle内部效率问题，但这些命中率与使用数据库的应用的性能关系不大；
2.命中率分析方法通过全局平均和模糊了个体，而大部分性能问题都是基于个体的。
基于等待事件借口的性能优化
优点：
1.OWI方法是快速解决orale性能的最有效方式；
2.OWI方法优化降低了性能优化人员的能力需求。
缺点：
1.OWI事实上并不是从业务（流程）的角度看问题，而是从CPU的角度看问题；
2.解决复杂性能问题有局限性。
OWI分析方法本质上和基于等待时间的调优方法是类似的，都缺乏从整体业务流程出发的概念。但是OWI的好处就是，简单、有效、快速。
具体的优化方法可以进入OTPUB学习网了解详情！

三、oracle数据库性能很差，老是有cursor pin s等待事件 请问这个cursor pin

cursor: pin * events’等待事件

该类等待事件一般是为了pin相关的子游标

cursor: pin S 当一个进程以共享pin模式申请一个Mutex，而不能立即获得时，进入cursor: Pin S等待事件。 Mutex Pin是以共享类型的操作，例如执行一个游标。

当一个进程等在cursor: pin S上，说明该进程在对一个共享的mutex pin
参考或取消参考时，有其他的进程也正在为同样的cursor heap创建或者取消一个共享Mutex pin。 实际上cursor: pin S
等待事件应当很少见，因为更新共享Mutex pin 的reference 应当是很快的。 再重复一次，S mode的Mutex可以被并发持有，
但是更新Mutex的Ref Count仍需要串行地处理 。 一旦reference count被增加好，则后续进程将可以为同样的cursor
heap增加reference count。 因此此处mutex 即可以扮演Latch的角色(串行控制ref
count的更新)，又可以扮演pin的角色(ref count本身)。

详见 《深入理解Oracle中的Mutex》一文