深入解析Oracle学习笔记（第七章）

redo 可恢复性，可重演。

undo 可回退性

redo entries（redo records）被数据库进程从用户的内存空间（PGA）复制到SGA中的redo log buffer中。redo log buffer也是循环使用的。

no-force-at-commit 提交时不强制写。通过redo的连续的，顺序的写出，使得随机分散的数据块的写出推延，获得批量效应等性能提升。

log switch触发检查点，检查点完成之前，日志文件不能被重用。

redo copy latch 用于写redo内容到redo log buffer过程的保护

redo allocation latch 用于管理log buffer内存空间分配

一个进程在修改数据时产生redo，redo首先在PGA中保存。获得redo copy latch。将redo信息copy到redo log buffer。

redo copy latch表明进程正在把redo拷贝入log buffer。

latch数量：78=CPU数量，8.1.3=2* CPU数量

redo copy latch获取后，进程接着获取redo allocation latch，分配redo空间，空间分配完成后，redo allocation latch即被释放，进程把PGA中临时存放的redo信息copy到redo log buffer，copy完成后，redo copy latch释放。此时LGWR才能去写出。

redo writing latch检查LGWR是否已经激活或被通知，避免LGWR被不必要的通知去写出。如果竞争过多，可能意味着用户提交过于频繁。

在执行redo copy的过程中，进程以log file sync事件处于等待

9i中，redo log buffer多池技术，多个子池，每个都有独立的redo allocation latch保护。提高的redo的并发。

多redo log buffer机制又被成为public redolog strands （PBRS）

处理器超过16个，并且经历非常高的redo allocation latch竞争，可以考虑并行redo。

如果misses / gets超过1%，通常认为存在latch竞争。

当主机拥有16--64个CPU时，推荐设置LOG_PARALLELISM在2--8之间，从低值开始，以1位步长增进直到redo allocation latch竞争不再激烈。不推荐超过8.

10g中LOG_PARALLELISM变为隐含参数。

_log_parallelism_dynamic 设置为true，动态调整。

_log_parallelism_max 不超过。

注意：日志并行读设置大于1之后，logminer将不能解析日志文件。

10g中引入了PVRS，在共享池中分配，而不是PGA中，独立的redo allocation latch保护，不再需要额外的内存拷贝过程，redo copy latch不再需要。而redo copy正是引发redo allocation latch竞争的根源。

RAC环境中不适用PVRS。

private strand flush not complete 从内存到redo log file的写出尚未完成。

改变向量（Vector）：改变向量表示对数据库内某一个数据块所做的一次变更。例如数据块的修改是一个改变向量，回滚段的修改又是一个改变向量。

重做记录（Redo record）：重做记录通常由一组改变向量组成，是改变向量的集合，代表一个数据库的变更，构成数据库变更的最小恢复单位。

update操作过程 P308页。

数据块加载到buffer cache。

在undo表空间，相应回滚段事务表上分配事务槽。记录redo。

从回滚段读入或者在buffer cache中创建前镜像。记录redo。

修改数据。记录redo。

用户提交，在redo记录提交信息，并在回滚段标记该事物为非激活。

redo写出触发条件：

1.每3秒超时 log file parallel write等待事件

2.阈值达到

min（1M，1/3 log buffer size）

隐含参数 _log_io_size

3.用户提交

进程通知LGWR写，并且以log file sync事件开始休眠，等待事务返回成功标志，超时时间为1秒。

组提交：多个提交在唤醒LGWR之前发生

4.DBWn写之前

DBWn需要写出的数据的High RBA超过LGWR的on-disk RBA

8i之前 log file sync事件

8i开始，DBWR把需要写出的block放入一个延迟队列，同时通知LGWR写出redo，DBWR可以继续执行无需等待的数据写出。

redo log buffer大小设置

如果log buffer space等待事件出现并且较为显著时，可以考虑增大log buffer以减少竞争

粒度

current状态日志文件，当前正在使用，崩溃恢复时必须用到。

active状态，检查点尚未完成，crash恢复时会被用到，可能已经完成归档，也可能没有归档，如果日志循环使用再次到达该文件，数据库将处于等待的停顿状态。checkpoint not complete在数据库中体现为等待事件log file switch（checkpoint incomplete）

inactive状态，实例恢复不需要，但是介质恢复可能需要。可能被归档，也可能没归档。归档完成之前，不允许被覆盖，这时进程处于log file switch（archiving needed）等待事件中。

日志文件块的大小为512byte，源代码中规定，与操作系统无关，与数据文件块大小不同。LGWR以日志文件块大小为单位写出redo。

手工热备，为了解决SPLIT BLOCK的问题，需要在日志文件中记录修改的行所在的数据块的前镜像，而不仅仅是修改信息。

RMAN可以在备份时，通过反复读取获得一致的BLOCK，从而避免了SPLIT BLOCK的生成，所以不会产生额外的redo。

NOLOGGING可以使得生成日志大幅降低，但是必要日志（如数据字典表的修改）仍然会被记录。

当使用DG作为数据库的备份或容灾模式时，日志变的不可缺少，可以将数据库至于强制日志模式 force logging，在强制日志模式下，所有操作都将被记录。

inactive日志组丢失

alter database clear [unarchived] logfile group 2; 清除日志组

损失当前日志时，如果是正常关闭的，需要recover database until cancel，然后alter database open resetlogs。

如果是异常关闭的，如果想要恢复，则必须需要当前日志，否则无法保证数据不丢失。这种情况，需要从备份恢复数据文件，然后应用归档日志文件向前推演，知道最后一个完好的日志文件，然后open resetlogs。丢失的数据就是损坏的日志文件中的数据。

如果要强制性打开数据库，忽略一致性，参数_allow_resetlogs_corruption。使用所有数据文件最旧的SCN打开数据库。然后exp导出数据，重新建库，imp导入。

此方法应在oracle技术支持的指导下进行，否则oracle将不对采用此方式进行恢复的数据库进行支持。