REDO日志的基本结构

REDO日志的基本结构

构成REDO日志的要素包括REDO日志缓冲区和REDO日志文件。此外， LGWR程序会将复原信息写入REDO日志，并且和DBWR（将数据库缓冲区数据写回数据文件的程序）与ARCH（把REDO日志文件当成更新履历，将其复制到归档文件的程序）进行消息通信，所以必须了解这些程序的工作原理。

下图说明REDO日志的基本处理流程。

1. 由于用户请求更新，所以后台进程会从数据文件将对应的数据块复制到数据库缓冲区。
2. 执行UPDATE处理，被更新的新信息和更新前的旧信息都被写入日志缓冲区。
3. 更新前的旧讯息写入到数据库缓冲区内分配的回滚段。
4. 更新后的新讯息会覆盖数据库缓冲区内分配的数据块。
5. 接收到Commit要求，把日志缓冲区内的变更写入REDO日志文件    （除了Commit之外还有其他情况会进行往REDO日志文件的写入处理）（以后会进一步介绍）。
6. REDO日志文件满了之后，就会出现checkpoint。
7. 出现checkpoint的时候，LGWR会向DBWR发送消息。
8. DBWR收到[出现checkpoint]的通知，把数据库缓冲区内的未清空的数据块全部写回数据文件。
9. 写回数据文件的步骤结束之后，通知LGWR处理已经结束。
10. LGWR会把被写入日志缓冲区变更的REDO日志文件从1改为2（log switch）。
11. 如果以归档模式运行数据库，在纪录数据库变更后已满的REDO日志文件会被写出到归档文件。

这次将详细介绍其中的LGWR进程，该进程执行REDO日志文件写入处理。

LGWR 将来自log Buffer的commit/rollback信息写入到REDO 日志文件，这些信息用于在数据库发生故障时恢复数据库。在频繁执行Update操作的情况下，LGWR会满负荷运行。这时， REDO日志文件写入操作的I/O性能就成为影响响应速度的关键因素。

LGWR操作在下列时间点会发生：
1. 距上次的写入达到3秒
2. 事务被提交（commit）
3. REDO日志缓冲区使用量达到3分之1的时候
4. DBWR要往数据文件执行写回动作之前
5. 出现checkpoint的时候
对于数据库内所有被更改的数据块，Oracle会把所有更改内容记录在REDO日志缓冲区。更改内容包括数据段，索引段和回滚段（rollback segment）。 数据库内任意数据块所产生的一次更改，会被记录为一个变更向量（Change Vector）。 变更向量里包含了发生变化的数据块的地址和更新前的数据。

数据库记录变更的最小单位是变更向量，一系列相关变更向量的集合称为重做记录 （REDO Record）。有些事务（transaction）会产生不止一个重做记录， 每个重做记录里都包含了一连串的变更向量.

※change vector
表示对数据库内某一个数据块所做的一个变更，change vector容纳了变更的数据块的地址（DBA）以及更新后的数据。
※REDO record
记录单一数据库变更的一系列change vector构成REDO record，有些transaction会产生不只一个REDOrecord，每个REDO record各有一连串的change vector。
假如执行了10件更新处理，会产生10笔REDO record，每个REDO record里都有多个change vector，在创建这个REDO record(change vector)的过程中会产生大量的未使用(浪费)的空间。换句话说，由于创建REDO record(change vector)时执行写入是以数据块为单位的，所以会产生空间浪费。
UPDATE、INSERT、DELETE对REDO日志文件写入的信息量并没有太大的差异，换句话说，REDO日志文件的写入是以OS的数据块(512byte) 为单位，从性能的观点看这三种处理就完全没有差异，如果是处理件数差异很大或者任务关联非常多的表，情况就会不同。

delet  >insert>update     redo size

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/22578826/viewspace-663899/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/22578826/viewspace-663899/