redo log file大小对性能的影响

[Lian...@gmail.com]

文档中看到如下内容：
The size of the redo log files can influence performance, because the
behavior of the database writer and archiver processes depend on the
redo log sizes. Generally, larger redo log files provide better
performance. Undersized log files increase checkpoint activity and
reduce performance.

一时不解 为何Undersized log files increase checkpoint activity
OK，just google it~

看到一个解决redo log故障的帖子，提到“当数据库发生日志切换时（Log Switch）,Oracle会触发一个检查点
（Checkpoint），检查点进程（Checkpoint Process，CKPT）会通知DBWR（Database Writer）进程去执
行写操作”，此时恍然大悟，过小的log file会导致过多的Log Switch，从而导致过多触发Checkpoint，最后造成过多的
Database Writer，此时效率问题也就出现了。

此后进一步了解了checkpoint的触发条件：
1.当发生日志组切换的时候
2.当符合
LOG_CHECKPOINT_TIMEOUT，LOG_CHECKPOINT_INTERVAL，fast_start_io_target,fast_start_mttr_target
参数设置的时候
3.当运行ALTER SYSTEM SWITCH LOGFILE的时候
4.当运行ALTER SYSTEM CHECKPOINT的时候
5.当运行alter tablespace XXX begin backup，end backup的时候
6.当运行alter tablespace ,datafile offline的时候;
7.运行alter tablespace、datafile offline的时候，它们存在着一定的区别：
alter datafile offline： 在offline、online的时候，系统将不会修改所有datafile的scn
alter tablespace offline：offline的事件，就会修改scn号；在online的时候，系统也将修改该ts下的所有
datafile的scn
这正是为什么online datafile需要recovery，而online tablespace就不需要

机缘巧合，反而解决了之前一直困惑的flashback query的timestamp和scn不准问题。因为SCN除了在checkpoint时会
有增加，还有一个称为commit SCN，即每个commited transaction都会被分配到一个scn，从而导致了同一个
timestamp会有多个scn，也就造成了flashback query的timestamp和scn不准问题。

做了一个实验

SQL> SELECT a, b, versions_operation, versions_startscn,
versions_endscn,
2 TO_CHAR (versions_starttime, 'YYYYMMDDHH24MISS')
starttime,
3 TO_CHAR (versions_endtime, 'YYYYMMDDHH24MISS') endtime
4 FROM test_fq
5 VERSIONS BETWEEN TIMESTAMP TO_TIMESTAMP
('20080410062040',
6
'YYYYMMDDHH24MISS'
7 ) AND
SYSTIMESTAMP
8 ORDER BY a;
A
B V VERSIONS_STARTSCN VERSIONS_ENDSCN STARTTIME ENDTIME
---------------------------------------------------------------------------
- - ----------------- --------------- -------------- --------------
10-4月 -08 06.20.41.011004 上
午 1 I
1246973 20080410062038
10-4月 -08 06.20.41.174994 上
午 2 I
1246975 20080410062041
10-4月 -08 06.20.41.250811 上
午 2 I
1246975 20080410062041
10-4月 -08 06.20.41.357464 上
午 3 I
1246977 20080410062041

B相同的数据为同一事务插入的数据，可以看到同一事务的SCN一致，但是之间跨越了一个SCN号，原因待研究