某客户ODS数据库undo段问题分析处理

概述

ODS数据库在7月22日4个时间点02:03,05:17,07:04,08:53分别报如下错误:

原因分析

Ora-1628:max # extents 32765 reached for rollback segment _SYSSMU19990_761259507$

Oracle 官方解释:

Cause: An attempt was made to extend a rollback segment that already has reached its maximum size or space could not be allocated in the data dictionary to contain the definition of the object.

Action:If possible,increase the value of either the MAXEXTENTS or PCTINCREASE initialization parameters or find the data dictionary table lacking space and alter the storage parameters,as described in the Oracle8 Server Administrator's Guide

该报错出现在实例1上,实例1的undo情况如下:

|-----------------|----------------|-----------|-----------|-------------|
| TABLESPACE_NAME | Allocated (MB) | Free (MB) | Used (MB) | PERCENTFREE |
| UNDOTBS11 | 32768 | 11762 | 21005 | 36 |

UndoTBS11的DDL语句如下:

Undotbs11是extent本地管理模式。

根据MOS文章:

出现ORA-1628错误主要有两方面:

1.出现非常大的事务

Undo使用自动管理,人为无法控制扩展区大小。也无法缩小。系统会自动决定扩展区的大小,但是如果undo段扩展了很多,通常它将开始分配更大的扩展区,undo 段的最大扩展区数限制为32K,并且如果当前扩展区中的下一个扩展区不是过期的扩展区,则长/大型运行事务可以通过添加新扩展区来耗尽此限制,并且最终将收到ORA-1628。

2.Undo表空间中存在大量的碎片

在undo使用自动管理。人为无法控制扩展区大小。在遇到大事务时,大量扩展回滚段,回滚段中的大量扩展区可能是由于undo表空间中的碎片所致:由于碎片,Oracle可能只能分配64k的扩展区,因此很有可能遇到最大扩展区问题。

解决方法

1.对于大事务,可以通过将大事务拆分为较小的事务(例如频繁提交)来解决。

2.如果是undo表空间碎片,可以通过重新创建undo表空间来解决(这也是建议的Bug 10330444Bug 10229998的解决方案,它们是针对同一问题而提交的,并且已作为非bug关闭)。

Oracle建议:

1)将参数 "_rollback_segment_count" 设置为在线更多可用的UNDO段。应通过放置以下查询获得的最大值来设置值

目前该参数设置为6000.

2)Oracle bug。(bug 7291739)

该bug修复提供一个隐藏参数:_HIGHTHRESHOLD_UNDORETENTION。该参数的设置根据如下两个值得到:

|-----------------------------------------------------------------------------------------------------------------------------------------------------------------|
| SQL> select max(maxquerylen),max(tuned_undoretention) from v$undostat; MAX(MAXQUERYLEN) MAX(TUNED_UNDORETENTION) ---------------- ------------------------ 0 0 |

ALTER SYSTEM SET "_highthreshold_undoretention"=max(maxquerylen)+1;

Oracle建议设置值:

ALTER SYSTEM SET "_highthreshold_undoretention"=1;

3)其他bug如下:

4)删除并重新创建undo表空间(由于其碎片)

解决方案及建议

目前ODS undo表空间undotbs11为bigfile数据文件,最大值设置为60G,自动扩展。而且出现该错误均在ODS大量跑批的时候。在对应时间点根据ASH报告,时有抽数的情况发生。根据实际情况有如下解决建议:

1.拆分大事务为小事务,之前跟开发沟通,结果不理想。

  1. 对于undo表空间碎片进行整理。

能够在线进行调整的只有undo表空间重建工作,而且不影响业务的正常运行。

如下:

  • 重建undotbs1表空间。
  • 重建表空间取消自动扩展。
  • 重建表空间初始分配60G大小。

根据现有信息,无法判断该报错是否bug,先期对undo表空间根据MOS文件进行重建后,后续在进行观察。

相关推荐
银发控、6 小时前
MySQL联合索引
数据库·mysql
予枫的编程笔记6 小时前
【MySQL修炼篇】从踩坑到精通:事务隔离级别的3大异常(脏读/幻读/不可重复读)解决方案
数据库·mysql·后端开发·数据库事务·事务隔离级别·rr级别·脏读幻读不可重复读
一起养小猫7 小时前
Flutter for OpenHarmony 实战:记账应用数据统计与可视化
开发语言·jvm·数据库·flutter·信息可视化·harmonyos
世界尽头与你7 小时前
(修复方案)CVE-2023-22047: Oracle PeopleSoft Enterprise PeopleTools 未授权访问漏洞
数据库·安全·oracle·渗透测试
韩立学长7 小时前
【开题答辩实录分享】以《智能大学宿舍管理系统的设计与实现》为例进行选题答辩实录分享
数据库·spring boot·后端
Henry Zhu1237 小时前
数据库(五):反规范化
数据库
Mr_Xuhhh8 小时前
MySQL函数详解:日期、字符串、数学及其他常用函数
java·数据库·sql
he___H9 小时前
Redis高级数据类型
数据库·redis·缓存
霖霖总总9 小时前
[小技巧60]深入解析 MySQL Online DDL:MySQL Online DDL、pt-osc 与 gh-ost 机制与最佳实践
数据库·mysql
爱学习的阿磊9 小时前
使用PyTorch构建你的第一个神经网络
jvm·数据库·python