1. Redo By Jonathan Lewis
http://jonathanlewis.wordpress.com/2011/08/19/redo-2/
Jonathan Lewis根据来自Tony Hasler的一篇帖子中遇到的问题, 进一步测试,,发现Oracle的Redo机制在ACID设计上的缺陷所做的深入的讨论..
问题的根本点是..
Oracle在进行提交的时候,需要处理3件事情.
1. 将提交的信息持久化到磁盘
2. 通知其它进程此事务已经提交,后续的查询可以查看最新的记录.
3. 通知处理当前事务的进程,此事务已经提交.
Oracle该如何平衡这三个选项..
目前的实现是, 在当前应用发出commit指令并等待log file sync时,,lgwr会接手进行日志的持久化(也即满足ACID的D),,其它会话会看到当前会话已经提交的数据(此处为ACID中的I所指代的READ Committed 隔离级别), 也就是其它会话已经看到此事务为已经提交,,而只有当前会话认为事务还未提交完成,,在正常情况下,,其它会话认为已经提交与当前会话认为已经提交之间的时间间隔会比较小(一般就一次log file parallel write的时间,在0.1-10ms之间), 而当LGWR由于某些原因没有办法正常写日志时(如此blog中的描述,lgwr suspend,或没有可用的在线日志),,这个时间差就可能造成比较大的影响,,主要影响是如果有其它DB会依赖于此DB中的一致性的状态, 并且在当前主机crash的情况下,,会出现违反ACID中的D或I的情况,,如果所有的状态都是依赖于当前数据库,,则不会造成影响,,因为后续的会话依赖的状态以及依赖此状态所做的变更,,必须要等LGWR的下次持久化才会变成持久的变更.
2. 推荐一组关于JBOSS连接池的研究的帖子(来自我们支付宝DBA团队的兄弟).
JBOSS连接池1-PreparedStatementCache参数的作用及设置
JBOSS连接池1-PreparedStatementCache参数的作用及设置
JBOSS连接池研究的后续内容请大家关注dbafree的后续内容.
最近评论