13518219792
如何理解oracle undo表空间快速扩展，很多新手对此不是很清楚，为了帮助大家解决这个难题，下面小编将为大家详细讲解，有这方面需求的人可以来学习下，希望你能有所收获。
成都创新互联公司专注于黄陂网站建设服务及定制，我们拥有丰富的企业做网站经验。 热诚为您提供黄陂营销型网站建设，黄陂网站制作、黄陂网页设计、黄陂网站官网定制、小程序制作服务，打造黄陂网络公司原创品牌,更为您提供黄陂网站排名全网营销落地服务。
最近发现在有两个数据库的undo表空间使用率一直在增长，过两天就加一次，已经加到快40G了，后来感觉这个现象有点不正常了，因为数据库的事务并不那太频繁，不至于总是到达100%
的地步，于是在网上查了下，果然这是oracle的一个bug造成的。这个bug应该是oracle10.2版本的所有平台上都存在。该bug oracle说在10.2.0.4版本上已经修补，但我还确实在AIX上发现了
BUG号：5387030、420525.1
环境：
OS\DB: AIX 5.3\oracle 10.2.0.2 64-bit
OS\DB: HP-Unix\oracle 10.2.0.2 64-bit
现象：
查看当前undo表空间使用率：
SQL>select t.tablespace_name, total, free, round(100*(1-(free/total)),3)||'%' 已使用的空间比例
from (select tablespace_name, sum(bytes)/1024/1024 total from dba_data_files
where tablespace_name='UNDOTBS1'
group by tablespace_name) t,
(select tablespace_name, sum(bytes)/1024/1024 free from dba_free_space
group by tablespace_name) f where t.tablespace_name=f.tablespace_name(+)
order by tablespace_name;
TABLESPACE_NAME TOTAL FREE 已使用的空间比例
------------------------------ ---------- ---------- -----------------------------------------
UNDOTBS1 39000 1442.0625 95.027%
undo表空间是非自动扩展的：
SQL> Select file_name,Autoextensible From Dba_Data_Files
2 Where tablespace_name='UNDOTBS1'
3 Order By File_id;
FILE_NAME AUTOEXTENSIBLE
-------------------------------------------------------------------------------- --------------
/gsfs02/oradata/CICGSFSP/undotbs01.dbf NO
/gsfs03/oradata/CICGSFSP/undotbs02.dbf NO
.........
SQL> show parameter undo_retention
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
undo_retention integer 1800
解决：
设表空间为自动扩展并设表空间最大值为表空间现在大小，其作用跟表空不自动扩展效果是一样的，这样避免这个bug的产生
--生成修改数据文件脚本
Select 'alter database datafile ''' || file_name || ''' Autoextend on ' || 'Maxsize ' || to_char(bytes/1024/1024) || 'm;' From Dba_Data_Files
Where tablespace_name='UNDOTBS1'
Order By File_id
alter database datafile '/gsfs02/oradata/CICGSFSP/undotbs01.dbf' Autoextend on Maxsize 2000m;
alter database datafile '/gsfs03/oradata/CICGSFSP/undotbs02.dbf' Autoextend on Maxsize 2000m;
alter database datafile '/gsfs04/oradata/CICGSFSP/undotbs03.dbf' Autoextend on Maxsize 2000m;
alter database datafile '/gsfs05/oradata/CICGSFSP/undotbs04.dbf' Autoextend on Maxsize 2000m;
.......
SQL> select to_char(sysdate,'yyyy-mm-dd hh34:mi:ss') from dual;
TO_CHAR(SYSDATE,'YYYY-MM-DDHH2
------------------------------
2010-10-29 10:40:03
然后执行其脚本修改数据文件自动扩展属性为on
第隔几分钟再次观察undo表空间使用情况，使用率在直线下降:
TABLESPACE_NAME TOTAL FREE 已使用的空间比例
------------------------------ ---------- ---------- -----------------------------------------
UNDOTBS1 29000 3790.0625 86.931%
TABLESPACE_NAME TOTAL FREE 已使用的空间比例
------------------------------ ---------- ---------- -----------------------------------------
UNDOTBS1 29000 10837.0625 62.631%
TABLESPACE_NAME TOTAL FREE 已使用的空间比例
------------------------------ ---------- ---------- -----------------------------------------
UNDOTBS1 38000 27496.9375 27.64%
然后再看看一重要视图v$undostat的tuned_undoretention字段的建议值：
--2010-10-29 10:42:18 这个时间正好是我修改完数据文件属性之后的时间
SQL> select to_char(begin_time,'yyyy-mm-dd hh34:mi:ss'),to_char(end_time,'yyyy-mm-dd hh34:mi:ss'),undoblks,tuned_undoretention,maxquerylen,maxqueryid from v$undostat WHERE rownum < 20;
TO_CHAR(BEGIN_TIME,'YYYY-MM-DD TO_CHAR(END_TIME,'YYYY-MM-DDHH UNDOBLKS TUNED_UNDORETENTION MAXQUERYLEN MAXQUERYID
------------------------------ ------------------------------ ---------- ------------------- ----------- -------------
2010-10-29 10:52:18 2010-10-29 10:56:39 1128 1800 88 5kma9ywsgcwhm
2010-10-29 10:42:18 2010-10-29 10:52:18 6848 1800 88 5kma9ywsgcwhm
2010-10-29 10:32:18 2010-10-29 10:42:18 5847 345600 200 cykr0t05sxa73
2010-10-29 10:22:18 2010-10-29 10:32:18 3770 345600 199 70r1113n3vwyu
2010-10-29 10:12:18 2010-10-29 10:22:18 5014 345600 105 4cp98gmy1q8qk
2010-10-29 10:02:18 2010-10-29 10:12:18 5292 345600 229 3156qc5zh6pwn
2010-10-29 09:52:18 2010-10-29 10:02:18 4113 345600 142 1amcb16ytfpbx
2010-10-29 09:42:18 2010-10-29 09:52:18 6184 345600 79 7qbdzfacr8srx
2010-10-29 09:32:18 2010-10-29 09:42:18 3939 345600 78 bunvx480ynf57
2010-10-29 09:22:18 2010-10-29 09:32:18 5575 345600 56 3s4zvp29gjsz0
看完上述内容是否对您有帮助呢？如果还想对相关知识有进一步的了解或阅读更多相关文章，请关注创新互联行业资讯频道，感谢您对创新互联的支持。
