记一次UNDO表空间超90%的处理

今天在为一套库扩表空间时查看到UNDOTBS1/2使用率均超过了90%,监控居然没报警,呵呵,这种花钱买监控还不如Nagios

SQL> select * from v$version;   

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
PL/SQL Release 11.2.0.4.0 - Production
CORE    11.2.0.4.0      Production
TNS for Linux: Version 11.2.0.4.0 - Production
NLSRTL Version 11.2.0.4.0 - Production
SQL> set linesize 200
SQL> col file_name for a40
SQL> select
  2  a.a1 tabelspace_name,
  3  round(b.b3/1048576,0) table_size_M,
  4  round((b.b3-a.a2)/1048576,0) used_M,
  5  round(a.a2/1048576,0) free_M,
  6  round(substr((b.b3-a.a2)/b.b3*100,1,5),2) used_rate
  7   from
  8  (select  tablespace_name a1, sum(nvl(bytes,0)) a2 from dba_free_space group by tablespace_name) a,
  9  (select tablespace_name b1,sum(bytes) b3 from dba_data_files group by tablespace_name) b
 10  where a.a1(+)=b.b1
 11  order by 5 desc;

TABELSPACE_NAME                TABLE_SIZE_M     USED_M     FREE_M  USED_RATE
------------------------------ ------------ ---------- ---------- ----------
UNDOTBS1                               5000       1009       3991      97.33
UNDOTBS2                               5000        835       4165      91.59
SYSAUX                                 5000       3738       1262      74.75
MNTDATA                              153600     110900      42700       72.2
SYSTEM                                 5000        286       4714       5.72
USERS                                   500          2        498        .36
MNTINDEX                              30720          1      30719          0

查看unexpired和expired的大小

SQL> select tablespace_name,count(bytes/1024/1024) from dba_undo_extents where status!=’ACTIVE’ group by tablespace_name;

TABLESPACE_NAME count(bytes/1024/1024)


UNDOTBS1 4866

UNDOTBS2 4579

actived一个没有,全是expired和unexpired的

SQL> select tablespace_name,count(bytes/1024/1024) from dba_undo_extents where status=‘ACTIVE‘ group by tablespace_name;

no rows selected
SQL>show parameter undo

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
undo_management                      string      AUTO
undo_retention                       integer     900
undo_tablespace                      string      UNDOTBS1

undo retention为900

UNDO表空间并没有设置成GUARANTEE模式，所以根据我们的知识都明白UNDO表空间中的EXPIRED和UNEXPIRED都是可能被重用的

SQL> select undotsn,activeblks,expiredblks,unexpiredblks,tuned_undoretention from v$undostat;

   UNDOTSN ACTIVEBLKS EXPIREDBLKS UNEXPIREDBLKS TUNED_UNDORETENTION
---------- ---------- ----------- ------------- -------------------
         4        464       84016         22272                2361
         4        464       84016         22272                2300
         4        464       83888         23680                1985
         4        464       85936         20992                2296
         4        464       82992         26240                1694
         4        464      280840         13056                2579
         4        464      281352         11648                2287
         4        464      123384        462216                2574
         4        464      125040        460560              176361
         4        464      125144        460456              176482
         4        464      125120        460480              176583

   UNDOTSN ACTIVEBLKS EXPIREDBLKS UNEXPIREDBLKS TUNED_UNDORETENTION
---------- ---------- ----------- ------------- -------------------
         4        464       70864        456752              226010
         4        464       68688        456880              225899
         4        464       69072        456496              225960
         4        464       66768        458800              225860
         4        464       66768        458800              225608
         4        464       66896        458672              225628
         4        464       65744        459824              226171
         4        464       67920        457648              225325
         4        464       64464        461104              225395
         4        464       64720        460848              225330
         4        464       64720        460848              225049

   UNDOTSN ACTIVEBLKS EXPIREDBLKS UNEXPIREDBLKS TUNED_UNDORETENTION
---------- ---------- ----------- ------------- -------------------
         4        464       66768        459824              225003
         4        464       71888        459952              225888
         4        464       71888        458928              225985
         4        464       71120        459696              226087
         4        464       70096        460720              225874
         4        464       70992        459824              225904
         4        464       69072        461744              225913
         4        464       69072        460720              225672
         4        464       67920        461872              225690
         4        464       65872        463920              225357
         4        464       65872        463920              225166
