本文内容来自YashanDB官网，原文内容请见 UNDO表空间膨胀怎么处理-YashanDB

问题现象

用户反馈UNDO表空间持续膨胀，出现UNDO空间不足，需要查明原因并如何做清理。

问题的风险及影响

影响对应功能使用

问题影响的版本

YashanDB版本：23.2及以上所有版本

解决方法及规避方式

在崖山是官网上有对UNDO空间的详细描述，UNDO的基本知识比较齐全，可以查阅 UNDO表空间管理 | YashanDB Doc

这里补齐常见的排查方法和应对措施。

1、核查方法

核查tablespace表空间情况，对应视图dba_tablespace，如果没有dba权限，则查询V$tablespace

表空间有对应的数据文件，对应视图dba_data_files/V$datafile, 重点关注AUTO_EXTEND是否打开为ON，FREE_BLOCKS/BLOCKS的比例

SQL> SELECT * FROM DBA_TABLESPACES dt;

ID TABLESPACE_NAME BLOCK_SIZE MAX_SIZE TOTAL_BYTES USER_BYTES USER_BLOCKS STATUS CONTENTS LOGGING ALLOCATION_TYPE SEGMENT_SPACE_MANAGEMENT ENCRYPTED COMPRESSED SHARED

------------ ---------------------------------------------------------------- ------------ ----------- ----------- ----------- ----------- ----------------- ----------------- ------------- --------------- ------------------------ --------- ---------- -----------------

0 SYSTEM 8192 5.4976E+11 67108864 26083328 3184 ONLINE PERMANENT LOGGING AUTO BITMAP N N SHARED

1 SYSAUX 8192 5.4976E+11 67108864 38600704 4712 ONLINE PERMANENT LOGGING AUTO BITMAP N N SHARED

2 TEMP 8192 5.4976E+11 67108864 61865984 7552 ONLINE TEMPORARY NOLOGGING UNIFORM BITMAP N N SHARED

3 SWAP 8192 5.4976E+11 67108864 66060288 8064 ONLINE SWAP NOLOGGING UNIFORM BITMAP N N SHARED

4 USERS 8192 5.4976E+11 67108864 66060288 8064 ONLINE PERMANENT LOGGING AUTO BITMAP N N SHARED

5 UNDO 8192 6.8719E+10 469762048 303906816 37098 ONLINE UNDO LOGGING AUTO BITMAP N N SHARED

6 rows fetched.

SQL> SELECT * FROM V$tablespace;

ID NAME STATUS EXTENT_BLOCKS CONTENTS ALLOCATION_TYPE MEMORY_MAPPED ENCRYPTED TEMPORARY COMPRESSED SHARED

------------ ---------------------------------------------------------------- ----------------- ------------- ----------------- --------------- ------------- --------- --------- ---------- -----------------

0 SYSTEM ONLINE 8 PERMANENT AUTO FALSE FALSE FALSE FALSE SHARED

1 SYSAUX ONLINE 8 PERMANENT AUTO FALSE FALSE FALSE FALSE SHARED

2 TEMP ONLINE 8 TEMPORARY UNIFORM FALSE FALSE TRUE FALSE SHARED

3 SWAP ONLINE 8 SWAP UNIFORM FALSE FALSE TRUE FALSE SHARED

4 USERS ONLINE 8 PERMANENT AUTO FALSE FALSE FALSE FALSE SHARED

5 UNDO ONLINE 1 UNDO AUTO FALSE FALSE FALSE FALSE SHARED

6 rows fetched.

SQL> SELECT * FROM V$datafile;

ID NAME CREATION_TIME TS# BLOCKS BLOCK_SIZE BYTES STATUS RELATIVE_FNO AUTO_EXTEND NEXT_SIZE MAX_SIZE FREE_BLOCKS DISK_BYTES SHADOW

------------ ---------------------------------------------------------------- ---------------------------------------------------------------- ------------ ------------ ------------ --------------------- --------- ------------ ----------- --------------------- --------------------- ------------ --------------------- ---------

0 /data/fangjingbian/yasdb_data/db-1-1/dbfiles/system 2024-08-15 04:27:42.148097 0 8192 8192 67108864 ONLINE 0 ON 67108864 549755813888 3184 67108864 FALSE

