重做
redo log，重做日志有两种，联机和归档（数据库事务的历史记录）
- 每个Oracle数据库至少有两个联机重做日志文件，循环使用，Oracle先往日志1写，写满专向日志2，写满转回日志文件1
- 归档重做文件日志文件只是复制旧的，写满了的联机重做日志文件
- 当系统写满日志文件时，ARCH进程会把联机重做日志文件复制到另一个位置
- 当硬盘出现故障或者物理损坏时，使用归档重做日志文件实现介质恢复
COMMIT
commit是一个非常快的操作，不管事务大小，commit响应时间通常是"平均的"
commit 1行花费x隔单位，commit 1000行同样花费x个单位，但是进行1000次commit一行的操作花费的是1000*x个单位
commit提交前做好的工作
- 在SGA中产生了回滚段（callback segment）记录
- 在SGA中产生了修改数据块
- 在SGA中产生了上面两条缓冲重做（undo）
- 取决于上面3项大小和消耗的时间，一部分数据可能已经刷新到硬盘上
- 已经获得所有的锁定
当commit时，所有剩下的工作
- 为事务产生一个系统改变号（System Change Number，SCN）
- LGWR把所有余下的缓冲区中的重做日志存储到硬盘上，并在联机重做日志文件中记录SCN（当前步骤即SCSN）
- 删除了事务条目，意味着已经提交了，在V$TRANSZCTION试图中的记录将消失
- 释放会话占用的所有锁定，释放在入队列等待中被占用锁定的每个事项
- 访问多个修改事务块，若它们仍在缓冲区高速缓存中，用快速模式访问和清除
执行commit只有很少的工作，时间最长的总是LGWR执行的操作，因为它是物理硬盘的IO
当操作进行时，LGWR连续刷新，至少：
- 每3秒
- 当满1/3或1MB
- 碰到任何事物commit
LGWR消耗的时间是由重做日志缓冲区已经释放的内容限定的
LGWR不会存储所有工作，当操作进行时，他将增加释放后台重做日志缓冲区中的内容，可以立即释放所有重做内容
在提交前，缓冲重做日志已经被放到硬盘上了，当commit时，必须等待
LGWR的调用是同步的事物要等待LGWR完全写完，收到的数据存在于硬盘上
SCN
是Oracle保证事务顺序并从失败中恢复的简单定时机制，SCN也能保证数据库一致读取性和检查点机制，类似计数器
回滚
ROLLBACK 必须物理上取消已完成的工作，在ROLLBACK之前已经完成了很多工作
- 已经在SGA产生了回滚段记录
- 已经在SGA产生了修改数据块
- 已经在SGA中产生了上面两条重做缓冲信息
- 取决于上面三项大小和消耗时间，一部分上面的数据可能已经刷新到硬盘上
- 已经获得所有锁定
当ROLLBACK时
撤销所有已做的修改，通过从ROLLBACK（undo）读取数据来完成，实际上是逆向操作
- 如果插入了一行，ROLLBACK删除它
- 如果更新了一行，ROLLBACK将逆向更新
- 如果删除了一行，回滚将重新插入它
释放会话占用的所有锁定，释放在队列中等待被占用锁定的每个事项
commit只是刷新保留在重做日志缓冲区中的数据，和ROLLBACK相比，做了非常少的工作
产生多少重做
重做管理是数据库中串行化的关键，在LGWR结果所有事务，要求它在它们的事务中管理重做和COMMIT
LGWR做的越多，系统越慢
使用动态性能试图V$MYSTAT，连接V$STATNAME，然后检索名为redo size的统计值，用V$STATNAME找到它
select * from v$statname;
阐述如何指定事务产生的重做量，知道要修改多少数据，可以直观估计要产生多少重做
对于AUTOTRACE追踪的语句（INSERT，UPDATE和DELETE），可以使用AUTOTRACE
无论使用一条语句UPDATE200行，都产生相同数量的重做，对DELETE结果也一样，无论是一条语句还是200条语句
insert情况不太一样，对于单行插入产生的重做稍微多一些，当一行插入时，必须组织不同块中的数据，一次插入多行不是这样
产生的重做是修改数据量的函数，如果insert2000字节的行，每行产生的重做将会稍微多余2000字节
当update时，会产生两倍数量的重做（记录日志数据和回滚），DELETE的情况和INSERT情况相似，整个行记录在回滚段
BEFORE触发器即使不修改行中的任何值，也会增加额外的重做信息
使用上面的技术，会发现
- BEFORE或AFTER触发器不影响DELETE
- 对于BEFORE或AFTER触发器，INSERT产生同样多的额外重做信息
- UPDATE只受BEFORE触发器的影响，而AFTER触发器不增加额外重做信息
- 行的大小影响INSERT产生的额外重做信息的数量，不影响UPDATE
在UPDATE时，AFTER触发器对UPDATE更有效，它根本不影响重做的产生，当且仅当必须使用BEFORE触发器时才使用它
估计重做的量
- 估计"事务"的大小--需要修改多少数据
- 是否增加10%~20%的额外开销，取决于要修改的行数，行越多，额外开销越少
- 对UPDATE，此值加倍
为了保持索引结构，必须完成索的工作量从UPDATE到UPDATE可能是不同的，考虑触发器的缺点和代表性能的隐式操作
如何不让重做日志产生
redo log对数据库至关重要，某些sql语句和操作支持使用nologging，可以不产生redo log
当使用nologging操作
- 会产生一定数量的重做，用来保护数据字典，无法避免重做的产生，虽然可以比以前明显地少
- nologging不能防止后面的操作产生重做
- 在ARCHIVELOG模式的数据库中执行nologging操作之后，必须尽快备份受影响的数据文件，可以避免介质故障丢失对文件的修改
两种方式使用nologging
- 在sql命令中何时为止嵌入关键字nologging
- 在nologging模式中隐式执行
在ARCHIVELOG模式数据库中，适当使用NOLOGGING，可以通过大量减少产生的重做日志数量，加速许多操作
不能分配一个新日志
Sun Feb 25 10:59:55 2001
Thread 1 cannot allocate new log, sequence 326
Checkpoint not complete
被要求归档，而不是设置检查点没有完成
只要数据库试图重用联机重做日志文件，但是发现不行时，就把此消息写入服务器的alert.log文件
当DBWR没有完成检查重做日志保护的数据，或者ARCH没有把重做日志文件复制到归档为止，就会发生这种情况
当发现会话长时间等待，最可能碰到提示：
切换日志文件，日志缓冲区空间，或切换日志文件设置检查点或归档没有完成
块清除
数据锁定会影响存储在块头上的数据，缺点是当块写一次被访问时，必须“清除”它，换句话说，删除事务的信息
这么做会产生重做并且导致块变脏
如果主要是小到中等的事务（OLTP联机事务处理），或是在批量操作后分析表的数据仓库，一般会"清除"块
COMMIT时处理的一个步骤，重新访问SGA中的块；如果是可访问的，清除它们，称为"提交清除"
强制清除
Oracle分配块清单，这些块在事务相关的提交清单中修改过，每个块清单有20个块，Oracle根据需要尽可能多地分配
修改过的块总和超过了缓冲区高速缓存大小的10%，Oracle会停止分配新块
SELECT产生了重做，它还"弄脏"了这些修改过的块，导致DBWR再次写入它们，这是块清除的原因
在OLTP（联机事务处理）系统中，所有事务都是短半块，修改几块并全部清除
create table as select
直接路径装载数据，直接路径插入数据，都将创建''干净"的块
日志竞争
最大等待事件是；日志文件同步
正在经历重做日志竞争，它们运行得不够快，发生原因有很多种
- 一个应用程序提交频率太高，例如提交在循环中insert，
等待LGWR把重做日志缓冲刷新到硬盘上，LGWR可以在后台完成工作，不必等待
当COMMIT越频繁，等待越多，假定所有事务大小合适，导致日志文件等待的通常原因是
- 重做放到了运行慢的设备上，硬盘性能差，应该去购买更块的硬盘
- 把重做和其他文件放到了同一设备上，重做是设计用来在专用设备上大量连续写入，其他组件，试图作为LGWR同时在这台设备上读写，就会遇到一定程度竞争
- 用缓冲方式安装设备，使用一种成熟的文件系统，双倍的缓冲降低了运行速度
- 用慢的技术放置重做，例如RAID读取性能好，写入性能差，
需要至少5个专用设备创建日志，为了也能镜像归档文件，最好是6个，找出最小的，最快的，一两个大的硬盘
重做组1 -- 硬盘1和3
重做组2 -- 硬盘2和4
归档 -- 硬盘5和可选的硬盘6
把成员A和B的第一组重做日志放到"组1"，把成员C和D的第二组重做日志放到"组2"，如果还有第3组和第4组，放到奇数组和偶数组硬盘上
LGWR将同时写入硬盘1和硬盘3，当这组写满时，LGWR将移到硬盘2和硬盘4
写满后，又返回重新写入硬盘1和硬盘3
同时ARCH处理全部联机重做日志
LGWR在网组1上写时，ARCH在读组2，同时往归档硬盘上写
当LGWR往组2上写时，ARCH在读组1，同时往归档硬盘上写，每个LGWR和ARCH都有自己专用的设备
它们不会竞争其他设备，也不会相互竞争
日志文件是最利于使用RAW硬盘的一组Oracle文件
临时表的重做和回滚
临时表不为它们的块产生重做，临时表上的操作是不能恢复的
当修改临时表中的块时，这种修改不会在重做日志文件中记录
然后临时表会产生回滚，回滚是记录到日志的，临时表会产生redo log
- INSERT产生很少甚至没有回滚/重做
- DELETE对临时表和对正常表产生同样多的重做
- UPDATE对临时表产生的重做只有UPDATE对正常表产生的重做的一半
避免删除临时表，因为如果产生回滚，DELETE的逆向操作INSERT是很麻烦的
可以使用TRUNCATE或者只是在COMMIT或会话结束后自动清空
分析重做
使用Logminer，在里面找到DELETE的OBJ$，查看表何时由于"事故"被删除，且希望DBA在DROP TABLE前刚刚保存
回滚
ORA-01555：snapshot too old 错误问题造成的混乱十分严重
什么产生最多/最少的撤销
- INSERT将产生最少数量的撤销，因为Oracle所要做的记录是"删除"行ID
- UPDATE第二位，记录修改过的字节，只要在撤销中记录行的一小部分
- DELETE产生最多的撤销，Oracle必须把整行的"前映像"记录到撤销段，等于将整个数据写入到回滚段
set transaction
选择事务要使用的回滚段，主要是为比较大的操作能够确保有大的回滚段
对于罕见的大更新，可以使用一次
大回滚段的一个问题是，不能阻止其他事务使用
没有办法使一个回滚段属于单个事务，如果执行许多信息的某种批量更新，使用这种特性比较好
在原来的地方把大表分区，然后执行并行更新
ORA-01555: Snapshot too old
- 对在系统上执行的工作，回滚段太小
- 程序产生交叉commit（是上面情况的一种变种）
- 块清除
前两点和Oracle的一致读模式直接相关，重复使用回滚段，既回滚失败的事务又提供一致读，导致了ORA-01555
第三点在只有一个会话的数据库中，这个会话没有修改这张表，会产生错误，未修改的表为什么产生回滚呢
- 分析相关对象，块清除是大量UPDATE或INSERT的结果
- 增多回滚段，可以降低当执行长时间查询时回滚数据被重写的可能性
- 降低查询的运行时间，降低对大回滚段的需要
事实上回滚段太小了
如果回滚段是确定大小的，那么在查询执行期间便于反转，并且查询访问的数据可能被修改可能再次遇到ORA-01555
必须去定回滚段的大小需要配置足够的回滚，适应长时间的查询需要
如果从查询开始的回滚都没有重写，就可以避免ORA-01555
产生ORA-01555，是由系统最小回滚段确定的，平均容量的回滚段，最大和最小是一样的，但也有风险，最好的做法是为装载工作估计合理的使用空间
交叉提交
交叉提交也可能产生ORA-01555错误，可以通过commit x 行降低回滚空间，但是系统变慢，产生更多的undo和redo，必然导致ORA-01555
最合适的配置方法，为系统配置一个合适大小的回滚段
延迟块清除
Oracle确定前面事务使用的回滚段(block header)，确定块头是否指出前一事务的提交状态
为了得到由于推迟块清除产生的ORA-10555，必须满足以下条件
已经修改并commit，块依旧没有自动清除，超过的块超过了能适应SGA块缓冲区高速缓冲的10%