对undo操作，和普通的数据表空间是一样的吗？
1, 从文件（数据文件，undo 文件 ）读数据到buffer cache
2,`修改的数据在cache buffer中变成脏数据
3,`commit后写入log日志文件
4，checkpoint的时候写入到数据文件（undo文件）如果是这样的情况下，在instance恢复的时候，还会用到undo信息进行rollback吗？
因为在log文件中包含的都是commit信息
不需要进行rollback，rollforward后的数据库也是完整的最新的commit的数据库是吗？
概念有些模糊，确认一下。
1, 从文件（数据文件，undo 文件 ）读数据到buffer cache
2,`修改的数据在cache buffer中变成脏数据
3,`commit后写入log日志文件
4，checkpoint的时候写入到数据文件（undo文件）如果是这样的情况下，在instance恢复的时候，还会用到undo信息进行rollback吗？
因为在log文件中包含的都是commit信息
不需要进行rollback，rollforward后的数据库也是完整的最新的commit的数据库是吗？
概念有些模糊，确认一下。
当时cache buffer中的脏数据会写入到数据文件中去吗？
>commit后的数据暂时放入redo log吗？所以没有commit的数据是不会写到datafile中去的.
>如果redo log中有未commit的数据，此时我用switch log操作。操作完之后，再对修改的数据进行commit，那么这个时候是不是又要打开之前的redo log文件。或者说再下一次checkpoint的时候，要把之前的redo log打开吗？在052教材上看到这么一段话
A checkpoint guarantees that as of a particular time, all data changes made up to
a particular SCN, or System Change Number, have been written to the datafiles by
DBWn. In the event of an instance crash, it is only necessary for SMON to replay
the redo generated from the last checkpoint position. All changes, committed or
not, made before that position are already in the datafiles; so clearly, there is no need to use redo to reconstruct the transactions committed prior to that. Also, all changes made by uncommitted transactions prior to that point are also in the datafiles—so there is no need to reconstruct undo data prior to the checkpoint position either; it is already available in the undo segment on disk for the necessary rollback.
1. DBWR 超时，大约3秒
2.系统中没有多的空缓冲区来存放数据
3. CKPT进程触发DBWR所以数据commit的数据不是放在redo log里，redo log只是记录用户做了什么操作。 数据是存放在缓冲区的。 所以归档之后的日志不是再次打开的，覆盖的话就没有之前的记录了. 不过可以用Logminner 来分析这些日志记录找到有关的信息。所以生产系统都采用归档模式All changes, committed or not, made before that position（SCN） are already in the datafiles
>这个论点有点疑惑，如果所有的数据都存放在缓存区，redo log只记录用户做什么操作。万一instance非法中断，那这些commit之后这些数据不是丢失了？ 还能恢复到commit得数据？
checkpoint得时候会把上一个checkpoint以后所有的数据都写进数据文件。为了数据统一，有undo操作。Well, just to clarify, log writer is writing committed and uncommitted transactions from the redo log buffer to the log files more or less continuously - not just on commit (when the log buffer is 10mb full, 1/3 full, every 3 seconds or every commit - whichever comes first - those all trigger redo writes). And DBWR is more or less continuously checkpointing these days - with fast start mttr target and the other log related parameters, dbwr is flushing dirty blocks to disk more or less "all of the time". There is this major event called a checkpoint, but it is more of a er than anything else since the work is ongoing. 1) because you can do transactions that are much larger than available memory - there isn't room to buffer it all. That and the fact that if you saved it all up, a commit could take a very very very long time - we want to get ahead of the curve. You can have transactions that are much larger than available memory. You can have transactions that are much larger than available online redo log (which leads to #2 in a second) You want commit times (we optimize for commit, we do not plan on rolling back, rolling back is the EXCEPTION, not the rule, commits are the rule) to be flat - even - regardless of transaction size (it takes about the same amount of time to commit 1 row update as it does a 1,000,000 row update)
2) DBWR will write out dirty blocks onto disk in order to a) allow an online redo log file to be reused, if it did not put the block safely onto disk - we could not reuse the redo log file (that contains the redo to redo the changes). If we cannot reuse the redo log file - we would STOP DEAD. Hence, since stopping dead in our tracks is a bad thing, we put the dirty blocks onto disk so we can reuse the redo information. b) make more space in the buffer cache, you can have modifications that exceed the available SGA by many times. Also, we are multi-user so many people can be doing things at once. We cannot be constrained by memory limitations c) limit the time it takes to recover from a crash. Say we were doing a big update and updated ton of information. We commit. We crash immediately after the commit. If DBWR left all of the dirty blocks in the cache, we'd have to wait during startup for that transaction to be replayed - that could take a long time. In order to reduce the mean time to repair the database after a crash - we have things like the fast_start_mttr_target