关于ORA-01555的问题分析(r5笔记第87天)

今天开发的同事发给我一个问题,在运行某一个Job的时候抛出了ORA错误,希望我们看看从数据库层面能不能发现什么。 错误日志如下:

Function: EntitySQLCursor::query
Line number: 113
Time: Thu Jul  2 22:52:46 2015
Message text: (PE1-000143) Internal IO Framework Database Error, message ORA-01555: snapshot too old: rollback segment number 22 with name "_SYSSMU22_234950861$" too small
, code 1555.

看这个错误,似乎是oracle分配的回滚段太小导致的。对于这个问题,因为已经过去了一段时间,所以能够合理分析的一种途径就是使用ash. 根据错误信息中的时间戳,基本定位在了22:52~22:53这一分钟之内,抓取了一个ash报告。 因为信息针对性更强,可以很清晰的看到在那一分钟之内数据库层面有一些查询和dml的语句在运行,有些走了全表扫描,有些走了索引扫描。

Top SQL with Top Events

SQL ID

Planhash

Sampled # of Executions

% Activity

Event

% Event

Top Row Source

% RwSrc

SQL Text

fzn01wc5pg2dg

1199754052

2

15.67

CPU + Wait for CPU

11.75

TABLE ACCESS - FULL

11.75

SELECT /*+ ALL_ROWS USE_NL ("A...

db file sequential read

2.61

TABLE ACCESS - FULL

2.61

direct path read

1.31

TABLE ACCESS - FULL

1.31

5q2mguqdcrq4a

421773076

1

12.01

db file sequential read

12.01

INDEX - RANGE SCAN

7.05

SELECT RE.L3_NET_START_TIME, R...

a793wrq0q27c5

201265388

1

10.70

db file sequential read

8.09

DELETE

8.09

delete from RATED_EVENT WHERE ...

CPU + Wait for CPU

1.57

DELETE

1.57

direct path read temp

1.04

DELETE

1.04

496x3fkydc1xj

84305990

1

9.92

db file sequential read

8.62

INDEX - RANGE SCAN

8.62

** SQL Text Not Available **

CPU + Wait for CPU

1.31

INDEX - RANGE SCAN

1.31

dm1d93bw2jdzc

2843169790

27

8.09

db file sequential read

4.70

INDEX - RANGE SCAN

2.09

select sk.rowid , sk.subscribe...

CPU + Wait for CPU

3.39

SELECT STATEMENT

2.35

需要重点关注的是全表扫描的语句和DML语句。 先来看看全表扫描的语句。 SELECT /*+ ALL_ROWS USE_NL ("AC1_CONTROL_HIST") FULL ("AC1_CONTROL_HIST") */ .... from "AC1_CONTROL_HIST" WHERE "CUR_PGM_NAME"='RGD' AND "IDENTIFIER"=:1 语句输出字段较多,但是相关的表只有一个,这个表从表名可以看出是一个历史表,数据量相比也是相当大的,一查看统计信息,数据量都在亿级以上。 这么大的表,使用了hint,指定全表扫描,相比是某些地方需要吧,带着疑问查看了索引的信息,而其中的主键索引就是IDENTIFIER字段开始的。 所以从这个角度来看,这个问题是一个很明显的问题,因为使用Hint不当导致了,本该走索引扫描的查询结果走了极为消耗资源的全表扫描。 当然了,哲学中有句话是 存在即合理,可能在早期的时候数据量不大,处于某种需要,可能需要全表扫描,或者这部分逻辑是直接从某个地方参考而来,而其中的hint都忘了变更,导致了这样的问题。 出了问题,找问题的理由也是多种多样。当然最终这个问题还是发生了,能够及时发现修复才是更重要的。 对于这个问题的分析暂时告一段落,但是还有dml对于undo的影响也不容小视,可供参考的就是前面表格中的delete语句了。 对于这个语句,delete涉及的表也是很大的一个分区表,数据量亿级以上。在基于索引扫描的前提下,做了根据时间戳进行数据清理的操作。对于这种操作,我们可以反过来考虑一下,目前delete的逻辑是对的,在排除了ac1_control_hist全表扫描影响的前提下,delete操作还是会消耗大量的undo资源。这个时候也需要同时考虑目前的undo大小是否完全满足系统的要求。目前的库里undo的大小在17G左右,几个大分区表都在百G以上,如果删除所限定的时间戳大一些,undo的消耗就会更大,所以也需要考量undo的大小,根据目前的情况,可以考虑适当增大undo空间。 所以这个问题的分析结果就是两个建议,第一个就是对于本该索引扫描的语句走了全表扫描进行改进,规范hint的使用。另外一方面是建议适当调大undo的大小,以满足系统的需求,使得系统的负载更有张力。

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2015-07-03

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏杨建荣的学习笔记

