oracle 回滚段 RBS 对ORA 01555的精彩解释
假设有张表，叫table1，里面有5000万行数据，假设预计全表扫描1次需要1个小时，我们从过程来看：
1、在1点钟，有个用户A发出了select * from table1;此时不管将来table1怎么变化，正确的结果应该是用户A会看到在1点钟这个时刻的内容。这个是没有疑问的。
2、在1点30分，有个用户B执行了update命令，更新了table1表中的第4000万行的这条记录，这时，用户A的全表扫描还没有到达第4000万条。毫无疑问，这个时候，第4000万行的这条记录是被写到了回滚段里去了的，我假设是回滚段RBS1，如果用户A的全表扫描到达了第4000万行，是应该会正确的从回滚段RBS1中读取出1点钟时刻的内容的。
3、这时，用户B将他刚才做的操作commit了，但是这时，系统仍然可以给用户A提供正确的数据，因为那第4000万行记录的内容仍然还在回滚段RBS1里，系统可以根据SCN来到回滚段里找到正确的数据，但是大家注意到，这时记录在RBS1里的第4000万行记录已经发生了一点重大的改变：就是这个第4000万行的在回滚段RBS1里的数据有可能随时被覆盖掉，因为这条记录已经被提交了！！！
4、由于用户A的查询时间漫长，而业务在一直不断的进行，RBS1回滚段在被多个不同的tracnsaction使用着，这个回滚段里的extent循环到了第4000万行数据所在的extent，由于这条记录已经被标记提交了，所以这个extent是可以被其他transaction覆盖掉的！
5、到了1点40分，用户A的查询终于到了第4000万行，而这时已经出现了第4条说的情况，需要到回滚段RBS1去找数据，但是已经被覆盖掉了，于是01555就出现了。
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/jamex/archive/2009/12/15/5009843.aspx
相关文档：
之前在项目中用到的分页都是假分页，也就是先从数据库中把所有的数据都查询出来然后在绑定时进行分页。这是一种假分页，效率较低，前几天听其他项目组说他们要使用数据库的存储过程来实现分页，感觉很疑惑，难道使用数据库还可以实现分页功能？闲来无事，就从网上搜了搜资料，果然，在oracl ......
甲骨文已经完成了对SUN公司的收购，于1月27日发布了对Sun各项业务的整合规划。总体上说，Oracle要成为软硬件一体化的整体解决方案的厂商。 以下就其对备受关注的Java方面的策略做个介绍。
Java SE:
1）推出JDK SE 7， 它将包括多个新的功能，如提高开发人员的效率，提供高性能，对多核芯片的支持等。
2）Sun的HotSpot ......
一。查看oracle数据库是否为归档模式：
1.select name,log_mode from v$database;
NAME LOG_MODE
------------------ ------------------------
QUERY NOARCHIVELO ......
1）从使用上来说，oci必须在客户机上安装oracle客户端或才能连接，而thin就不需要，因此从使用上来讲thin还是更加方便，这也是thin比较常见的原因。
2）原理上来看，thin是纯java实现tcp/ip的c/s通讯；而oci方式,客户端通过native java method调用c library访问服务端，而这个c library就是oci(oracle called interface ......
