深度解析 ORA-01555 原因及解决方法

两种原因:

  1. 一致读 ,CR (consistency Read)
    查询修改数据的前镜像时,前景镜像被覆盖。
  2. 块延迟清理
事务工作步骤
Transaction 开始前 回滚段获取一个ITL(事务槽),分配空间, 记录事务信息
Transaction 提交后,redo完成记录,同时还清除回滚段的事务信息 包括行级锁,ITL信息(commit 标志,SCN等)

清除这些事务段的信息的过程就叫做 块清除, 在完成块清除时, 我们本事务修改的数据块就会存在两种可能
    (1) 所有的数据块还保存在 buffer  cache 中, 
    (2)部分数据块或者是全部数据块由于LRU管理已经被刷出了buffer cache。oracle为了考虑到块清除的成本,以及性能,会作以下两种方式的块清除处理:
     快速块清除(fast block cleanout),  当事务修改的数据库全部保存在buffer cache 并且修改数据块的数据量没有超过 cache buffer  的 10%,快速清除事务信息。 
     延迟块清除(delayed block cleanout) 当修改的数据块的阀值超过10%  或者本次事务相关的数据块已经被刷出了 buffer cache, oracle 会下次访问此block 时再清除事务信息。

接下来,下一个select(读者)去读延迟块。

  1. 如果select 可以找到回滚段中记录的commit 时的SCN,那么延迟块正常清除,出现select产生redo的情况。
  2. 如果select 找不到commit时的SCN,证明需要清理commit的已经被回收。顺序为:
    需要清理的scn(已被回收) < 能找到的最小事务的scn
    这时候就需要分析现在select的SCN 在哪个位置:
    2.1: select的SCN > 回滚段中最小的scn,及在最小scn之后, 那么完成块清理。
    2.2 :select的SCN < 回滚段中最小的scn, 就是还是小于最小的scn 即还是找不到。就发生ORA-01555. oracle 会做设置需要清理的scn(已被回收) = 能找到的最小事务的scn。

++++++++++++++++++++++++

下面简单讲下ORA-1555的处理方法:

在磁盘空间不充足,可以调整undo_retention                                  
SELECT d.undo_size/(1024*1024) "ACTUAL UNDO SIZE [MByte]",
       SUBSTR(e.value,1,25) "UNDO RETENTION [Sec]",
       ROUND((d.undo_size / (to_number(f.value) *
       g.undo_block_per_sec))) "OPTIMAL UNDO RETENTION [Sec]"
  FROM (
       SELECT SUM(a.bytes) undo_size
          FROM v$datafile a,
               v$tablespace b,
               dba_tablespaces c
         WHERE c.contents = 'UNDO'
           AND c.status = 'ONLINE'
           AND b.name = c.tablespace_name
           AND a.ts# = b.ts#
       ) d,
       v$parameter e,
       v$parameter f,
       (
       SELECT MAX(undoblks/((end_time-begin_time)*3600*24))
              undo_block_per_sec
         FROM v$undostat
       ) g
WHERE e.name = 'undo_retention'
  AND f.name = 'db_block_size';


在磁盘充足,保证undo_retention不变,调整undo_size
SELECT d.undo_size/(1024*1024) "ACTUAL UNDO SIZE [MByte]",
       SUBSTR(e.value,1,25) "UNDO RETENTION [Sec]",
       (TO_NUMBER(e.value) * TO_NUMBER(f.value) *
       g.undo_block_per_sec) / (1024*1024) 
      "NEEDED UNDO SIZE [MByte]"
  FROM (
       SELECT SUM(a.bytes) undo_size
         FROM v$datafile a,
              v$tablespace b,
              dba_tablespaces c
        WHERE c.contents = 'UNDO'
          AND c.status = 'ONLINE'
          AND b.name = c.tablespace_name
          AND a.ts# = b.ts#
       ) d,
      v$parameter e,
       v$parameter f,
       (
       SELECT MAX(undoblks/((end_time-begin_time)*3600*24))
         undo_block_per_sec
         FROM v$undostat
       ) g
 WHERE e.name = 'undo_retention'
  AND f.name = 'db_block_size'
  • 1
    点赞
  • 7
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
kettle ora-01555是指在使用kettle工具进行数据抽取或转换时,出现了Oracle数据库的ORA-01555错误。ORA-01555错误是Oracle数据库的一个常见错误,也被称为Snapshot too old错误。 ORA-01555错误是由于事务回滚段中的数据被其他事务重用或者已经被覆盖而导致的。这种情况通常发生在并发事务环境下,当一个事务需要读取某些数据,但是在读取期间该数据已经被其他事务修改或删除,导致该事务无法读取到所需的数据而出现ORA-01555错误。 在kettle中,当进行数据抽取或转换时,kettle会同时执行多个SQL语句以读取或修改数据库中的数据。如果在执行这些SQL语句的过程中,有其他事务修改了这些数据,那么就有可能导致ORA-01555错误的发生。 为了解决ORA-01555错误,可以考虑以下几个方案: 1. 增加Rollback段的大小:可以通过增大回滚段的大小来解决ORA-01555错误。通过增加回滚段的大小,可以延长数据被重用的时间,从而减少ORA-01555错误的发生。 2. 设置合适的UNDO_RETENTION参数:可以通过设置UNDO_RETENTION参数来控制回滚段中数据的保留时间。增加UNDO_RETENTION的值可以延长数据被重用的时间,减少ORA-01555错误的发生。 3. 调整事务隔离级别:可以尝试调整事务的隔离级别,例如将隔离级别改为READ_COMMITTED,可以降低ORA-01555错误的发生概率。 此外,还可以根据具体情况进行其他的优化措施,例如优化SQL语句、调整并发事务的执行顺序等,以减少ORA-01555错误的发生。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

东方-phantom

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值