Welcome 微信登录

首页 / 数据库 / MySQL / undo系列学习之读一致性（ORA-01555错误机制分析）

Oracle在读的过程中，数据是静止的，没有脏读，也就是，未提交的永远都不会被读到。我们可以理解为，Oracle在读的开始时，提前为他今后所要读的内容拍了一张”照片“，把所有内容全部定格在一个时间点上，作为接下来读的依据。Oracle利用scn来实现这个理论，开始查询时，会确定一个select scn，这样就保证了事务槽里所有的scn都小于select scn。好比如，现在是12:21分，那么我之前所敲的字都在12:21分之前做的。我们已经知道，undo段是循环使用，并且，Oracle只会把inactive的事务给覆盖。若是一个长时间的查询需要读到被覆盖的块时，就会报ora-01555错误。借助v$undostat里面的字段ssolderrcnt来查询在每个10分钟，Oracle内是否发生过01555错误。下面是一张01555错误的图：产生01555错误，原因有好多，这里列三个：1）undo_retention不够大2）undo空间压力大3）sql性能差下面我们来模拟01555错误。注意，这里要避免和30036错误相混淆。会话1：
  1. hr@ORCL> var i refcursor  
  2. hr@ORCL> exec open :i for select * from t;  
  3.   
  4. PL/SQL procedure successfully completed.  
  5.   
  6. hr@ORCL> print i;  
  7.   
  8.         ID NAME  
  9. ---------- ----------   
  10.          1 a  
  11.          2 b  
  12.   
  13. hr@ORCL> exec open :i for select * from t;  
  14.   
  15. PL/SQL procedure successfully completed.  
会话2：
  1. sys@ORCL> delete from hr.t;  
  2.   
  3. 3 rows deleted.  
  4.   
  5. sys@ORCL> commit;  
  6.   
  7. Commit complete.  
会话1：
  1. hr@ORCL> print i;  
  2.   
  3.         ID NAME  
  4. ---------- ----------   
  5.          1 a  
  6.          2 b  
如果有数据，则证明查询是修改前的；如果没有数据，则证明查询是修改后的。但如果，此时undo里面没有数据，那就会报错。从查询输出，可知，查询是修改前的。
  • 1
  • 2
  • 下一页
Oracle证明题：未提交的事务也可能被DBWn写进数据文件使用MongoDB开发实践体会相关资讯      undo 
  • Oracle 11g undo_retention 以及  （05月28日）
  • undo表空间使用率  （07/23/2015 16:29:56）
  • undo表空间概述  （02/24/2015 20:32:43）
  • Oracle中利用undo进行数据的恢复操  （11/27/2015 09:31:30）
  • undo表空间修复小结  （07/08/2015 08:43:13）
  • Oracle 11gR2 Database UNDO表空间  （01/29/2015 11:30:59）
本文评论 查看全部评论 （0）
表情： 姓名： 字数