高频错误:ORA-01555深入剖析

黄玮(Fuyuncat)

资深Oracle DBA,个人网站www.HelloDBA.com,致力于数据库底层技术的研究,其作品获得广大同行的高度评价.

ORA-01555(快照过旧)问题让很多人感到十分头痛。最近我们的生产系统上也报出了ORA-01555错误。就结合这次案例将ORA-1555问题作个案例分析,并浅析产生原因和各种解决办法。

如果要了解1555错误产生的原因,就需要知道ORACLE的两个特性:一致性读(Consistent Get)和延迟块清除(Delayed Block Cleanout)。此外,还要知道关于回滚段的一些配置参数。

先看下Oracle中关于UNDO有哪些配置参数:

undo_management

回滚段的管理方式。值可以为MANUAL/AUTO。9i中默认是MANUAL,10g中默认是AUTO。

从9i后,回滚段就以表空间的形式管理,并且支持系统自动管理回滚段。一个回滚表空间上可以创建多个回滚段,一个数据库可以创建多个回滚表空间。但是,一个实例(Instance)只能使用一个回滚表空间。

如果undo_management设置为MANUAL,就是手动创建回滚段:

SQL> create rollback segment undo1 tablespace UNDOTBS1;

如果设置为AUTO,Oracle就自动管理回滚段的创建,而手工创建就会失败。

undo_retention

这个参数设置回滚段中的被提交或回滚的数据强制保留时间,单位是秒。请注意,这个参数和1555错误有非常大的关系。但是,需要提醒的是,并不是回滚段中的数据超过这个时间以后就会被清除掉,而是等到后面事务产生的回滚数据覆盖掉“超期”数据。所以这就是为什么我们往往看到系统的回滚表空间占有率始终是100%的原因了。

undo_suppress_errors

是否报与回滚段有关的错误。如果为FALSE,就不会产生与回滚段有关的错误。但是,请注意,并不是不会发生回滚段错误,而只是屏蔽错误信息,错误发生了就会存在滴。在10g中,这个参数是隐含参数。

undo_tablespace

为每个实例制定的唯一当前使用的回滚段表空间。

一致性读(Consistent Get)

一致性读(Consistent Get)可以说是产生1555错误的主要原因。但它的确是Oracle一个非常优秀的特性。既然这个特性会产生这么烦人的错误,我为什么还说它是ORACLE十分优秀的特性呢?下面就先了解一下这个特性:

并发事务和脏读

需要先了解一下这一特性的产生的背景原因。看下以下这个例子。在一个银行系统中(一般涉及到钱的问题对并发事务要求是最严格的^_^),会计正在统计当月某地区的个人存款总额,她的这个操作,在后台肯定要产生一条SQL语句,对这一地区的所有用户的存款额作SUM(),我们假设这一操作产生的语句为A,时间点是T1。由于存款用户非常多,再加上会有一些对其他表的JOIN条件,语句A的执行时间可能比较长。这时,在A的执行过程中,A已经统计了账户X的钱,但还没有统计到账户Y的钱的时候,正好有一个客户通过ATM机从账户X中转250元钱到帐户Y,他的操作也产生了一条语句B,对存款表进行更新。开始时间点是T2,结束时间是T3。因为只更新两条记录,这个过程非常短。A结束时的时间点是T4。让我们看下过程图,看看会产生什么结果:

从图中,我们可以看到,T2时刻A已经统计过帐户X中的钱,但在这时B从X中转了250元到帐户Y中,在B结束的时刻T3,A还没有统计到Y,但Y已经多出了250元了,所以到T4,统计结束时,A实际上多统计出250元。这就是并发事务中的“脏读(dirty read)”问题。

在标准SQL中,为了防止并发事务中产生脏读,就需要通过加锁来控制。这样就会带来死锁、阻塞的问题,即时是粒度最小的行级锁,也无法避免这些问题。再看下上面这个例子。为了防止脏读,A在开始时就需要对表加锁,防止其他事务更新表。这样,B就会被阻塞,假如A事务要执行1个小时,B可能最长就要被阻塞1个小时。再看下图,

从图中,可以看到,B开始时,存款表被加锁了,所以B被A阻塞,只有等A释放锁以后,B才能更新表。所以B被阻塞了很长时间。在大量并发事务系统中,可能会使整个系统慢得不可想象。

一致性读

