oracle等待事件10——I/O上的等待事件 下篇
5、direct path read temp / direct path write temp
为了排序工作在临时区域读写时，等待direct path read temp、direct path write temp事件。这个等待时间是从10g开始被分类的。9i之前是通过direct path read 、direct path write 等特观察的。排序段上的direct path I/O是在需要排序的数据比为排序所分配的PGA内存区大时发生的。因此若排序工作时大量发生direct path read tmp 、direct path write temp等待，就可以通过追加分配内存区域而避免等待。
1）应用程序层：检查需要排序的SQL语句是否已经最优化。不必要的排序操作会导致CPU浪费、PGA区域的浪费、磁盘I/O的浪费。从union和union all 的性能差异上可以得知，只靠减少不必要的排序操作，也能解决许多问题。
2）oracle内存层：PGA拥有为执行排序、Hash join、位图等运算等的内存区域，这个称为工作区（work area）；在进程上分配的工作区大小内一次性实现的排序称为one pass sort。与此相反的情况称为multi pass sort。发生multi pass sort时，排序工作过程中将排序结果读写到排序段（sort segment）区域，因此发生direct path read temp 、direct path write emp等待。如果等待大量发生，就可以适当提高PGA_AGGREGATE_TARGET值，以此消除问题。
设定PGA_AGGREGATE_TARGET值时有一个特别需要注意的问题：就是服务器进程限制着实际可使用的内存大小。即，只能使用PGA_AGGREGATE_TARGET上指定值的一部分。oracle根据PGA_AGGREGATE_TARGET上指定的值计算特定进程上可以分配的最大内存区域，这个值存储在隐含参数_SMM_MAX_SIZE里，其单位是KB。_SMM_PX_MAX_SIZE是在执行paralle query时所有slave session上可使用的最大内存大小。从v$sesstat视图查看session pga memory max值，可以查到实际使用的最大内存区域。
6、direct path read（lob） / direct path write(lob)
如果创建LOB列时使用的nocache 选项，读写LOB段的工作就使用direct path I/O，这时等待direct path read（lob）、direct path write（lob）事件。使用cache选项创建LOB列时因为讲过高速缓冲区，索引应用与一般数据相同的机制。
创建LOB时，在cache和nocache中使用哪个选项，是根据系统和数据的特点决定的。如果SGA没有空余空间或LOB数据较大，则使用NOCACHE比较有利，如果LOB数据不大，而且经常访问的范围固定，则通过cache选项可得到性能改善的效果。
在LOB数据的属性里，存在其他数据类型上没有的多种选项。不谨慎使用时，可能引发较多的性能问题，因此创建LOB时应该注意如下事项：
1）使用enable storage in row 选项时，比4000 bytes小的LOB数据与行一起存储在相同的块，因此引发连接的可能性高。使用比4000bytes大的LOB数据与使用disable storage in row 选项时具有相同结果。考虑到LOB数据的大小，如果被判断为发生行链接的可能性高，最好使用disable storage in row选项。存储在与行相同的LOB数据称为in-line LOB，存储LOB段时称为Out-of-line LOB。
2）使用disable storage in row时，LOB数据存于另外的LOB段，行内只存储20bytes大小的LOB地址信息。这时回滚段数据只对LOB定位创建。LOB数据的实际撤销信息不是存在于撤销表空间上，而是存于LOB段内。LOB段的回滚段被PCTVERSION选项所控制，例如PCTVERSION为50，LOB段的空间中50%用于存储撤销信息。因此将PCTVERSION设定的较低时，可能发生意想不到的错误ora-01555snapshot too old。若是LOB段的撤销区域不足引起的snapshor too old 错误是，rollback segment name以空白表示，PCTVERSION过小，则发生错误ora-01555的概率增高，PCTVERSION过大，则浪费空间加深。解决这个问题的方法与发生一般回滚段上的错误ora-01555的情况相同。就是适当保持PCTVERSION，减少不必要的提交。保障LOB段扩张空间也相当重要。
3） CACHE/NOCACHE, LOGGING/NOLOGGING：如果LOB数据大，且不经常被访问或随机被访问，就应该使用nocache选项。使用nocache选项时，可以指定创建重做与否。如果不是必须恢复的数据，就可以使用nologging选项，因此能获得性能改善的效果，使用cache选项是必须要拥有logging属性。使用nocache选项时，因不经过高速缓冲区，所以会等待diect path red（lob），dirct path write（lob）事件，但使用cache选项时，因经过高速缓冲区，所以可能引发db file sequential read 和 latch：cache buffer chains等待。
4）chunk的大小：out-of-line LOB时，就以chunk为单位存储LOB数据。使用较大的chunk问题在于发生空间浪费的可能性高。如果chunk原来是8K，插入了1K大小的LOB数据，则余下7K空间可能无法使用。chunk大小的单位基本上是块大小的整数倍。如果块大小为8K时，将chunk大小设定为5000bytes，oracle就会隐式变换为8192bytes。共将chunk的大小设定的过小时，则会在连续分配chunk的过程中消耗性能。
7、db file parallel write
经过高速缓冲区的所有数据都是通过DBWR写入磁盘的，DBWR请求写入脏块的I/O后，在此工作结束期间等待db file prarllel write事件。db file parallel write 事件拥有P1=file#，P2=block#，P3=block数量。这三个值。
db file parallel write等待基本上可视为I/O问题。如果DBWR进程上这个等待广泛出现，就可以判断与数据相关的I/O系统上发生了严重的性能下降现象。若I/O系统没有性能问题，但db file parallel write 等待没有消失，就可以认为I/O系统上收到无法承担的大量请求。
db file parallel write等待的发生原因和解决方法如下：
I/O系统的性能缓慢时：
若果DBWR进程上db file parallel write等待时间表现的过长，就可以判断为I/O系统上有问题。如果DBWR上的db file parallel write 等待时间延长，服务器进程就会连接经历free buffer waits事件或write complete waits事件的等待。这个问题可通过改善I/.O系统解决，改善I/O系统的方法如下：
1）组合使用裸设备和异步I/O是目前为止最好的方法。
2）OS级上使用direct I/O。若cpu数量充足，可以调整DB_WRITER_PROCESSES参数值，将DBWR数量增加。多个DBWR具有模拟异步的效果。oracle推荐的DBWR进程是CPU_COUNT/8。利用v$filestat视图，可以间接推断是哪些文件上主要发生性能问题的。
I/O工作过多时：
频繁发生检查点时，DBWR的活动量过多，可能导致DBWR的性能降低。DBWR的性能与整个系统的性能有直接的关系。将FAST_START_MTTR_TARGET参数值设定过小时，将频繁发生增量检查点工作。日志文件过小时，将频繁发生日志文件的转换，因此检查点工作将增加。因parallel query发生direct path read 时，在truncate 、drop 、hot backup时也发生检查点。如果I/O系统上不存在性能问题，但还是广泛出现db file parallel write等待，就应该查看是否存在给DBWR带来不必要负荷的因素。
不能有效使用高速缓冲区时：
间接改善DBWR性能的另一种方法是合理使用多重缓冲池（default 、keep、recycle）。因为不必要的写入工作减少，减少了DBWR的负担。改善了I/O系统的性能。
8、control file parallel write
回顾一下控制文件中包括的内容：
the database name（数据库名字）
the timestamp of database creation（数据库创建时间戳）
the names and locations of associated datafiles and redo log files（数据文件和日志文件名字以及位置）
tablespace information（表空间信息）
datafiles offline ranges（数据文件脱机范围）
the log history（日志历史）
archived log information（归档日志信息）
backup set and backup piece information（备份集和备份片信息）
backup datafile and redo log information（日志文件，数据文件的备份信息）
datafile copy information（数据文件的拷贝信息）
the current log sequence number（当前日志的序列号）
checkkpoit information（检查点信息）
查看 v$controlfile_record_section视图后，可以确认当前控制文件管理哪些信息：
SQL> desc v$controlfile_record_section;
名称 是否为空? 类型
----------------------------------------- -------- - -------------
TYPE VARCHAR2(28)
RECORD_SIZE NUMBER
RECORDS_TOTAL NUMBER
RECORDS_USED NUMBER
FIRST_INDEX NUMBER
LAST_INDEX NUMBER
LAST_RECID NUMBER
SQL> select type,records_used from v$controlfile_record_section;
TYPE RECORDS_USED
---------------------------- ------------
DATABASE 1
CKPT PROGRESS 0
REDO THREAD 1
REDO LOG 3
DATAFILE 5
FILENAME 9
TABLESPACE 6
TEMPORARY FILENAME 1
RMAN CONFIGURATION 0
LOG HISTORY 454
OFFLINE RANGE 0
TYPE RECORDS_USED
---------------------------- ------------
ARCHIVED LOG 0
BACKUP SET 0
BACKUP PIECE 0
BACKUP DATAFILE 0
BACKUP REDOLOG 0
DATAFILE COPY 1
BACKUP CORRUPTION 0
COPY CORRUPTION 0
DELETED OBJECT 1
PROXY COPY 0
BACKUP SPFILE 0
TYPE RECORDS_USED
---------------------------- ------------
DATABASE INCARNATION 2
FLASHBACK LOG 0
RECOVERY DESTINATION 1
INSTANCE SPACE RESERVATION 1
REMOVABLE RECOVERY FILES 0
RMAN STATUS 0
THREAD INSTANCE NAME MAPPING 8
MTTR 1
DATAFILE HISTORY 0
已选择31行。
请求控制文件的更新的进程直到更新结束为止，期间等待control file parallel write事件。一般环境下，因为更新控制文件的次数不多，因此不怎么发生control file paralle write等待现象，但如下情况下可能发生与控制文件相关争用：
***日志文件切换经常发生时：日志文件过小时，进程发生日志文件的切换。每当发生日志文件的切换时，需要对控制文件进行更新，所以LGWR进程等待control file parallel write时间的时间将延长。
***检查点经常发生时：MTTR设定的过短或频繁的发生人为的检查点时，CKPT进程等待Control file parallel write 事件的时间将延长。
***nologging引起频繁的数据文件修改时：对数据文件在nologging选项下执行修改工作时，为了修改unrecoverable SCN，需要更新控制文件，这时，服务器进程将等待control file parallel write事件，对于利用nologging选项创建的LOB数据进行修改时代表性的例子（unrecoverable SCN是利用RMAN实现备份时所使用）
***I/O系统的性能缓慢时：最好是将控制文件位于独立的磁盘空间上，使用裸设备或direct I/O，若控制文件数量过多时，最好只保管恢复所需的最少量的控制文件。若控制文件的更新工作不是很多，但特定进程经历许多control file parallel write 等待，就有必要怀疑I/O系统的性能。
control file parallel write 等待，通常与control file sequential read 等待或enq：CF-contention等待一通出现的情况较多。enq：CF-contention等待是在多个会话为了同时更新控制文件获得CF锁的过程中发生的。control file parallel write 、control file sequential read ，enq：CF-contention等待，全是因为过多的控制文件更新或I/O系统的性能问题引发的。