…

576 rows selected.

TUNED_UNDORETENTION被自动调整了

SQL> select 224997/3600 from dual;

224997/3600
-----------
 62.4991667

也就是说UNDO表空间中的数据要保留接近62小时才会过期，正是因为这么长的数据未过期时间，且表空间又足够的大，才导致了UNDO表空间的空间一致未被释放

正常情况下，如果undo 表空间被设置为固定大小，不自动扩展，>oracle会启用Automatic Tuning of undo retention特性。

启用Automatic Tuning of undo retention时，oracle会忽略undo_retention的设置，根据undo表空间大小、系统负载情况，自动调整undo_retention为一个合适的值。这个值一般会大于“所有事务的最长运行时间”。

10gR2的bug现象为，只要设置了undo表空间自动管理，不管有没开自动扩展，不管undo_retention设置为多少，都会启用 Automatic Tuning of undo retention的新特性。

解决方法：

1).将UNDO表空间对应的数据文件调整为自动扩展，并为其设定一个最大值。

SQL> ALTER DATABASE DATAFILE ‘<datafile_flename>‘ AUTOEXTEND ON MAXSIZE <current_size>

正是通过这种方式解决了问题，调整之后空间很快得到释放，VUNDOSTAT.TUNEDUNDORETENTION值立即变小，这和文章前面的解释是完全吻合的，当UNDO表空间对应的数据文件是自动扩展的，那么VUNDOSTAT.TUNED_UNDORETENTION值的计算就不再依赖于UNDO表空间的百分比（UNDO表空间本身较大）。

2).设置_smu_debug_mode隐藏参数。
_smu_debug_mode=33554432
前面我们已经对这个参数进行了解释，这里再次验证。

3).设置_undo_autotune隐藏参数。
_undo_autotune = false

前面的两种方法没有关闭Oracle的UNDO自动调整RETENTION的功能，将_undo_autotune设置为false，就彻底关闭了自动调整UNDO RETENTION的功能，那么UNDO的RETENTION时间完全依赖于初始化参数UNDO_RETENTION的值，默认值为900秒。

这里我通过第一种方法

alter database datafile ‘+DGSYS/undotbs101.dbf’ autoextend on maxsize 5000m;

alter database datafile ‘+DGSYS/undotbs201.dbf’ autoextend on maxsize 5000m;

过一段时间后查看

SQL> select
  2  a.a1 tabelspace_name,
  3  round(b.b3/1048576,0) table_size_M,
  4  round((b.b3-a.a2)/1048576,0) used_M,
  5  round(a.a2/1048576,0) free_M,
  6  round(substr((b.b3-a.a2)/b.b3*100,1,5),2) used_rate
  7   from
  8  (select  tablespace_name a1, sum(nvl(bytes,0)) a2 from dba_free_space group by tablespace_name) a,
  9  (select tablespace_name b1,sum(bytes) b3 from dba_data_files group by tablespace_name) b
 10  where a.a1(+)=b.b1
 11  order by 5 desc;

TABELSPACE_NAME                TABLE_SIZE_M     USED_M     FREE_M  USED_RATE
------------------------------ ------------ ---------- ---------- ----------
SYSAUX                                 5000       3738       1262      74.75
MNTDATA                              153600     110900      42700       72.2
UNDOTBS1                               5000       1009       3991      20.18
UNDOTBS2                               5000        835       4165       16.7
SYSTEM                                 5000        286       4714       5.72
USERS                                   500          2        498        .36
MNTINDEX                              30720          1      30719          0

空间释放了

时间： 2024-11-05 19:05:15

记一次UNDO表空间超90%的处理的相关文章

记一次ORACLE的UNDO表空间爆满分析过程

这篇文章是记录一次ORACLE数据库UNDO表空间爆满的分析过程,主要整理.梳理了同事分析的思路.具体过程如下所示: 早上收到一数据库服务器的UNDO表空间的告警邮件,最早一封是7:55发出的(监控作业是15分钟一次),从告警邮件分析,好像是UNDO表空间突然一下子被耗尽了. DB Tablespace Allocated Free Used % Free % Used 192.168.xxx.xxx:1521 UNDOTBS1 16384 190.25 16193.75 1.16 99 使用一

