oracle的还原表空间UNDO写满磁盘空间,解决该问题的具体步骤



产生问题的原因主要以下两点:

1. 有较大的事务量让Oracle Undo自动扩展,产生过度占用磁盘空间的情况;

2. 有较大事务没有收缩或者没有提交所导制;

说明:本问题在ORACLE系统管理中属于比较正常的一现象,日常维护多注意对磁盘空间的监控。

UNDO表空间介绍

UNDO表空间用于存放UNDO数据,当执行DML操作(INSERT,UPDATE和DELETE)时,oracle会将这些操作的旧数据写入到UNDO段,在oracle9i之前,管理UNDO数据时使用(Rollback Segment)完成的.从oracle9i开始,管理UNDO数据不仅可以使用回滚段,还可以使用UNDO表空间.因为规划和管理回滚段比较复杂,所有oracle database 10g已经完全丢弃用回滚段.并且使用UNDO表空间来管理UNDO数据。

1、查看系统磁盘状态

AIX系统:/> df -g   (Linux系统:  df -h)

Filesystem    GB blocks      Free %Used    Iused %Iused Mounted on

/dev/undolv       30.00      0.00  100%        9     1% /u01/app/u01/app/oracle/undo

2、查看Oracle数据库表空间的占有率

select a.tablespace_name,

round((a.maxbytes / 1024 / 1024), 2) "sum MB",

round((a.bytes / 1024 / 1024), 2) "datafile MB",

round(((a.bytes - b.bytes) / 1024 / 1024), 2) "used MB",

round(( (a.maxbytes-a.bytes+b.bytes) / 1024 / 1024), 2) "free MB",

round(((a.bytes - b.bytes) / a.maxbytes) * 100, 2) "percent_used"

from (select tablespace_name, sum(bytes) bytes,sum(maxbytes) maxbytes

from dba_data_files where maxbytes!=0

group by tablespace_name) a,

(select tablespace_name, sum(bytes) bytes, max(bytes) largest

from dba_free_space

group by tablespace_name) b

where a.tablespace_name = b.tablespace_name

order by ((a.bytes - b.bytes) / a.maxbytes) desc

Tablespace_name SumDatafile(MB) Datafile Used   Free   Precent_used

1 UNDOTBS1 32767.98 30000 29968 2799.98 91.46

或者通过如下脚本检查数据库表空间占用空间情况:

select tablespace_name,sum(bytes)/1024/1024/1024 GB

from dba_data_files group by tablespace_name

union all

select tablespace_name,sum(bytes)/1024/1024/1024 GB

from dba_temp_files group by tablespace_name order by GB;

3、找出UNDO表空间的路径及大小

SQL>  select file_name,bytes/1024/1024 from dba_data_files

where tablespace_name like ‘UNDOTBS1‘

/u01/app/oracle/undo/undotbs01.dbf   30000

4、检查UNDO Segment状态

SQL> select usn,xacts,rssize/1024/1024/1024,hwmsize/1024/1024/1024,shrinks

from v$rollstat order by rssize;

USN XACTS RSSIZE/1024/1024/1024 HWMSIZE/1024/1024/1024 SHRINKS

1 0 0 0.000358582 0.000358582 0

2 14 0 0.796791077 0.796791077 735

3 13 0 0.800453186 0.800453186 894

4 12 0 0.805213928 0.805213928 728

5 15 0 1.186126709 1.186126709 922

6 1 0 1.723365784 1.963180542 946

7 3 0 1.732704163 1.977462769 1051

8 5 0 1.978370667 2.228370667 654

9 2 0 2.032501221 2.034454346 707

10 4 0 2.065216064 2.318145752 875

11 11 0 2.100006104 2.100006104 1269

12 8 0 2.630340576 2.700653076 897

13 6 0 2.740814209 2.740814209 1030

14 9 0 2.745697021 2.772064209 1037

15 7 0 2.833526611 2.833526611 1033

16 10 0 3.088363647 3.310592651 989