为了解决这一矛盾。Oracle充分利用的回归段,通过会滚段进行一致性读取,即避免了脏读,又大大减少了系统的阻塞、死锁问题。

下面就看下Oracle是如何实现一致性读的:

当Oracle更新数据块(Data Block Oracle中最小的存储单位)时,会在两个地方记录下这一更新动作。一个是重做段(Redo Segment),是用于数据库恢复(Recover)用的。一个是回滚段(UNDO Segment),而回滚段是用于事务回滚(Rollback)的(我们只关心回滚段了)。并在数据块头部标示出来是否有修改数据。一个语句在读取数据快时,如果发现这个数据块是在它读取的过程中被修改的(即开始执行读操作时并没有被修改),就不直接从数据块上读取数据,而是从相应的回滚段条目中读取数据。这就保证了最终结果应该是读操作开始时的那一时刻的快照(snapshot),而不会受到读期间其他事务的影响。这就是Oracle的一致性读,也可以叫做多版本(Multi-Versioning)。

以上面的例子为例,A在读取到Y帐户时,发现这条记录已经被修改了,于是就从回滚段读取保留的回滚数据,最终就能正确得到T1时刻的正确存款总额了。看下图:

从图上看出,A即能得出正确的数据,又保证B不会被阻塞。

延迟块清除

再介绍一下另外一个可能产生1555错误的概念——延迟块清除(Delayed Block Cleanout)。但个人认为,如果不从字面意思上翻译,应该把它叫做延迟锁清除更加让人容易理解一些。

我们知道,当Oracle更新数据块时,会在回滚段(UNDO Segment)记录下这一更新动作。并且产生一个Cleanout SCN,在回滚段中,会产生对应的Transaction ID以及相应的数据记录镜像。并在对应的数据记录上,产生锁标志。在事务提交(commit)前,会在数据块的头部记录下这个Cleanout SCN(Csc)号、Undo Block Address(Uba)和Transaction ID(Xid);并且在在对应Interested Transaction List(Itl)中设置锁标志,记录这个事务在这数据块中产生的锁的数目;同时在对应修改的数据记录上打上行级锁标志,并映射到对应的Itl去。当提交时,并不会一一清除掉所有锁标志,而是给对应的Itl打上相应标志,告诉后面访问该数据块的事务,相应的事务已经提交。这就叫做快速提交(Fast Commit)。而后面访问该数据块的的事务就先检查锁标志和对应的事务状态,如果发现前面的事务没有提交,并且要访问的数据记录被锁住了,就被阻塞;否则就清除相应的锁标志,并提交自己的锁标志,再重复以上动作。这就事延迟块清除。

而如果前面的事务在提交之前buffer cache中的脏数据已经被DBwn进程写回,那么Itl中的事务标志就不会被更新,并且数据块的Itl列表也不会记录下事务的Commit SCN。后面的事务或查询语句访问该数据块时,为了检测是否需要进行一致性读(如果数据块的Itl中记录的提交事务的Commit SCN大于当前访问该数据块的SCN,则需要进行一致性读),就需要通过Undo Block Address和Transaction ID到回滚段的事务信息表中去检查前面事务的状态和它的Commit SCN,确定是否做一致性读,最后将前面事务在该数据块上的标志做一次Cleanout。

下面就举一个例子:

创建测试表:

SQL> create table t_multiver (a number, b number); Table created.

插入测试数据,这时,实际上已经产生了一个对数据块修改的事务:

SQL> insert into t_multiver values (1,1); 1 row created. SQL> insert into t_multiver values (2,2); 1 row created. SQL> insert into t_multiver values (3,3); 1 row created. SQL> SQL> commit; Commit complete

修改记录,并且在commit之前将脏数据写回:

SQL> conn demo/demo Connected. SQL> update t_multiver set b=115 where a=1; 1 row updated. SQL> alter system flush buffer_cache; System altered. SQL> commit; Commit complete.

Dump出数据块:

SQL> alter system dump datafile 5 block 50959; System altered.

看看Dump出来的内容:

其余的内容在我们讨论的这个问题中不需要太关心,主要注意Interested Transaction Slot (ITS) 部分。

CSC:即Cleanout SCN,它是在我们的insert操作事务中产生的。

Flag:事务标志位。由于我们在提交之前将buffer cache手动flush了,所以标志位为空。请注意到,我们这在commit之前DBwn已经写回了脏数据,标志为空。各个标志的含义分别是:

