疑难解答:ORA-01555的场景模拟和解决方案

黄玮(Fuyuncat)

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

前期分享了ORA-01555错误的原理及相关基础概念。

参考(高频错误:ORA-01555深入剖析)

今天我们来分析ORA-01555发生的场景和各种解决方案

1555发生的场景

测试环境

首先建立测试环境。由于我们只是要模拟1555错误的发生,所以需要建立一个小的回滚表空间,并且设置undo_retention时间为1(秒),以便回滚数据尽快被覆盖(呵呵,要防止1555错误发生,这就一定要避免的)。

1

一致性读导致的1555错误

开始读取表。

SQL> var cl refcursor SQL> begin open :cl for select * from demo.t_multiver; end; / PL/SQL procedure successfully completed.

更新表数据,产生回滚信息。

SQL> update demo.t_multiver set b = 111 where a = 1; 1 row updated. SQL> commit; Commit complete.

运行大批其他事务,充满所有回滚段,以致覆盖上面的回滚信息。回滚段可以通过dba_rollback_segs查看。

SQL> begin for i in 1..20000 loop update demo.t_dual set dummy=1; commit; end loop; end; / PL/SQL procedure successfully completed. SQL> / PL/SQL procedure successfully completed.

查询到更新过的数据记录,回滚信息已经被覆盖,所以报1555错误。

SQL> print :cl ERROR: ORA-01555: snapshot too old: rollback segment number 18 with name "_SYSSMU18$" too small no rows selected

2

延迟块清除导致的1555错误

开始读取表

SQL> var cc refcursor SQL> SQL> begin open :cc for select * from t_multiver; end; /

这时一个事务更新了该数据块,但在提交前,我们手工将buffer cache中的数据做了flush,再做提交。这时的数据块上只记录了锁标志,没有事务标志和Commit SCN。

PL/SQL procedure successfully completed. 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.

进行非常多的事务,将回滚段中的事务信息表中的数据全部覆盖:

SQL> begin -- overwrite rollback slot for i in 1..40000 loop update t_dual set dummy=1; commit; end loop; end; / PL/SQL procedure successfully completed.

读取数据块前需要到回滚段的事务信息表中读取Itl中没有标记完全的事务的状态和Commit SCN,以判断是否需要进行一致性读。但是事务信息表中的数据都已经被覆盖,所以报1555错误:

SQL> print :cc ERROR: ORA-01555: snapshot too old: rollback segment number 20 with name "_SYSSMU20$" too small no rows selected

以上两个例子看起来是好像很类似,但是,他们的本质区别是:第一个实际上是在进行一致性读得时候发生的1555错误,而第二个例子是在判断是否需要进行一致性读得时候发生的1555错误。

解决1555错误的方法

现在,我们已经知道了1555错误产生的原因。那么,就可以总结出以下方法来解决1555错误问题:

1、扩大回滚段

因为回滚段是循环使用的,如果回滚段足够大,那么那些被提交的数据信息就能保存足够长的时间是那些大事务完成一致性读取。

2、增加undo_retention时间

在undo_retention规定的时间内,任何其他事务都不能覆盖这些数据。

3、优化相关查询语句,减少一致性读

减少查询语句的一致性读,就降低读取不到回滚段数据的风险。这一点非常重要!

4、减少不必要的事务提交

提交的事务越少,产生的回滚段信息就越少。

5、对大事务指定回滚段

通过以下语句可以指定事务的回滚段:

SET TRANSACTION USE ROLLBACK SEGMENT rollback_segment;

给大事务指定回滚段,即降低大事务回滚信息覆盖其他事务的回滚信息的几率,又降低了他自身的回滚信息被覆盖的几率。大事务的存在,往往是1555错误产生的诱因。

6、使用游标时尽量使用显式游标并且只在需要的时候打开游标,同时将所有可以在游标外做的操作从游标循环中拿出。

当游标打开时,查询就开始了,直到游标关闭。减少游标的打开时间,就减少了1555错误发生的几率。

下面例子中,第一段代码发生1555错误的几率就大于第二段的:

例子一

declare cursor cl is select b from demo.t_multiver; v_b number; begin open cl; --do some thing without relation to the cursor. fetch cl into v_b; while cl%found loop --do other things without relation to the cursor. ... ... fetch cl into v_b; end loop; close cl; commit; END;

例子二:

declare cursor cl is select * from demo.t_multiver; begin --do some thing without relation to the cursor. --do other things without relation to the cursor. open cl; fetch cl into v_b; while cl%found loop ... ... fetch cl into v_b; end loop; close cl; commit; END;

7、使用回滚表空间自动管理

