Question

oracle的commit和检查点，对数据查询（scn）结果的影响？

我这边建立了数据表Test: id varchar name varchar ,然后数据为 1 a , 2 b, 3 c, 4 d.
疑问是：我操作delete from Test where id='1';在没有执行手动commit情况下，我手动执行alter system checkpoint,后，再打开一个新sqlplus连接，查看Test表，后看到数据，还是 1 a , 2 b, 3 c, 4 d.
但是在我手动commit后，再新打开的sqlplus连接中，看到的是
2 b, 3 c, 4 d，
我不知道这其中的为什么alter system checkpoint后难道对后面新打开的sqlplus（相当于最新的scn来查看）没有影响？
可以帮我解答一下吗？

Answer 1

commit触发的操作大致三点:1是生成SCN号。2.释放相关锁。3是将log buff内涉及到此次delete操作还未来得及写入redo日志的信息全部写入到redo日志里，log buff一般都不大，默认好像是40MB？再考虑到strand，写入速度很快。所以commit操作非常快。当然commit还是需要时间的，如果commit的过程中数据挂掉了怎么办？所以oracle采用的是日志在先，所有的操作都是先将涉及到的数据块和undo信息组合成redo信息写入到log buff内的。修改数据的操作在你未进行commit的时候就已经做了，只等着你commit确定此次更改了。
checkpoint触发后会产生DBWn进程，用来把内存中的脏数据块写入到数据文件内(包含你未commit的脏数据块)。在commit未提交以至于步骤2里相关锁未释放，slot未释放时，别的session是看不到你做的修改的。

commit和chechpoint是两种不同的操作，如果你非要说吃饭和洗衣服有联系那我也没办法。commit因为是分几步走，虽然耗时很短，但用额外方式hang住commit操作(例如oradebug spid命令)，commit就只能完成1、2步骤，第3步骤无法完成，此时别的session已经可以看到你做的delete操作，但实际你的commit不完全，这个比较罕见的状态叫不完全的事物提交。
不排除以上有错误，欢迎指正。

Answer 2

会的。
Minor GC 都会触发“全世界的暂停（stop-the-world）”，停止应用程序的线程。对于大部分应用程序，停顿导致的延迟都是可以忽略不计的