这还原表空间中还存在16个回滚的对象。

5、创建新的临时UNDO表空间

可以在其它的磁盘空间临时创建还原表空间

SQL>

create undo tablespace undotbs2

datafile ‘/u01/app/oracle/pub/undotbs02.dbf‘

size 10M autoextend on;

Tablespace created.

6、切换UNDO表空间为新的UNDO表空间

SQL> alter system set undo_tablespace=undotbs2 scope=both;

System altered.

7、验证当前数据库的还原表空间

SQL> show parameter undo

NAME                                 TYPE        VALUE

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

undo_management                      string      AUTO

undo_retention                       integer     900

undo_tablespace                      string      UNDOTBS2

8、等待原UNDO表空间所有UNDO SEGMENT OFFLINE

select t.segment_name,t.tablespace_name,t.segment_id,t.status from dba_rollback_segs t;

SEGMENT_NAME TABLESPACE_NAME SEGMENT_ID STATUS

1 SYSTEM SYSTEM 0 ONLINE

2 _SYSSMU1$ UNDOTBS1 1 OFFLINE

3 _SYSSMU2$ UNDOTBS1 2 OFFLINE

48 _SYSSMU47$ UNDOTBS1 47 OFFLINE

49 _SYSSMU48$ UNDOTBS1 48 OFFLINE

50 _SYSSMU49$ UNDOTBS1 49 OFFLINE

51 _SYSSMU50$ UNDOTBS1 50 OFFLINE

52 _SYSSMU51$ UNDOTBS1 51 OFFLINE

53 _SYSSMU52$ UNDOTBS1 52 OFFLINE

54 _SYSSMU53$ UNDOTBS1 53 OFFLINE

55 _SYSSMU54$ UNDOTBS1 54 OFFLINE

56 _SYSSMU55$ UNDOTBS1 55 OFFLINE

57 _SYSSMU56$ UNDOTBS1 56 OFFLINE

58 _SYSSMU57$ UNDOTBS1 57 OFFLINE

59 _SYSSMU58$ UNDOTBS1 58 OFFLINE

60 _SYSSMU59$ UNDOTBS1 59 OFFLINE

61 _SYSSMU60$ UNDOTBS1 60 OFFLINE

62 _SYSSMU61$ UNDOTBS1 61 OFFLINE

63 _SYSSMU62$ UNDOTBS2 62 ONLINE

64 _SYSSMU63$ UNDOTBS2 63 ONLINE

65 _SYSSMU64$ UNDOTBS2 64 ONLINE

66 _SYSSMU65$ UNDOTBS2 65 ONLINE

67 _SYSSMU66$ UNDOTBS2 66 ONLINE

68 _SYSSMU67$ UNDOTBS2 67 ONLINE

69 _SYSSMU68$ UNDOTBS2 68 ONLINE

上面对应的UNDOTBS1还原表空间所对应的回滚段均为OFFLINE

9、删除原UNDO表空间

SQL> drop tablespace undotbs1 including contents and datafiles;

Tablespace dropped.

10、可以再次查看系统磁盘空间:

AIX系统:/> df -g   (Linux系统:  df -h)

如果需要规范数据库的表空间和路径,还原表空间名称undotbs1和路径不能改变,

可以安装刚才的步骤进行切换回来。

1、创建新的原来的UNDO表空间

可以在其它的磁盘空间临时创建还原表空间

SQL>

create undo tablespace undotbs1

datafile ‘/u01/app/oracle/undo/undotbs01.dbf‘

size 10M autoextend on maxsize 15G;

刚开始为10M,设置自动扩展,最大为15GB

Tablespace created.

2、切换UNDO表空间为新的UNDO表空间

SQL> alter system set undo_tablespace=undotbs1 scope=both;

System altered.

3、验证当前数据库的还原表空间

SQL> show parameter undo

NAME                                 TYPE        VALUE

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

undo_management                      string      AUTO

undo_retention                       integer     900

