如何理解oracle undo表空间快速扩展

如何理解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

看完上述内容是否对您有帮助呢?如果还想对相关知识有进一步的了解或阅读更多相关文章,请关注亿速云行业资讯频道,感谢您对亿速云的支持。

原创文章,作者:奋斗,如若转载,请注明出处:https://blog.ytso.com/206792.html

(0)
上一篇 2021年12月3日
下一篇 2021年12月3日

相关推荐

发表回复

登录后才能评论