1 /data/fangjingbian/yasdb_data/db-1-1/dbfiles/sysaux 2024-08-15 04:27:42.720697 1 8192 8192 67108864 ONLINE 0 ON 67108864 549755813888 4712 67108864 FALSE

2 /data/fangjingbian/yasdb_data/db-1-1/dbfiles/temp 2024-08-15 20:19:59.067646 2 8192 8192 67108864 ONLINE 0 ON 67108864 549755813888 7552 67108864 FALSE

3 /data/fangjingbian/yasdb_data/db-1-1/dbfiles/swap 2024-08-15 20:19:59.137679 3 8192 8192 67108864 ONLINE 0 ON 67108864 549755813888 8064 67108864 FALSE

4 /data/fangjingbian/yasdb_data/db-1-1/dbfiles/users 2024-08-15 04:27:44.796951 4 8192 8192 67108864 ONLINE 0 ON 67108864 549755813888 8064 67108864 FALSE

5 /data/fangjingbian/yasdb_data/db-1-1/dbfiles/undo 2024-08-15 04:27:45.022139 5 57344 8192 469762048 ONLINE 0 ON 67108864 68719476736 37098 469762048 FALSE

6 rows fetched.

SQL> SELECT * FROM DBA_DATA_FILES;

FILE_NAME FILE_ID TABLESPACE_NAME BYTES BLOCKS STATUS MAXBYTES MAXBLOCKS AUTO_EXTEND NEXT_SIZE USER_BYTES USER_BLOCKS

---------------------------------------------------------------- ------------ ---------------------------------------------------------------- --------------------- ------------ --------- --------------------- ----------- ----------- --------------------- --------------------- ------------

/data/fangjingbian/yasdb_data/db-1-1/dbfiles/system 0 SYSTEM 67108864 8192 ONLINE 549755813888 67108864 ON 67108864 26083328 3184

/data/fangjingbian/yasdb_data/db-1-1/dbfiles/sysaux 1 SYSAUX 67108864 8192 ONLINE 549755813888 67108864 ON 67108864 38600704 4712

/data/fangjingbian/yasdb_data/db-1-1/dbfiles/temp 2 TEMP 67108864 8192 ONLINE 549755813888 67108864 ON 67108864 61865984 7552

/data/fangjingbian/yasdb_data/db-1-1/dbfiles/swap 3 SWAP 67108864 8192 ONLINE 549755813888 67108864 ON 67108864 66060288 8064

/data/fangjingbian/yasdb_data/db-1-1/dbfiles/users 4 USERS 67108864 8192 ONLINE 549755813888 67108864 ON 67108864 66060288 8064

/data/fangjingbian/yasdb_data/db-1-1/dbfiles/undo 5 UNDO 469762048 57344 ONLINE 68719476736 8388608 ON 67108864 303906816 37098

6 rows fetched.

SQL>

2、处理方法

1）在磁盘空间足够的情况下，直接加数据文件即可

ALTER TABLESPACE UNDO ADD DATAFILE 'undo02' SIZE 10G AUTOEXTEND ON;

2） 空间回收

undo空间不能通过alter tablespace shrink的方法缩小空间，但可以通过配置UNDO_SHRINK_ENABLED、UNDO_SHRINK_INTERVAL实现自动回收，详见配置参数 | YashanDB Doc

另外，UNDO的事务完成之后，对应的block在经过UNDO_RETENTION设置的时间之后，是可被其他事务复用的，因此，在没有长事务的情况下，可以缩小UNDO_RETENTION的时间，另空间可以快速复用。

3）原因核查

一般情况下UNDO的空间默认是自动扩展的，最大数据文件大小有64GB（和其他数据文件不一样，其他数据文件最大有512GB），是用不完的。

undo的空间不足一般情况下通过上面两种方法可以快速规避，但是还需要定位为什么会占用这么大的UNDO空间。

UNDO是做事务一致性控制必须的，其空间膨胀必然有大事务执行，用户在使用的过程应该尽量避免大事务，例如在loop过程分批提交。

另外，后台任务也可能有事务产生，如定时任务、快照清理。快照如果太大太多，也容易造成大事务占用UNDO空间，需要及时处理，快照可以通过SYSAUX表空间核查。

ITPub博客

UNDO表空间膨胀怎么处理

最新文章