执行计划的偏差导致的性能问题(r3笔记第12天)

在生产环境中有一条sql语句,查看执行计划来看,效果还是可以接受的。 sql语句类似下面的样子,可以看到里面还使用了比较纠结的外连接。从执行计划来说,默认是走n...

27640
来自专栏杨建荣的学习笔记

insert中启用错误日志的问题及分析(r2第10天)

在平时的工作中,有时候需要insert一批数据,这些数据可能是临时表,外部表,普通表,子查询等形式,类似下面的格式 insert into xxxx (sele...

33590
来自专栏「3306 Pai」社区

《那些年,我在乙方的日子 -- 神谕篇NO1》

某个夏日的午后,窗外知了在大声鸣叫。而我却在睡梦中跟基友一起吃鸡,正准备抢空投时 。手机突然铃声响起,惊醒后一看是领导电话,一下子回到了现实中。心想又得去公司吃...

18920
来自专栏idba

死锁案例之四

一 前言 死锁,其实是一个很有意思也很有挑战的技术问题,大概每个DBA和部分开发同学都会在工作过程中遇见 。关于死锁我会持续写一个系列的案例分析,希望能够对想...

9730
来自专栏数据和云

触类旁通:那些关于 TBL$OR$IDX$PART$NUM 的诡异案例和知识

你是否留意过数据库中有一个奇怪的函数 TBL$OR$IDX$PART$NUM ,你是否留意过很多场景下都出现过它的身影?

15440
来自专栏数据库新发现

在Mac上通过Docker部署Oracle Database 12.2版本

Oracle 已经宣布支持了Docker部署,这也让我们在Mac上部署 Oracle 数据库有了多一个选择,这是我的第一个Docker应用,非常简便快速的就完...

39160
来自专栏杨建荣的学习笔记

生产环境sql语句调优实战第六篇(r2笔记91天)

生产环境中有大量的sql语句在运行,尽管有awr,ash做数据的收集统计,但是dba的调优工作大多数情况都是在问题已经发生后做排查的,有些sql语句可能执行的时...

28040
来自专栏杨建荣的学习笔记

巧用外部表避免大量的insert (r4笔记第71天)

昨天开发咨询我一个问题,希望我对下面的语句进行调优。 语句类似下面的形式 SELECT subscriber_no FROM SUBSCRIBER S W...

37480
来自专栏沃趣科技

应用示例荟萃 | performance_schema全方位介绍(上)

经过前面6个篇幅的学习,相信大家对什么是performance_schema,已经初步形成了一个整体认识,但我想很多同行看完之前的文章之后可能还是一脸懵逼,今天...

26630
来自专栏杨建荣的学习笔记

海量数据迁移之外部表并行抽取(99天)

在10g开始的新特性中,外部表是一个不容忽视的好工具。对于大型项目中海量数据使用sqlloader是一种全新的方式,不过很明显,sqlloader的可扩展性更强...

38350

扫码关注云+社区

领取腾讯云代金券