关于ORA-01555的问题分析
今天开发的同事发给我一个问题，在运行某一个Job的时候抛出了ORA错误，希望我们看看从数据库层面能不能发现什么。
错误日志如下：
需要重点关注的是全表扫描的语句和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的大小，以满足系统的需求，使得系统的负载更有张力。
错误日志如下：
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的大小，以满足系统的需求，使得系统的负载更有张力。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/23718752/viewspace-1722045/ ，如需转载，请注明出处，否则将追究法律责任。
上一篇：
并行查询缓慢的问题分析
请登录后发表评论
登录
全部评论