undo_tablespace                      string      UNDOTBS1

4、等待原UNDO表空间所有UNDO SEGMENT OFFLINE

select t.segment_name,t.tablespace_name,t.segment_id,t.status from dba_rollback_segs t;

SEGMENT_NAME TABLESPACE_NAME SEGMENT_ID STATUS

上面对应的UNDOTBS2还原表空间所对应的回滚段均为OFFLINE

5、删除UNDO2表空间

SQL> drop tablespace undotbs2 including contents and datafiles;

Tablespace dropped.

6、可以再次查看系统磁盘空间:

AIX系统:/> df -g   (Linux系统:  df -h)

undo_retention:指定事物commit后undo 将要保存的时间(秒),在ORACLE10g中默认的是900秒。

GUARANTEE : 保证undo_retention参数所设定的时间有效,这个是10g的新功能。

SQL> ALTER TABLESPACE undotbs1 RETENTION GUARANTEE;

SQL> ALTER TABLESPACE undotbs1 RETENTION NOGUARANTEE;

在没有guarantee的保证下,ORACLE并不能保证能够将undo信息存储900秒,如果undo表空间不足,那么ORACLE将忽略undo_retention的设置,直接覆盖掉以前的undo,这个时候有可能会产生ORA-01555错误。如果undo表空间空间足够,那么undo将会保存很长一段时间,直到undo表空间达到maxsize,这个时候才会覆盖undo信息,而且ORACLE会从最古老的undo信息开始覆盖。

ORACLE推荐我们将undo 表空间中的datafile 设定MAXSIZE ,不要让它一直自动扩展,如果ORACLE获得了自动扩展的能力,那么旧的undo不会被覆盖,到后来undo表空间会越来越大,越来越大,直到将磁盘空间耗尽。

在有guarantee的保证下,ORACLE将会保证undo信息能够保存到undo_retention设定的值之后才被覆盖,如果这个时候同时执行了很多事物,将undo表空间耗完了,那么那个事物会失败,会报ORA-30036 错误,所以使用guarantee一定要慎用,如果非要使用guarantee,那么尽量将undo 表空间设大 一点。

Oracle10g开始,如果你设置UNDO_RETENTION为0,那么Oracle启用自动调整以满足最长运行查询的需要。当然如果空间不足,那么Oracle满足最大允许的长时间查询,而不再需要用户手工调整。

时间: 2024-12-28 16:23:43

oracle的还原表空间UNDO写满磁盘空间,解决该问题的具体步骤的相关文章

MySQL ibdata1撑爆占满磁盘空间

MySQL主从由于ibdata1占满磁盘空间-->主从失效 因为设置了innodb_file_per_table = 1,ibdata1依旧撑爆占满磁盘空间 主从断的时候,IO线程在连接,SQL线程断掉. 想要了解为何ibdata1增长那么大? 个人这么理解的:主从断掉,IO线程在,获取到了事件事物的更新,而SQL线程断掉,导致产生大量的undo,撑爆了ibdata1. 最终验证发现,确实是undo占满了ibdata1. 下载一个小工具:py_innodb_page_info.py  本人网盘下

【总结】filebeat进程写满磁盘的情况处理

采用filebeat收集日志,日志文件频繁rotate,造成filebeat占用文件不释放,只要filebeat保持着被删除文件Open状态,操作系统就不释放磁盘空间,导致可用磁盘空间逐渐减小. 使用lsof命令查看filebeat保持着的文件资源,可以发现许多被filebeat占用空间的失效文件(deleted)文件. deleted状态的文件没有释放,始终占据磁盘空间 解决办法: 查看filebeat配置文件位置: /etc/filebeat/filebeat.yml 在配置文件中添加clo

解决Ubuntu因为CUPS打印服务的日志占满磁盘空间的问题

