一次带大字段表记录暴增(LOBSEGMENT)引发的悲剧
2012-03-20 17:40
477 查看
事件起因:ORACLE主库进行例行周期性停机后应用相关人员确认数据交换程序时未发现交换异常,
导致该交换程序连接其中一个数据库成功,连接另外一个数据库失败,因此不断的向连接成功的数据库的状态控制表中写入交换异常的数据,而控制表中有CLOB字段记录所有的出错信息。该程序在周末跑了约24H,导致产生120W条垃圾数据,耗费表空间10G以上。
故障定位处理过程:
1、发现监控系统报告USERS表空间99%使用率
我们通过如下语句查USERS表空间有哪些对象
故障定位处理过程:
1、发现监控系统报告USERS表空间99%使用率
我们通过如下语句查USERS表空间有哪些对象
select owner,segment_name,segment_type,bytes from dba_segments a where a.tablespace_name='USERS'
……………………
8 SNDFC SYS_LOB0000077141C00012$$ LOBSEGMENT 18817744896
17 SNDFC SYS_LOB0000094212C00003$$ LOBSEGMENT 10583277568
15 SNDFC SYS_LOB0000092081C00012$$ LOBSEGMENT 2824863744
13 SNDFC SYS_LOB0000077219C00003$$ LOBSEGMENT 2618294272
12 SNDFC SYS_LOB0000077219C00008$$ LOBSEGMENT 38797312
24 SNDFC SYS_IL0000077219C00003$$ LOBINDEX 26214400
19 SNDFC SYS_IL0000077141C00012$$ LOBINDEX 8388608
18 SNDFC SYS_LOB0000077029C00008$$ LOBSEGMENT 4194304
14 SNDFC SYS_LOB0000077192C00007$$ LOBSEGMENT 3145728
23 SNDFC SYS_IL0000077219C00008$$ LOBINDEX 131072
28 SNDFC SYS_IL0000094212C00003$$ LOBINDEX 131072
21 SNDFC SYS_IL0000077227C00008$$ LOBINDEX 65536
22 SNDFC SYS_IL0000077227C00004$$ LOBINDEX 65536
26 SNDFC SYS_IL0000092081C00012$$ LOBINDEX 65536
27 SNDFC SYS_IL0000094212C00008$$ LOBINDEX 65536
25 SNDFC SYS_IL0000077192C00007$$ LOBINDEX 65536
29 SNDFC SYS_IL0000077029C00008$$ LOBINDEX 65536
20 SNDFC SYS_IL0000077087C00005$$ LOBINDEX 65536
9 SNDFC SYS_LOB0000077087C00005$$ LOBSEGMENT 65536
16 SNDFC SYS_LOB0000094212C00008$$ LOBSEGMENT 65536
10 SNDFC SYS_LOB0000077227C00008$$ LOBSEGMENT 65536
11 SNDFC SYS_LOB0000077227C00004$$ LOBSEGMENT 65536
很惊奇的发现里面竟然没有数据表,显然SYS_LOB0000077141C00012$$等几个大的对象占据了存储空间。
因为属性是LOBSEGMENT,马上想到是大对象的表发生了大量的数据增长。
于是动用如下SQL语句,查处大字段对象:
SELECT A.TABLE_NAME,
A.COLUMN_NAME,
B.SEGMENT_NAME,
B.SEGMENT_TYPE,
B.TABLESPACE_NAME,
B.BYTES / 1024 / 1024,
B.BLOCKS,
B.EXTENTS
FROM USER_LOBS A, USER_SEGMENTS B
WHERE A.SEGMENT_NAME = B.SEGMENT_NAME
ORDER BY B.BYTES DESC;
查询结果如下:
TABLE_NAME COLUMN_NAME SEGMENT_NAME SEGMENT_TYPE TABLESPACE_NAME B.BYTES/1024/1024
SNDFC_EXCHANGE_LOG_INFO ERROR_TRACE SYS_LOB0000077141C00012$$ LOBSEGMENT USERS 17946
SNDFC_SEND_CONTROL_HISTORY CONTENT SYS_LOB0000094212C00003$$ LOBSEGMENT USERS 10093
TMP_SNDFC_EXCHANGE_LOG_INFO ERROR_TRACE SYS_LOB0000125221C00012$$ LOBSEGMENT IN_SNDFC_DATA 5857
SNDFC_EXCHANGE_LOG_HISTORY ERROR_TRACE SYS_LOB0000092081C00012$$ LOBSEGMENT USERS 2694
SNDFC_SEND_CONTROL CONTENT SYS_LOB0000077219C00003$$ LOBSEGMENT USERS 2497
SNDFC_SEND_CONTROL ERR_TRACE SYS_LOB0000077219C00008$$ LOBSEGMENT USERS 37
SNDFC_COM_RESOURCE FILE_BLOB SYS_LOB0000077029C00008$$ LOBSEGMENT USERS 4
SNDFC_NOTICE_FILE DOC_CONTENT SYS_LOB0000077192C00007$$ LOBSEGMENT USERS 3
BIN$pIfKdb4Sv0LgQBqsDaM1Tg==$0 ERROR_TRACE SYS_LOB0000125215C00012$$ LOBSEGMENT IN_SNDFC_DATA 0.6875
SNDFC_AUTO_PORT_BARRIER_LOG EXCEPTION_STACK SYS_LOB0000102643C00011$$ LOBSEGMENT IN_SNDFC_DATA 0.375
TMP_SAVE_TABLEDDL TABLE_SQL SYS_LOB0000117696C00002$$ LOBSEGMENT IN_SNDFC_DATA 0.125
TMP_SAVE_INDEXDDL INDEX_SQL SYS_LOB0000117779C00002$$ LOBSEGMENT IN_SNDFC_DATA 0.0625
SNDFC_SEND_CONTROL_HISTORY ERR_TRACE SYS_LOB0000094212C00008$$ LOBSEGMENT USERS 0.0625
SNDFC_SEND_CONTROL_HIS CONTENT SYS_LOB0000077227C00004$$ LOBSEGMENT USERS 0.0625
SNDFC_SEND_CONTROL_HIS ERR_TRACE SYS_LOB0000077227C00008$$ LOBSEGMENT USERS 0.0625
SNDFC_ENTRY_RESOURCE FILE_BLOB SYS_LOB0000077087C00005$$ LOBSEGMENT USERS 0.0625
BIN$pHyd9j2iK0vgQBqsDaNWjQ==$0 ERROR_TRACE SYS_LOB0000124975C00012$$ LOBSEGMENT IN_SNDFC_DATA 0.0625
根据以上查询,显然SNDFC_EXCHANGE_LOG_INFO表上的SYS_LOB0000077141C00012$$对象作用了17G的空间。
正巧应用值班人员反馈某业务的数据交换程序出错,而出错的交换表中正巧有大字段对象,再一确认就是SNDFC_EXCHANGE_LOG_INFO表。
查该表总记录数和事件发生当天记录数:
SQL> Select Count(*) From sndfc_exchange_log_info t Where to_char(modi_date,'yyyymmdd')='20110529';
COUNT(*)
----------
1492157
SQL> Select Count(*) From sndfc_exchange_log_info t;
COUNT(*)
----------
2043454
该表保存一个月的记录,总记录数量204W,但该天的记录数量达到149W,显然存在问题。
怎么处理这149W条记录,必须新建一张临时表sndfc_exchange_log_info_new,然后把需要的记录移动到该表,
把sndfc_exchange_log_info重命名为sndfc_exchange_log_info_old
再TRUNCATE原先的sndfc_exchange_log_info_old表释放空间,然后把sndfc_exchange_log_info_new重命名
为sndfc_exchange_log_info(注意主键和索引等约束)。
其实表数据的删除还是比较容易的,但是最悲剧的是我们的DATAGUARD环境磁盘非常紧缺。 为了移动sndfc_exchange_log_info的数据,必须增大USERS表空间,而增大USERS表空间备库相应目录就会不足, 昨天为了处理备库相应目录不足问题已经颇费周折,在此简单回顾下。链接:http://yunlongzheng.blog.51cto.com/788996/578973
导致该交换程序连接其中一个数据库成功,连接另外一个数据库失败,因此不断的向连接成功的数据库的状态控制表中写入交换异常的数据,而控制表中有CLOB字段记录所有的出错信息。该程序在周末跑了约24H,导致产生120W条垃圾数据,耗费表空间10G以上。
故障定位处理过程:
1、发现监控系统报告USERS表空间99%使用率
我们通过如下语句查USERS表空间有哪些对象
故障定位处理过程:
1、发现监控系统报告USERS表空间99%使用率
我们通过如下语句查USERS表空间有哪些对象
select owner,segment_name,segment_type,bytes from dba_segments a where a.tablespace_name='USERS'
……………………
8 SNDFC SYS_LOB0000077141C00012$$ LOBSEGMENT 18817744896
17 SNDFC SYS_LOB0000094212C00003$$ LOBSEGMENT 10583277568
15 SNDFC SYS_LOB0000092081C00012$$ LOBSEGMENT 2824863744
13 SNDFC SYS_LOB0000077219C00003$$ LOBSEGMENT 2618294272
12 SNDFC SYS_LOB0000077219C00008$$ LOBSEGMENT 38797312
24 SNDFC SYS_IL0000077219C00003$$ LOBINDEX 26214400
19 SNDFC SYS_IL0000077141C00012$$ LOBINDEX 8388608
18 SNDFC SYS_LOB0000077029C00008$$ LOBSEGMENT 4194304
14 SNDFC SYS_LOB0000077192C00007$$ LOBSEGMENT 3145728
23 SNDFC SYS_IL0000077219C00008$$ LOBINDEX 131072
28 SNDFC SYS_IL0000094212C00003$$ LOBINDEX 131072
21 SNDFC SYS_IL0000077227C00008$$ LOBINDEX 65536
22 SNDFC SYS_IL0000077227C00004$$ LOBINDEX 65536
26 SNDFC SYS_IL0000092081C00012$$ LOBINDEX 65536
27 SNDFC SYS_IL0000094212C00008$$ LOBINDEX 65536
25 SNDFC SYS_IL0000077192C00007$$ LOBINDEX 65536
29 SNDFC SYS_IL0000077029C00008$$ LOBINDEX 65536
20 SNDFC SYS_IL0000077087C00005$$ LOBINDEX 65536
9 SNDFC SYS_LOB0000077087C00005$$ LOBSEGMENT 65536
16 SNDFC SYS_LOB0000094212C00008$$ LOBSEGMENT 65536
10 SNDFC SYS_LOB0000077227C00008$$ LOBSEGMENT 65536
11 SNDFC SYS_LOB0000077227C00004$$ LOBSEGMENT 65536
很惊奇的发现里面竟然没有数据表,显然SYS_LOB0000077141C00012$$等几个大的对象占据了存储空间。
因为属性是LOBSEGMENT,马上想到是大对象的表发生了大量的数据增长。
于是动用如下SQL语句,查处大字段对象:
SELECT A.TABLE_NAME,
A.COLUMN_NAME,
B.SEGMENT_NAME,
B.SEGMENT_TYPE,
B.TABLESPACE_NAME,
B.BYTES / 1024 / 1024,
B.BLOCKS,
B.EXTENTS
FROM USER_LOBS A, USER_SEGMENTS B
WHERE A.SEGMENT_NAME = B.SEGMENT_NAME
ORDER BY B.BYTES DESC;
查询结果如下:
TABLE_NAME COLUMN_NAME SEGMENT_NAME SEGMENT_TYPE TABLESPACE_NAME B.BYTES/1024/1024
SNDFC_EXCHANGE_LOG_INFO ERROR_TRACE SYS_LOB0000077141C00012$$ LOBSEGMENT USERS 17946
SNDFC_SEND_CONTROL_HISTORY CONTENT SYS_LOB0000094212C00003$$ LOBSEGMENT USERS 10093
TMP_SNDFC_EXCHANGE_LOG_INFO ERROR_TRACE SYS_LOB0000125221C00012$$ LOBSEGMENT IN_SNDFC_DATA 5857
SNDFC_EXCHANGE_LOG_HISTORY ERROR_TRACE SYS_LOB0000092081C00012$$ LOBSEGMENT USERS 2694
SNDFC_SEND_CONTROL CONTENT SYS_LOB0000077219C00003$$ LOBSEGMENT USERS 2497
SNDFC_SEND_CONTROL ERR_TRACE SYS_LOB0000077219C00008$$ LOBSEGMENT USERS 37
SNDFC_COM_RESOURCE FILE_BLOB SYS_LOB0000077029C00008$$ LOBSEGMENT USERS 4
SNDFC_NOTICE_FILE DOC_CONTENT SYS_LOB0000077192C00007$$ LOBSEGMENT USERS 3
BIN$pIfKdb4Sv0LgQBqsDaM1Tg==$0 ERROR_TRACE SYS_LOB0000125215C00012$$ LOBSEGMENT IN_SNDFC_DATA 0.6875
SNDFC_AUTO_PORT_BARRIER_LOG EXCEPTION_STACK SYS_LOB0000102643C00011$$ LOBSEGMENT IN_SNDFC_DATA 0.375
TMP_SAVE_TABLEDDL TABLE_SQL SYS_LOB0000117696C00002$$ LOBSEGMENT IN_SNDFC_DATA 0.125
TMP_SAVE_INDEXDDL INDEX_SQL SYS_LOB0000117779C00002$$ LOBSEGMENT IN_SNDFC_DATA 0.0625
SNDFC_SEND_CONTROL_HISTORY ERR_TRACE SYS_LOB0000094212C00008$$ LOBSEGMENT USERS 0.0625
SNDFC_SEND_CONTROL_HIS CONTENT SYS_LOB0000077227C00004$$ LOBSEGMENT USERS 0.0625
SNDFC_SEND_CONTROL_HIS ERR_TRACE SYS_LOB0000077227C00008$$ LOBSEGMENT USERS 0.0625
SNDFC_ENTRY_RESOURCE FILE_BLOB SYS_LOB0000077087C00005$$ LOBSEGMENT USERS 0.0625
BIN$pHyd9j2iK0vgQBqsDaNWjQ==$0 ERROR_TRACE SYS_LOB0000124975C00012$$ LOBSEGMENT IN_SNDFC_DATA 0.0625
根据以上查询,显然SNDFC_EXCHANGE_LOG_INFO表上的SYS_LOB0000077141C00012$$对象作用了17G的空间。
正巧应用值班人员反馈某业务的数据交换程序出错,而出错的交换表中正巧有大字段对象,再一确认就是SNDFC_EXCHANGE_LOG_INFO表。
查该表总记录数和事件发生当天记录数:
SQL> Select Count(*) From sndfc_exchange_log_info t Where to_char(modi_date,'yyyymmdd')='20110529';
COUNT(*)
----------
1492157
SQL> Select Count(*) From sndfc_exchange_log_info t;
COUNT(*)
----------
2043454
该表保存一个月的记录,总记录数量204W,但该天的记录数量达到149W,显然存在问题。
怎么处理这149W条记录,必须新建一张临时表sndfc_exchange_log_info_new,然后把需要的记录移动到该表,
把sndfc_exchange_log_info重命名为sndfc_exchange_log_info_old
再TRUNCATE原先的sndfc_exchange_log_info_old表释放空间,然后把sndfc_exchange_log_info_new重命名
为sndfc_exchange_log_info(注意主键和索引等约束)。
其实表数据的删除还是比较容易的,但是最悲剧的是我们的DATAGUARD环境磁盘非常紧缺。 为了移动sndfc_exchange_log_info的数据,必须增大USERS表空间,而增大USERS表空间备库相应目录就会不足, 昨天为了处理备库相应目录不足问题已经颇费周折,在此简单回顾下。链接:http://yunlongzheng.blog.51cto.com/788996/578973
相关文章推荐
- 一次带大字段表记录暴增(LOBSEGMENT)引发的悲剧 推荐
- 一次带大字段表记录暴增(LOBSEGMENT)引发的悲剧
- 一次修改mysql字段类型引发的技术探究
- ORACLE sql调优之记录一次trim函数引发的大表全表扫描
- LOB字段导入遇出现ORA-00959错误, 并由此引发IMP-00017和IMP-00003错误
- 记录一次Bug修改__数据库连接不关闭引发的bug
- 记录一次使用_RecordsetPtr去访问已有表的新增字段时,出现的怪异问题!
- 一次app抓包引发的Android分析记录
- 记录一次阻塞引发的系统超时
- 一次类型强转后引发的segment fault
- 记录一次JDK版本问题,引发的思考
- ORACLE同一次查询取同一字段的前(后)N条记录
- 一次app抓包引发的Android分析记录
- 关于 OGG "Loading data from file to Replicat"同步含有lob字段表的部分记录的关键参数
- MongoDB经验教训:一次批量删除历史数据引发的悲剧
- ORACLE sql调优之记录一次trim函数引发的大表全表扫描
- SQL Server 数据库中SQL优化的一次记录
- MyBatis获取插入记录的自增长字段值
- 一个破手机引发的悲剧
- 静电引发的悲剧