4点 E文解释如下: The change in the log_buffer value is expected behaviour. The value of log_buffer from v$spparameter gives you the value which you have set in the spfile; The value from show sga, show parameter, v$sgastat, v$parameter are different than which you have set because this is not a minimum limit for redo buffer size, Oracle combines fixed SGA area and redo buffer together, if there is a free space after Oracle put combined buffer to fit in granule, that space is added to redo buffer. Thus you see redo buffer has more space as expected. This is an expected behavior.
sqlplus exit后，如果没有执行过 set autocommit on;事务均自动rollback。开始关闭计算机，OS是会关闭服务，关闭服务，这个当然会触发checkpoint
SQL> show user USER is "SCOTT" SQL> select * from dept; DEPTNO DNAME LOC ---------- -------------- ------------- 10 ACCOUNTING NEW YORK 20 RESEARCH DALLAS 30 SALES CHICAGO 40 OPERATIONS BOSTONSQL> show autocommit; autocommit OFF SQL> show parameter auto ORA-00942: table or view does not exist SQL> insert into dept values(55,'a','a') 2 ;1 row created.SQL> select * from dept; DEPTNO DNAME LOC ---------- -------------- ------------- 55 a a 10 ACCOUNTING NEW YORK 20 RESEARCH DALLAS 30 SALES CHICAGO 40 OPERATIONS BOSTONSQL> exit Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.1. oduction With the Partitioning, OLAP and Data Mining optionsC:\Documents and Settings\Admin>sqlplus scott/tigerSQL*Plus: Release 10.2.0.1.0 - Production on Mon Sep 28 10:23:42 2009Copyright (c) 1982, 2005, Oracle. All rights reserved. Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production With the Partitioning, OLAP and Data Mining optionsSQL> select * from dept; DEPTNO DNAME LOC ---------- -------------- ------------- 55 a a 10 ACCOUNTING NEW YORK 20 RESEARCH DALLAS 30 SALES CHICAGO 40 OPERATIONS BOSTONSQL> 好像不对啊老大
exit再登陆进去那条insert的记录还在呀 没有rollback
如果是纯sqlplus的环境的话，推出session是不会commit的，这是肯定的。有一些客户端只所以会commit是，客户端本身的配置上的设置，plsql dev和青蛙都有这样的设置。 比如plsql dev可以找到这个设置 preference->oracle->connection->logoff with open transaction 不清楚你上面的实验是如何做的。如果在事务后面出现了ddl语句或者是dcl语句，都会直接提交事务，破坏事务的完整性的，不知道是不是这个导致的。你多试试。
直接关机时发生CHECKPOINT吗？
话说在数据库关闭的时候会发生CHECKPOINT,以保证脏数据都写到数据文件中。可有的时候我在SQL*PLUS里完成操作后并不会使用SHUTDOWN关闭，而是直接exit推出，完了就直接关电脑了。这个时候会发生CHECKPOINT吗？（应该会的哦，因为我每次重新开机并没提示我有什么错）
直接掉电关机，还是正常关机阿?
掉电关机的话相信肯定是没有做checkpoint的，这个时候脏数据没有写回数据文件。
正常关机的话如果你在操作系统级别设置了，操作系统会帮你停应用的，看alert.log可以看到数据库其实还是
做了一个shutdown 操作的。如果做了shutdown 操作，是会做checkpoint的。
重新开机没提示你有什么错误，表示上次数据库一定成功做了checkpoint吗？话说数据库开机的时候，如果发现发生了不正常关机，会做一个instance recovery，这个操作是由oracle 的smon来执行的，smon会做一个前滚，再作一个回滚操作，这个执行过程中不需要有用户的干扰。所以开服务的时候不会
报错。
E文解释如下:
The change in the log_buffer value is expected behaviour.
The value of log_buffer from v$spparameter gives you the value which you have set in the spfile; The value from show sga, show parameter, v$sgastat, v$parameter are different than which you have set because this is not a minimum limit for redo buffer size, Oracle combines fixed SGA area and redo buffer together, if there is a free space after Oracle put combined buffer to fit in granule, that space is added to redo buffer. Thus you see redo buffer has more space as expected. This is an expected behavior.
估计是在关机的过程中OS会去停止响应的服务，也就把数据库给关闭了。
同样的，启动服务的时候在ALERT LOG中也会多一条STARTUP的记录。
LZ说到的disk sort其实就是用的临时表空间的临时表来排序,每次从内存把待排序的内容放入临时表,内存空间的数据和临时表空间的数据采用了一个merge的操作.
关于这个在itpub上有个热烈讨论过的帖子,lz有兴趣可以关注一下
http://www.itpub.net/84823.html
其实在一个TRANSACTION中并是在COMMIT的时候才提交。当每过一段时间，系统会直接提交一次，所以第二个问题，一个写日志进程就够了。
愚见，希望有帮助。
直接关机，是不会checkpoint 的！
你电脑重启开机后，oracle 就会自己redo/undo 3：ARCn有多个解发条件：每三秒会自己归档
当到达 logBuffer的三分之一
commit 时 还有Arcn是顺序写，速度比较 快
当有transaction没有提交就直接关闭数据库，是不会有CHECKPOINT的，所有的操作相关都存放在UNDO,REDO里面，当系统重启后就会读这个地方有无需要回滚/提交的数据，提示用户是提交还是回滚。但是，如果你是直接关机，这两个地方的数据就会被清空，所以你重启电脑后没有提示你什么东西。
愚见，希望有帮助。
<1> 基本思想 合并排序的算法就是二分法。
分解：将n个元素分解成各含 一半元素的子序列。
解决：用合并排序法对两个子序列递归地排序。
合并：合并两个已排序的子序列排序结果。
在对子序列排列时，当其长度为1时递归结束，因为单个元素被认为是已排好序的.合并排序的.合并排序的关键步骤在于合并目前产生的两个已排好序的子序列:
A[p..q] 和 A[q+1…r];
将它们合并成一个已排好序的子序列A[p..r]. 我们引入一个辅助过程merge(A,p,q,r)来完成这一项合并工作,其中A是数组,p,q,r是下标
可是我昨晚试了一下 直接退出SQL*PLUS 并没有使用SHUTDOWN关闭数据库
在我重启计算机后查看ALERT.LOG里是多了一条SHUTDOWN记录的
我认为是在重新启动计算机的过程中操作系统会自动关闭打开的ORACLE服务 例如OracleServiceORCL
这个时候可能就发生了SHUTDOWN操作
先REDO(重做已提交的何未提交的) 再UNDO(回滚未提交的)
如果想试的话，用shutdown abort就可以叻。试之前记得备份或者把所有事务都提交以后在来，要不然，这时候在遇到个突发事情，你的数据库就叫天不应，叫地地不灵了。
顺便问一下
有没有什么地方可以查看CHECKPOINT发生的记录信息呢?
有的话查一下就知道直接关电脑的时候有没有发生CHECKPOINT了嘛
Mon Sep 28 08:10:21 2009
Completed checkpoint up to RBA [0xa7d.2.10], SCN: 9455233800127
Mon Sep 28 08:20:19 2009
Incremental checkpoint up to RBA [0xa7d.144.0], current log tail at RBA [0xa7d.19b.0]
~
~
记录checkpoint的地方有很多，比如v$database, v$datafile; v$log_his .... 不过这里不同的地方的scn都一样是同样的意义，不过是作用于不同的对象而已。你直接关闭电脑，是正常关机还是断电叻。shutdown abort类似断电，这时候，这时候，中间数据是不会回滚也不会提交的，所有的事务是中间状态，只有等我们的数据库在重启(如果还没有损害的话，主要是redo和归档已经controlfile)以后redo后undo叻。
问题二
当然。不仅是正常关机，只要是有触发一个全局的检查点，都会发生checkpoint。问题三
Lgwr的写频率是比较好的，我记得好像是3秒钟触发一次，或者是redo buffer的内容达到1/3或者redo buffer数据达到1M 都会触发，所以这个lgwr触发是很频繁的，这个具体可以参考一下网上的资料，所以log buffer不会很大，推荐是3M而已。这里技术上完全是可以多线程来做的，但是可能Oracle并不觉得这里有很大的价值，而且也不需要为之增加复杂度，有时候简单是美。问题四
ls的有一个兄弟已经回答的很完整了。鼓励学习讨论贴。 管理这方面的需要多讨论，多谈自己的想法。
就是在SQL*PLUS中EXIT后
开始-关闭计算机
我们知道了checkpoint会刷新脏数据，但什么时候会发生checkpoint呢？以下几种情况会触发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的时候;三：增量检查点（incremental checkpoint）
oracle8以后推出了incremental checkpoint的机制，在以前的版本里每次checkpoint时都会做一个full thread checkpoint,这样的话所有脏数据会被写到磁盘，巨大的i/o对系统性能带来很大影响。为了解决这个问题，oracle引入了checkpoint queue机制，每一个脏块会被移到检查点队列里面去，按照low rdb（第一次对此块修改对应的redo block address）来排列，靠近检查点队列尾端的数据块的low rba值是最小的，而且如果这些赃块被再次修改后它在检查点队列里的顺序也不会改变，这样就保证了越早修改的块越早写入磁盘。每隔3秒钟ckpt会去更新控制文件和数据文件，记录checkpoint执行的情况。增量检查点并不去更新数据文件头，只是在控制文件中记录了checkpoint progress record这个区域，记下low rba,on-disk rba等信息。这些信息就可以用来快速恢复。
set autocommit on;事务均自动rollback。开始关闭计算机，OS是会关闭服务，关闭服务，这个当然会触发checkpoint
USER is "SCOTT"
SQL> select * from dept; DEPTNO DNAME LOC
---------- -------------- -------------
10 ACCOUNTING NEW YORK
20 RESEARCH DALLAS
30 SALES CHICAGO
40 OPERATIONS BOSTONSQL> show autocommit;
autocommit OFF
SQL> show parameter auto
ORA-00942: table or view does not exist
SQL> insert into dept values(55,'a','a')
2 ;1 row created.SQL> select * from dept; DEPTNO DNAME LOC
---------- -------------- -------------
55 a a
10 ACCOUNTING NEW YORK
20 RESEARCH DALLAS
30 SALES CHICAGO
40 OPERATIONS BOSTONSQL> exit
Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.1.
oduction
With the Partitioning, OLAP and Data Mining optionsC:\Documents and Settings\Admin>sqlplus scott/tigerSQL*Plus: Release 10.2.0.1.0 - Production on Mon Sep 28 10:23:42 2009Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining optionsSQL> select * from dept; DEPTNO DNAME LOC
---------- -------------- -------------
55 a a
10 ACCOUNTING NEW YORK
20 RESEARCH DALLAS
30 SALES CHICAGO
40 OPERATIONS BOSTONSQL>
好像不对啊老大
如果是纯sqlplus的环境的话，推出session是不会commit的，这是肯定的。有一些客户端只所以会commit是，客户端本身的配置上的设置，plsql dev和青蛙都有这样的设置。
比如plsql dev可以找到这个设置 preference->oracle->connection->logoff with open transaction
不清楚你上面的实验是如何做的。如果在事务后面出现了ddl语句或者是dcl语句，都会直接提交事务，破坏事务的完整性的，不知道是不是这个导致的。你多试试。
我刚才又去试了下
用EXIT正常退出的话是COMMIT了
如果直接点右上角的叉叉关闭掉SQL*PLUS就ROLLBACK了