今天一大早用命令行界面登陆Ubuntu之后发现数据库无法执行SQL语句,并且报了个磁盘空间已满的ERROR. 当时有点奇怪:因为这台服务器就我一人在使用,没有其他人使用,服务器也不对外提供服务. 于是用以下命令查看磁盘空间,发现确实已经满了. 在磁盘空间已满的情况下,Ubuntu的图形界面是进不去的,请使用命令行登陆. df -h 再用这个命令查找容量在5GB或以上的大文件 sudo find / -type -f size +5000000k 果然找到两个error_log文件都特别大,一个1

postfix导致maillog填满磁盘空间的巨坑!

双休日回家pull在公司修改的代码...于是菜鸟的linux探索之路开始了 1.df -f发现磁盘又占满了(之前是node的error) 2.发现maillog整整10个G,无数条(Jul 7 04:08:15 tangxu postfix/error[4318]: B1612103F04: to=[email protected], relay=none, delay=361517, delays=361504/14/0/0, dsn=4.4.3, status=deferred (deliv

ORACLE 11G收缩表空间报错 ORA-03297: file contains used data beyondrequested RESIZE value

测试环境磁盘空间不足,所以drop一些无用的大表,但是发现空间没有变化,df -h还是没有释放出磁盘空间来. SQL> set line 200 SQL> set pagesize 200 SQL> col name format A150 1,查看表空间使用情况 SQL> SELECTUPPER(F.TABLESPACE_NAME) "表空间名", 2 D.TOT_GROOTTE_MB "表空间大小(M)", 3 D.TOT_GROOTTE

Oracle磁盘空间使用统计

对于大型数据库,Oracle占用的磁盘空间非常大,掌握数据库中那些用户.表占用了多杀磁盘空间,以及增长情况,可以方便日后对磁盘系统进行维护和扩充. 对Oracle磁盘空间使用情况,可以分为按照表空间.用户或者表来进行统计. (一).表空间 计算表空间的剩余大小 select A.TABLESPACE_NAME,A.BYTES/(1024*1024*1024) "SPACE(G)", C.BYTES/(1024*1024) "FREE SPACE(M)",(C.BYT

记一次Linux磁盘空间占满无法删除的故障

问题介绍 近日发现公司服务器的磁盘空间越来越满,感觉快要爆掉的感觉,于是开始着手清清磁盘空间,但是找来找去,发现根目录已经使用了90%以上,可是/下的目录占的空间都非常小,始终找不到占满磁盘空间的大头在哪里. 思考解决方案 按照网上的说法,是因为文件已经删除,但是使用文件的进程还存在,导致空间无法释放.运行如下命令后(最终无效). lsof | grep deleted | awk '{print $2}' | xargs kill -9 因为系统有单独挂载的文件夹,所以想把系统分区还原成还没挂

运行R 报错R cannot R_TempDir, 继而发现/dev/mapper/VG00-LV01 磁盘空间已满

今天在运行R脚本的时候报了个错:Fatal error: cannot create 'R_TempDir'.排除了是自己写的代码的问题,想着应该是某个没见过的原因,google之,发现网上的说法是/tmp文件夹占满了磁盘空间. 运行 df 命令: Filesystem Size Used Avail Use% Mounted on /dev/mapper/VG00-LV01 50G 47G 16M 100% / 发现确实有个分区被占满了... 第一次碰到这种情况,继续google之,使用如下命

Linux磁盘空间被未知资源耗尽【转】

Linux磁盘空间被未知资源耗尽 在linux中,当我们使用rm在linux上删除了大文件,但是如果有进程打开了这个大文件,却没有关闭这个文件的句柄,那么linux内核还是不会释放这个文件的磁盘空间,最后造成磁盘空间占用100%,整个系统无法正常运行.这种情况下,通过df和du命令查找的磁盘空间,两者是无法匹配的,可能df显示磁盘100%,而du查找目录的磁盘容量占用却很小. 遇到这种情况,基本可以断定是某些大文件被某些程序占用了,并且这些大文件已经被删除了,但是对应的文件句柄没有被某些程序关闭