undo表空间概述

oracle028 undo表空间概述 UNDO的简要概序: 1. 一般的表空间中的段是手动建立的,undo表空间和普通的表空间相似,但是undo表空间中undo段,undo段是自动生成的:oracle自动使用.维护undo段. 2. 一般表空间中的段是我们自己手动使用的,而undo表中的段是oracle自动使用的. show parameter undo_tablespace;//查询当前的undo表空间 NAME                                        

【oracle11g，13】表空间管理2：undo表空间管理(调优) ，闪回原理

一.undo空间原理: dml操作会产生undo数据. update时,sever process 会在databuffer 中找到该记录的buffer块,没有就从datafile中找并读入data buffer.在修改之前,原始数据先放到undo段,并在数据块头记录undo段(acitve 状态)中该数据块的位置,读写这个块时会占用事务槽,会将该事务号记录在数据块的头部.然后在进行update,并将该块放到dirty list检查点队列,等待dbwr进行写操作. 二.创建新的undo表空间替换

监控和管理Oracle UNDO表空间的使用

监控和管理Oracle UNDO表空间的使用 对Oracle数据库UNDO表空间的监控和管理是我们日常最重要的工作之一,UNDO表空间通常都是Oracle自动化管理(通过undo_management初始化参数确定):UNDO表空间是用于存储DML操作的前镜像数据,它是实例恢复,数据回滚,一致性查询功能的重要组件:我们常常会忽略对它的监控,这会导致UNDO表空间可能出现以下问题: 1).空间使用率100%,导致DML操作无法进行. 2).告警日志中出现大量的ORA-01555告警错误. 3).实

UNDO表空间的估算

UNDO表空间和TEMP空间类似,都是循环使用的,其使用原理大致如下: 当我们使用AUM(自动UNDO管理),并设置了undo_retention以后,undo块就存在四种状态. Active:表示正在使用该undo的事务还没有提交或回滚. Inactive:表示该undo上没有活动的事务,该状态的undo可以被其他事务覆盖. Expired:表示该undo持续inactive的时间超过undo_retention所指定的时间. Freed:表示该undo块内容是空的,从来没有被使用过. 当活动

Oracle undo 表空间不可用

由于某次不小心操作,在切换表空间时没有成功,但是由于把parameter undo的undo_management值改为了MANUAL所以在启动数据库时没有报任何错误,但是给表插入数据时报错了,回滚段不可用的错误.然后查询了错误原因. 1 首先看数据库中undo信息 SQL> show parameter undo; NAME TYPE VALUE------------------------------------ ----------- --------------------------

第15章 oracle undo表空间管理

2015-10-23 目录 参考资料 [1] 林树泽.Oracle 11g R2 DBA操作指南[M].北京:清华大学出版社,2013 [2] Oracle undo 表空间管理 [3] undo表空间概述 [4] Oracle UNDO表空间的管理 [5] Oracle的UNDO表空间管理总结 [6] UNDO表空间的管理 [7] UNDO表空间的管理 [8] 监控和管理Oracle UNDO表空间的使用 [9] 谈谈undo表空间

在线扩大数据库UNDO表空间

用oracle账号登陆ORACLE数据库服务器 方法一: 查看表空间的名字及文件所在位置: select tablespace_name, file_id, file_name,round(bytes/(1024*1024),0) total_space from dba_data_files order by tablespace_name; 修改数据库datafile文件到新的大小 alter database datafile '\oracle\oradata\undotab1.dbf'

MySQL5.7新特性——在线收缩undo表空间

1. MySQL 5.5时代的undo log 在MySQL5.5以及之前,大家会发现随着数据库上线时间越来越长,ibdata1文件(即InnoDB的共享表空间,或者系统表空间)会越来越大,这会造成2个比较明显的问题: (1)磁盘剩余空间越来越小,到后期往往要加磁盘: (2)物理备份时间越来越长,备份文件也越来越大. 这是怎么回事呢? 原因除了数据量自然增长之外,在MySQL5.5以及之前,InnoDB的undo log也是存放在ibdata1里面的.一旦出现大事务,这个大事务所使用的undo