C--- = transaction has been committed and locks cleaned out -B-- = this undo record contains the undo for this ITL entry --U- = transaction committed (maybe long ago); SCN is an upper bound ---T = transaction was still active at block cleanout SCN

可以看到,目前事务标志是----,这是为什么呢?请注意,上面过程在commit之前进行了buffer cache flush,也就是说,oracle进程在改写数据块时,该事务还未提交,也未回滚,所以标志为空。而假如将buffer cache flush放在commit之后,该标致就为--U-,即事务已经提交,但是相应的锁并没有清除(有兴趣可以自己做试验)。所以,看到后面的Lck位(行级锁数目)为1(因为我们修改了1条记录)。

再看每条记录中的行级锁对应Itl条目lb:都是0x1。即Itl中的第一条。

这时,我们重新访问该数据块:

SQL> alter system flush buffer_cache; System altered. SQL> conn demo/demo Connected. SQL> select * from t_multiver; A B ---------- ---------- 1 115 2 222 3 222 SQL> alter system dump datafile 5 block 50959; System altered.

再将数据块内容dump出来:

这时,可以看到,前一事务的Itl条目中,Flag标志为已经被修改为C,即提交完毕,Commit SCN也被获得。锁也已经被清除,其锁Lck的数量也清0。相应的,各条记录的行锁对应Itl位也被清0。

图解一下这个过程:

数据块初始状态:

第一个修改该数据块的事务提交后:

第二个访问该数据块的事务(清除了相应锁信息)

当然,如果事务进行的删除操作,或者事务回滚,又会有一些不同的情况。

后面的分享中将会继续解答ora-01555错误发生的场景和解决方案

原文发布于微信公众号 - 数据和云(OraNews)

原文发表时间:2016-08-25

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏祝威廉

Spark Streaming 数据产生与导入相关的内存分析

我这篇文章会分几个点来描述Spark Streaming 的Receiver在内存方面的表现。

723
来自专栏三丰SanFeng

Linux64位程序移植

1 概述 Linux下的程序大多充当服务器的角色,在这种情况下,随着负载量和功能的增加,服务器所使用内存必然也随之增加,然而32位系统固有的4GB虚拟地址空间限...

1887
来自专栏灯塔大数据

技术 | Python从零开始系列连载(二)

上一期学的upyter相信大家都已经会用了,我们这一期就可以愉快地学习写代码啦! Python的基本数据类型 数据类型在数据结构中的定义是一个值的集合以及定义在...

3426
来自专栏分布式系统和大数据处理

四种简单的排序算法

我觉得如果想成为一名优秀的开发者,不仅要积极学习时下流行的新技术,比如WCF、Asp.Net MVC、AJAX等,熟练应用一些已经比较成熟的技术,比如Asp.N...

752
来自专栏皮振伟的专栏

[linux][memory]hugetlb和hugepage技术分析

前言: 乍一看,hugetlb和hugepage还挺像的,好像都是所谓的“大页”。然而,却很难说出来它们的差异。作者也是花了写时间翻翻代码,写了几个测试的例子,...

3927
来自专栏Spark学习技巧

Kafka源码系列之Broker的IO服务及业务处理

Kafka源码系列之Broker的IO服务及业务处理 一,kafka角色 Kafka源码系列主要是以kafka 0.8.2.2源码为例。以看spark等源码的经...

23110
来自专栏Linux驱动

协处理器CP15介绍—MCR/MRC指令(6)

概述:在基于ARM的嵌入式应用系统中,存储系统的操作通常是由协处理器CP15完成的。CP15包含16个32位的寄存器,其编号为0~15。 而访问CP15寄存器的...

2459
来自专栏JAVA技术zhai

JVM虚拟机详解

  JVM是Java Virtual Machine(Java虚拟机)的缩写,JVM是一种用于计算设备的规范,它是一个虚构出来的计算机,是通过在实际的计算机上仿...

1022
来自专栏京东技术

Vitess告诉你两阶段提交到底长啥样

● 原子性:一个事务对状态的改变是原子的,要么都发生,要么都不发生,这些改变包括数据库的改变、消息以及对转换器的操作。

1422
来自专栏移动端开发

iOS 从实际出发理解多线程

前言 ----       多线程很多开发者多多少少相信也都有了解,以前有些东西理解的不是很透,慢慢的积累之后,这方面的东西也需要自己好好的总结一下。多线程从我...

1977

扫码关注云+社区