转：Oracle 一致性读的原理
在Oracle数据库中，undo主要有三大作用：提供一致性读（Consistent Read）、回滚事务（Rollback Transaction）以及实例恢复（Instance Recovery）。 一致性读是相对于脏读（Dirty Read）而言的。假设某个表T中有10000条记录，获取所有记录需要15分钟时间。当前时间为9点整，某用户A发出一条查询语句：select * from T，该语句在9点15分时执行完毕。当用户A执行该SQL语句到9点10分的时候，另外一个用户B发出了一条delete命令，将T表中的最后一条记录删除并提交了。 那么到9点15分时，A用户将返回多少条记录？ 如果返回9999条记录，则说明发生了脏读；如果仍然返回10000条记录，则说明发生了一致性读。很明显，在9点钟那个时间点发出查询语句时，表T中确实有10000条记录，只不过由于I/O的相对较慢，所以才会花15分钟完成所有记录的检索。对于Oracle数据库来说，没有办法实现脏读，必须提供一致性读，并且该一致性读是在没有阻塞用户的DML的前提下实现的。 那么undo数据是如何实现一致性读的呢？还是针对上面的例子。用户A在9点发出查询语句时，服务器进程会将9点那个时间点上的SCN号记录下来，假设该SCN号为SCN9.00。那么9点整的时刻的SCN9.00一定大于等于记录在所有数据块头部的ITL槽中的SCN号（如果有多个ITL槽，则为其中最大的那个SCN号）。 服务器进程在扫描表T的数据块时，会把扫描到的数据块头部的ITL槽中的SCN号与SCN9:00之间进行比较，哪个更大。如果数据块头部的SCN号比SCN9.00要小，则说明该数据块在9点以后没有被更新，可以直接读取其中的数据；否则，如果数据块ITL槽的SCN号比SCN9.00要大，则说明该数据块在9点以后被更新了，该块里的数据已经不是9点那个时间点的数据了，于是要借助undo块。 9点10分，B用户更新了表T的最后一条记录并提交（注意，在这里，提交或者不提交并不是关键，只要用户B更新了表T，用户A就会去读undo数据块）。假设被更新记录属于N号数据块。那么这个时候N号数据块头部的ITL槽的SCN号就被改为SCN9.10。当服务器进程扫描到被更新的数据块（也就是N号块）时，发现其ITL槽中的SCN9.10大于发出查询时的SCN9.00，说明该数据块在9点以后被更新了。于是服务器进程到N号块的头部，找到SCN9.10所在的ITL槽。由于ITL槽中记录了对应的undo块的地址，于是根据该地址找到undo块，将undo块中的被修改前的数据取出，再结合N号块里的数据行，从而构建出9点10分�
相关文档：
在某些特殊的情况下，如因为网络或者X配置的关系无法连接到X server或者主机上没有X，就可以使用静默安装的方式安装数据库，同样如果需要大规模部署，则静默安装将会大大减轻DBA的重复劳动力，而且静默安装不需要X，从安装效率
在某些特殊的情况下，如因为网络或者X配置的关系无法连接到X server或者主机上没有X� ......
Oracle中临时表产生过量Redo的说明
最近,在Oracle9i中你用过临时表吗?
它是否给你带来了性能提高?你注意过么?
--------------------------------------------------------------------------------
好了言归正传.
我们知道临时表在DML操作中可以减少redo的生成,从而在保存中间结果集时可以带来较大的性能提高.
可是,� ......
在执行启动关闭命令之前需要正确设置下列环境变量：
ORACLE_BASE
ORACLE_HOME 安装过程中显示的oracle home 目录
ORACLE_SID
PATH=$PAHT：$ORACLE_HOME/bin
以 oracle 账号登陆 Linux，或者从 root 下输入 su - or ......