回滚表空间自动管理是9i后的特性。他由Oracle自动管理回滚段的创建和回收。尽管有人认为这一特性是以后牺牲性能为代价的,或者有其他缺点而不建议使用。但我认为,这确实是Oracle一个很好的特性,特别是OLTP环境下应该使用它。并且10g中,这一特性大大增强了。

而在大型的数据仓库或者报表系统中,会有一些很大的查询作业存在,这时可以考虑使用手动管理,为某些大作业创建单独的回滚段。

以上总结了解决1555错误的各种办法,具体采用哪种方式,就需要根据错误产生的实际情况来决定了。

实例分析

实际上,你在了解了1555错误为什么会发生的前提,遇到了1555错误就不应该再手足无措了。但是,根据我个人的经验,大多数的1555错误的发生,其根本原因还是语句写得太烂,导致了大量的consistent gets和超长的执行时间,最后引发了1555错误。下面就是一个典型例子:

错误的发生

近来生产系统反馈,时常有作业被异常中止,导致应用程序被hung住。经过检查日志,是某个作业在运行时发生了1555错误,导致程序无法返回结果:

相关程序记录下的日志:

错误分析解决

这是一个典型的1555错误。检查引发该错误的PACKAGE,发现它只有一个入口函数main(及程序日志中记录的函数),但这个函数还调用了其他N个PACKAGE里面的函数。这是一个大作业,执行时,设置它使用了一个大的回滚段:RBS_BATCH1。

先看看相关配置:rollback tablespace空间为8G,undo_retention为1800。

看看回滚段的统计数据:

注意到RBS_BATCHT1的wait%是0.098%,这个值应该是比较好的一个值。

回过头再来看依法错误的语句:调用ext_pkg.main函数。在程序日志中已经记录下了输入参数,这就比较好办了:作一个trace,看看到底哪条语句的性能最差:

用tkprof处理trace文件后检查trace文件:

......

......

......

从trace文件中,发现有一条语句性能相当差,通过对这条语句做SQL Trace,发现它的consistent gets达到80万!

于是对该语句进行优化,调整了它的写法,并建立了缺少的索引(优化过程略)。最终将consistent gets数量降低到了5000。

重新安排上线,经过一周的观察,1555错误没再发生。

其实这个案例的解决是比较简单的,最终的处理就是将一条语句进行优化。

-------The End

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

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

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏腾讯技术工程官方号的专栏

Elasticsearch调优实践

6525
来自专栏何俊林

Android app内存管理的16点建议

前言:内存管理,在iOS开发中和C++开发中可以说是天天提到。对于Android平台,Google其实早有文档说明,本文翻译自Google官方文档,如有不正确,...

3537
来自专栏IMWeb前端团队

react 的数据管理方案:redux 还是 mobx?

本文作者:IMWeb jerytang 原文出处:IMWeb社区 未经同意,禁止转载 mobx 简介 和 redux 类似,mobx 是一个数据管理库...

3327
来自专栏salesforce零基础学习

salesforce零基础学习(八十五)streaming api 简单使用(接近实时获取你需要跟踪的数据的更新消息状态)

Streaming API参考链接: https://trailhead.salesforce.com/en/modules/api_basics/units/...

3188
来自专栏哲学驱动设计

Rafy 领域实体框架演示(2) - 新功能展示

本文的演示需要先完成上一篇文章中的演示:《Rafy 领域实体框架示例(1) - 转换传统三层应用程序》。在完成改造传统的三层系统之后,本文将讲解使用 Rafy ...

1888
来自专栏编程

嵌入式Linux系统在线升级策略

由于市面上大多数嵌入式设备的分散、数量庞大、部署地点情况复杂,因此对于这些设备进行个体、本地升级的实施非常费时费力。针对这种现状,本文提供一种对基于 Linux...

2319
来自专栏liuchengxu

[译]使用pelican搭建一个数据科学博客

写博客是一个证明你的技能,进一步加深学习和积累受众的一个非常好的方式。已经有非常多的数据科学和编程博客帮助它们的作者找到工作,或是建立了非常重要的联系。撰写博客...

942
来自专栏JAVA后端开发

通用数据级别权限的框架设计与实现(5)-总结与延伸思考

继上篇文章通用数据级别权限的框架设计与实现(4)-单条记录的权限控制后,通用数据级别权限的框架设计已经实现,但我们就这样满足了吗? 代码也只是花了我两个晚上完...

792
来自专栏WindCoder

网易MySQL微专业学习笔记(三)-Mysql权限管理

这个系列属于个人学习网易云课堂MySQL数据库工程师微专业的相关课程过程中的笔记,本篇为其“MySQL数据库对象与应用”中的MySQL数据类型相关笔记。

791
来自专栏Java后端技术

Spring+SpringMvc+Mybatis框架集成搭建教程一(项目创建)

  2.选择Maven->Create from artchetype并选择如下图红框中的骨架

641

扫码关注云+社区