Oracle版本:Oracle11g R2 x64 11.2.0.4
标准版
(RAC
)
操作系统:Oracle Linux Server release 6.5
RAC双节点，三SCANIP
实体机型号无法知道，因利用VM虚拟化
在工作上，因业务需求需要针对某些表记录历史操作，经过考虑，先在开发库上测试闪回数据归档功能，为其中一张9k+行，约3M的业务表开启闪回数据归档功能，将会存放在一个新的表空间中，5G，不可扩展。经过几日的观察，发现正常记录历史操作并且没有发现异常问题。所以于6月15日18:00在生成环境开启闪回数据归档功能。具体脚本如下：
--利用sys用戶创建用于闪回数据归档的表空间
create tablespace fbda
datafile '+DBDATA' size 5G autoextend off;
--利用sys用戶创建默认闪回数据归档
create flashback archive default flashar tablespace fbda retention 1 month;
--利用Wilson用戶为表T 1设置闪回数据归档
alter table " T 1 " flashback archive flashar;-- Wilson
在6月16日早上约9点至10点之间，工作人员反馈说业务无法正常使用，后台代码报错，之后在数据库alert.log中发现UNDO表空间已经爆了，
实际上查看 alert.log发现在16号凌晨约3点左右每个1个小时就报错 ORA-1652，只是可能当时UNDO已经释放空间，能够继续维持使用
提示ORA-1652: unable to extend temp segment by 8 in tablespace UNDOTBS1
之后发现UNDO数据文件已经达到最大值，为此先保证业务，首先为 UNDOTBS1和UNDOTBS2添加datafile，并且怀疑是闪回数据归档引起的问题，所以把闪回数据归档关闭，脚本如下：
--发现undotbs问题之后关闭闪回数据归档
alter table "T1" no flashback archive;-- Wilson
drop flashback archive FLASHAR;--SYS
drop tablespace fbda including contents and datafile;--SYS
之后可以看到数据库没有报错，正常运行下去，业务也可继续操作，但在当天由于需要expdp一份生成环境数据下来，运维部门发现硬盘空间不足，仔细发现，
是由于16号凌晨4点的自动JOB的RMAN1级增量备份占用空间太大，导致硬盘空间不足，通过SQL查询，发现正常情况下一天的归档不到1G，但就在15号整天的归档量已经达到50G+，
16号的归档量达到100G+，具体查询归档量SQL如下：
SELECT SUM(BLOCKS *BLOCK_SIZE )/1024/1024/1024 AS "Size(G)",TRUNC(completion_time) completion_time FROM v$archived_log
--where DELETED!='YES'
GROUP BY TRUNC(completion_time) order by completion_time desc
后来发现alert.log日志中，从我15日18:00开启闪回数据归档，从15日19:30就开始每隔半分钟就切换一次日志，直到解决问题前，基本上两节点都是约半分钟就切换一次日志，所以归档量才暴涨，
之后通过挖包，想查看不断切换日志生成的归档中究竟做了什么操作导致归档量如此的大，挖了几个归档通过查看v$logmnr_contents发现基本上都是在每一秒都对SYS用户下的表SYS_FBA_BARRIERSCN中的字段BARRIERSCN和字段ACTIVESCN不断作更新操作，信息如下：
/*
表T1的数据类型基本上为VARCHAR2/Number/Timestamp，不存在LOB相关的字段
*/
......此份归档约99774行数据，其中98%都是以上表中的操作，少部分为业务操作， 最后一行的 TIMESTAMP为 2015-06-18 09:05:15
查看该表 SYS_FBA_BARRIERSCN信息大概为以下内容
inst_id barrierscn activescn status spare
1 具体scn号 具体scn号 1 (null)
2 具体scn号 具体scn号 1 (null)
尝试每秒刷新一次，两行数据中的字段 BARRIERSCN和字段ACTIVESCN基本上 （具体scn号=具体scn号+4000 ）
***********************************
到这里，基本上可以判断归档量暴涨的原因在于对 该表 SYS_FBA_BARRIERSCN存在大量更新操作，那么为什么呢？
解决方案：
2. alter system set "_fbda_debug_mode"=8;
3. delete from sys.sys_fba_barrierscn where inst_id=1;(暴涨的实例上面)
4.commit;
5. alter system set "_fbda_debug_mode"=0;
6. alter system flush shared_pool;
基本就解决了
操作系统:Oracle Linux Server release 6.5
RAC双节点，三SCANIP
实体机型号无法知道，因利用VM虚拟化
在工作上，因业务需求需要针对某些表记录历史操作，经过考虑，先在开发库上测试闪回数据归档功能，为其中一张9k+行，约3M的业务表开启闪回数据归档功能，将会存放在一个新的表空间中，5G，不可扩展。经过几日的观察，发现正常记录历史操作并且没有发现异常问题。所以于6月15日18:00在生成环境开启闪回数据归档功能。具体脚本如下：
--利用sys用戶创建用于闪回数据归档的表空间
create tablespace fbda
datafile '+DBDATA' size 5G autoextend off;
--利用sys用戶创建默认闪回数据归档
create flashback archive default flashar tablespace fbda retention 1 month;
--利用Wilson用戶为表T 1设置闪回数据归档
alter table " T 1 " flashback archive flashar;-- Wilson
在6月16日早上约9点至10点之间，工作人员反馈说业务无法正常使用，后台代码报错，之后在数据库alert.log中发现UNDO表空间已经爆了，
实际上查看 alert.log发现在16号凌晨约3点左右每个1个小时就报错 ORA-1652，只是可能当时UNDO已经释放空间，能够继续维持使用
提示ORA-1652: unable to extend temp segment by 8 in tablespace UNDOTBS1
之后发现UNDO数据文件已经达到最大值，为此先保证业务，首先为 UNDOTBS1和UNDOTBS2添加datafile，并且怀疑是闪回数据归档引起的问题，所以把闪回数据归档关闭，脚本如下：
--发现undotbs问题之后关闭闪回数据归档
alter table "T1" no flashback archive;-- Wilson
drop flashback archive FLASHAR;--SYS
drop tablespace fbda including contents and datafile;--SYS
之后可以看到数据库没有报错，正常运行下去，业务也可继续操作，但在当天由于需要expdp一份生成环境数据下来，运维部门发现硬盘空间不足，仔细发现，
是由于16号凌晨4点的自动JOB的RMAN1级增量备份占用空间太大，导致硬盘空间不足，通过SQL查询，发现正常情况下一天的归档不到1G，但就在15号整天的归档量已经达到50G+，
16号的归档量达到100G+，具体查询归档量SQL如下：
SELECT SUM(BLOCKS *BLOCK_SIZE )/1024/1024/1024 AS "Size(G)",TRUNC(completion_time) completion_time FROM v$archived_log
--where DELETED!='YES'
GROUP BY TRUNC(completion_time) order by completion_time desc
后来发现alert.log日志中，从我15日18:00开启闪回数据归档，从15日19:30就开始每隔半分钟就切换一次日志，直到解决问题前，基本上两节点都是约半分钟就切换一次日志，所以归档量才暴涨，
之后通过挖包，想查看不断切换日志生成的归档中究竟做了什么操作导致归档量如此的大，挖了几个归档通过查看v$logmnr_contents发现基本上都是在每一秒都对SYS用户下的表SYS_FBA_BARRIERSCN中的字段BARRIERSCN和字段ACTIVESCN不断作更新操作，信息如下：
/*
表T1的数据类型基本上为VARCHAR2/Number/Timestamp，不存在LOB相关的字段
*/
| TIMESTAMP | OPERATION | OPERATION_CODE | SEG_OWNER | SEG_NAME | TABLE_NAME | SEG_TYPE | SEG_TYPE_NAME | TABLE_SPACE | DATA_OBJD# | SQL_REDO | SQL_UNDO | INFO |
| 2015-06-18 09:04:38 | START | 6 | 0 | 0 | set transaction read write; | |||||||
| 2015-06-18 09:04:38 | UNSUPPORTED | 255 | SYS | SYS_FBA_BARRIERSCN | SYS_FBA_BARRIERSCN | 2 | TABLE | SYSTEM | 1302 | Unsupported | Unsupported | Object or Data type Unsupported |
| 2015-06-18 09:04:38 | COMMIT | 7 | 0 | 0 | commit; | |||||||
| 2015-06-18 09:04:38 | START | 6 | 0 | 0 | set transaction read write; | |||||||
| 2015-06-18 09:04:38 | UNSUPPORTED | 255 | SYS | SYS_FBA_BARRIERSCN | SYS_FBA_BARRIERSCN | 2 | TABLE | SYSTEM | 1302 | Unsupported | Unsupported | Object or Data type Unsupported |
| 2015-06-18 09:04:38 | COMMIT | 7 | 0 | 0 | commit; | |||||||
| 2015-06-18 09:04:38 | START | 6 | 0 | 0 | set transaction read write; | |||||||
| 2015-06-18 09:04:38 | UNSUPPORTED | 255 | SYS | SYS_FBA_BARRIERSCN | SYS_FBA_BARRIERSCN | 2 | TABLE | SYSTEM | 1302 | Unsupported | Unsupported | Object or Data type Unsupported |
| 2015-06-18 09:04:38 | COMMIT | 7 | 0 | 0 | commit; | |||||||
| 2015-06-18 09:04:38 | START | 6 | 0 | 0 | set transaction read write; | |||||||
| 2015-06-18 09:04:38 | UNSUPPORTED | 255 | SYS | SYS_FBA_BARRIERSCN | SYS_FBA_BARRIERSCN | 2 | TABLE | SYSTEM | 1302 | Unsupported | Unsupported | Object or Data type Unsupported |
| 2015-06-18 09:04:38 | COMMIT | 7 | 0 | 0 | commit; | |||||||
| 2015-06-18 09:04:38 | START | 6 | 0 | 0 | set transaction read write; | |||||||
| 2015-06-18 09:04:38 | UNSUPPORTED | 255 | SYS | SYS_FBA_BARRIERSCN | SYS_FBA_BARRIERSCN | 2 | TABLE | SYSTEM | 1302 | Unsupported | Unsupported | Object or Data type Unsupported |
| 2015-06-18 09:04:38 | COMMIT | 7 | 0 | 0 | commit; | |||||||
| 2015-06-18 09:04:38 | START | 6 | 0 | 0 | set transaction read write; | |||||||
| 2015-06-18 09:04:38 | UNSUPPORTED | 255 | SYS | SYS_FBA_BARRIERSCN | SYS_FBA_BARRIERSCN | 2 | TABLE | SYSTEM | 1302 | Unsupported | Unsupported | Object or Data type Unsupported |
......此份归档约99774行数据，其中98%都是以上表中的操作，少部分为业务操作， 最后一行的 TIMESTAMP为 2015-06-18 09:05:15
查看该表 SYS_FBA_BARRIERSCN信息大概为以下内容
inst_id barrierscn activescn status spare
1 具体scn号 具体scn号 1 (null)
2 具体scn号 具体scn号 1 (null)
尝试每秒刷新一次，两行数据中的字段 BARRIERSCN和字段ACTIVESCN基本上 （具体scn号=具体scn号+4000 ）
***********************************
到这里，基本上可以判断归档量暴涨的原因在于对 该表 SYS_FBA_BARRIERSCN存在大量更新操作，那么为什么呢？
经过调查和提交SR，可能触发了16196536(Many active undo extents with flashback Archive)的BUG
解决方案：
1.重启节点解决
因生产环境存在安全性的考虑，没有调用隐含参数解决，而是通过重启节点解决，先重启节点1，再重启节点2
2.通过调用隐含参数解决
1.create table wilson.sys_fba_barrierscn as select * from sys_fba_barrierscn;2. alter system set "_fbda_debug_mode"=8;
3. delete from sys.sys_fba_barrierscn where inst_id=1;(暴涨的实例上面)
4.commit;
5. alter system set "_fbda_debug_mode"=0;
6. alter system flush shared_pool;
基本就解决了
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/30220976/viewspace-1706140/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/30220976/viewspace-1706140/
573
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
