由Oracle Bug引起的AWR Snapshot收集故障(2)

AWR和其他一些性能收集,的确是不断的将数据收集到sysaux表空间里面进行记录。笔者一直认为:任何正确的数据架构模式,必要条件之一就是“有进有出”。数据不断积累,一定要有机制(系统内或者系统外)让数据可以脱离系统。从微观角度看,数据表要维持一个稳定的体积容量结构。

AWR系统也的确是这样。在不断收集数据的时候,也会依据Retention规则(默认为8天)不断将数据Purge掉。无论如何设置,sysaux正常情况下应该是一个固定稳定的大小规格。笔者当前数据库已经运行一两年的时间,要出问题早就出现问题了。说明系统中,有一些数据在不断的“默默长大”,问题在不断的慢慢积累。

尝试检查当前sysaux表空间段结构排名,看有没有与此相关的信息。

SQL> select owner, segment_name, segment_type, bytes/1024/1024 from (select * from dba_segments where tablespace_name='SYSAUX' order by bytes desc) where rownum<5;

OWNER      SEGMENT_NAME          SEGMENT_TYPE      BYTES/1024/1024

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

SYS  WRM$_SNAPSHOT_DETAILS_INDEX INDEX                          102

SYS  WRM$_SNAPSHOT_DETAILS      TABLE                          88

SYS  SMON_SCN_TO_TIME_AUX      CLUSTER                        80

XDB  SYS_LOB0000057474C00025$$  LOBSEGMENT                53.1875

疑问出现了,最大的几个对象中,snapshot赫然出现在其中。当前Snapshot里面没有数据,无论是被自然purge掉,还是认为删掉,都不应该有数据存在。查看基础数据表:

SQL> select count(*) from WRM$_SNAPSHOT_DETAILS;

COUNT(*)

----------

1723102

SQL> select * from WRM$_SNAPSHOT_DETAILS where rownum<5;

SNAP_ID      DBID INSTANCE_NUMBER  TABLE_ID BEGIN_TIME                   

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

1 1778314713              1          4 05-12??-12 05.00.08.719 ????   

1 1778314713              1          5 05-12??-12 05.00.08.771 ????     

1 1778314713              1          6 05-12??-12 05.00.08.841 ????       

1 1778314713              1          7 05-12??-12 05.00.08.892 ????   

其中数据量还是很大的,重点在于snap_id。

SQL> select max(snap_id), min(snap_id) from WRM$_SNAPSHOT_DETAILS;

MAX(SNAP_ID) MIN(SNAP_ID)

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

23383            1

“慢慢变大”的数据找到了,作为AWR基础的数据,从来就没有被删除。手工删除呢?是不是可以删除?

SQL> select snap_id from dba_hist_snapshot;

SNAP_ID

----------

23383

SQL> exec dbms_workload_repository.drop_snapshot_range(1,23383);

PL/SQL procedure successfully completed

SQL> select snap_id from dba_hist_snapshot;

SNAP_ID

----------

SQL> select max(snap_id), min(snap_id) from WRM$_SNAPSHOT_DETAILS;

MAX(SNAP_ID) MIN(SNAP_ID)

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

23383            1

SQL> select max(snap_id), min(snap_id) from WRM$_SNAPSHOT;

MAX(SNAP_ID) MIN(SNAP_ID)

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

删除的数据,没有连带将基础数据表WRM$_SNAPSHOT_DETAILS内容删除。诡异的问题!

经过查证MOS,发现该数据表不能删除是一个Oracle Bug,具体描述如下:

Bug 9797851 - WRM$_SNAPHOST_DETAILS is never purged

The verification criteria for the bug are:

Drop a range of snap id's using dbms_workload_repository.drop_snapshot_range()

Check the corresponding snap id's in WRM$_SNAPSHOT_DETAILS.

If snap id's from the range that you chose to drop are still present, then you are hitting this bug.

The following solutions are available:

The Patch 9797851 for unpublished Bug 9797851 is available for some platforms and can be downloaded from My Oracle Support

If the patch is not available on your platform on a supported version, please contact Oracle Support.

This issue will be fixed from release Oracle 12.1

As a workaround, it is possible to manually purge the range of snap id's from the table WRM$_SNAPSHOT_DETAILS using appropriate delete statments under the guidance of Oracle Support.

其中内容所,如果要解决这个问题,需要进行补丁操作,或者在Oracle Support指导之下手工进行删除。

由于是生产环境,经过协调,认为当前开启拓展sysaux策略是可以接受的解决方案。于是笔者打算适可而止,不影响系统正常运行。

4、恢复自动AWR收集

最后需要恢复AWR收集。注意:在一些资料中,建议最开始有一个snapshot,通过手工创建,之后Oracle才能自动的进行生成。

为了快速验证,调整收集周期是10分钟。

SQL> exec dbms_workload_repository.create_snapshot;

PL/SQL procedure successfully completed

SQL> exec dbms_workload_repository.modify_snapshot_settings(interval=>10);

PL/SQL procedure successfully completed

SQL> select * from dba_hist_wr_control;

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/961ead341c1dd3713c171aaf2bbbca8a.html