日志文件的操作部分总结

最新推荐文章于 2024-10-15 15:06:01 发布

weixin_34232363

最新推荐文章于 2024-10-15 15:06:01 发布

阅读量117

点赞数

文章标签：数据库

原文链接：http://www.cnblogs.com/ebs-blog/archive/2007/10/22/2167353.html

版权

1 性能调整的重点是减少磁盘的物理i/o。
2 频繁执行更新处理，代表对数据文件（磁盘）会产生频繁的I/O，也就是会数据文件频繁的写入和读取。每次执行写入和读取的时候，磁盘head就会移动到目的位置，也就是发生“seek overhead”。如果统计 seek overhead所花费的时间（计入磁盘I/O），你就会发现，这就可能是降低性能的原因。

然而，对日志文件的读取操作完全不会发生（数据库出现故障执行复原处理的情况除外）,因此REDO日志文件因读取而发生的seek overhead完全不存在。再则，REDO日志文件都是顺序写入的，即总是从head的所在位置开始写入。因此，无须将head移到要写入的位置而产生seek overhead，所以相较于对数据文件的写入，REDO日志文件执行写入处理更快

对于数据库内所有被更改的数据块，Oracle会把所有更改内容记录在REDO日志缓冲区。更改内容包括数据段，索引段和回滚段（rollback segment）。数据库内任意数据块所产生的一次更改，会被记录为一个变更向量（Change Vector）。变更向量里包含了发生变化的数据块的地址和更新前的数据。

数据库记录变更的最小单位是变更向量，一系列相关变更向量的集合称为重做记录（REDO Record）。有些事务（transaction）会产生不止一个重做记录，每个重做记录里都包含了一连串的变更向量。下面，我们就以实例追踪变更向量和重做记录产生的过程。

──SQL语句──
*************************************************************
UPDATE WORK03
SET EMPNO = 9999
WHERE EMPNO = 1111 ;

※ EMPNO项目尚未创建索引
*************************************************************
运行上面的UPDATE语句之后，会产生下面的变更向量。

1. 对于回滚段的事务表（header）的变更向量
事务表中包含被修改的数据块的地址、该事务的状态（commit或active）、以及存有该事务的UNDO的回滚段的位置，如果事务表被修改，就会产生针对于它的变更向量。

2. 对于回滚段的数据块的变更向量
将修改前的值（1111）存储（修改）到回滚段里的数据块时，就会产生变更向量。

3. 对于WORK03表内的数据块的变更向量
将修改后的值（9999）覆盖（修改）到WORK03表内的数据块时，就会产生变更向量。

由上面的例子可知，对于这个事务，重做记录中会有三个变更向量。当然可能有其他情况会产生重做记录，例如修改的项目如果有索引，就必须修改索引，这时候就会产生第二个重做记录。这时候的重做记录还是和第一个重做记录一样，包含不止一个变更向量。此外，在事务完成之后运行commit语句，就会产生第三个重做记录。

把REDO信息写入到REDO日志缓冲时，Oracle必须取得REDO allocation latch和REDO copy latch这两个latch。
REDO allocation(分配) latch：在REDO日志缓冲内，分配空间给要存入的REDO entry时所需的latch。
REDO copy latch：当REDO entry太大，无法以REDO allocation latch执行copy时，REDO copy latch会代替REDO allocation latch执行copy。
这两个latch的功能和作用请参考下图的说明。图中提到REDO entry的大小，主要取决于初始设定参数LOG_SMALL_ENTRY_MAX_SIZE。
http://www.performance-insight.com/html/ora3/ora3_ref/ref85.gif
假设这个参数设定为80 (Oracle7.2之前是800)，也就是说，对于80 byte以下的REDO entry由REDO allocation latch执行copy，超过80 byte的REDO entry就由REDO copy latch执行copy。

这种结构是因为REDO allocation latch只有一个，所以当REDO allocation latch在copy比较大的REDO entry时，又发生下一个REDO entry，就必须等到REDO allocation latch恢复闲置才能进行copy，也就是存在时间等待。因此，把copy任务交给多个REDO copy latch处理，可以预防REDO信息的copy中断。

此外，因为决定REDO copy latch数目是由初始设定参数LOG_SIMULTANEOUS_COPIES决定，这个参数的预设值是实际上CPU的个数，可以增加到CPU个数的2倍。(可以通过初始化参数CPU_COUNT动态指定为CPU的个数)

此外，在单CPU系统下这个参数的数值会设定为0，所以没有REDO copy latch。因此，不论REDO entry有多大，所有的空间锁定和copy任务都由REDO allocation latch完成。(如果LOG_SIMULTANEOUS_COPIES大于1的话LOG_SMALL_ENTRY_MAX_SIZE就会有效)

转载于:https://www.cnblogs.com/ebs-blog/archive/2007/10/22/2167353.html