资讯专栏INFORMATION COLUMN

从一个案例谈谈永久表空间的临时段问题

IT那活儿 / 541人阅读
从一个案例谈谈永久表空间的临时段问题
点击上方“IT那活儿”公众号,关注后了解更多内容,不管IT什么活儿,干就完了!!!

  
6月的某一天,我们一个工程师说有个表空间使用率一直在不断增长,已经使用了93%,业务反馈未有大数据批量变更,也无新业务上线,临时想扩容,但无法扩容。于是这个事情转交我来解决,下面我就此案例和大家分享。




事情解决过程




我们分析问题一般从头开始, 先看看表空间使用率,XX表空间占了93.43%。
为了知道谁占用的空间比较多,对该XX表空间的对象进行分析,发现临时段占用了3.2T,接近此表空间的50%。
为了临时解决问题,我想先扩容,可发现该表空间是bigfile tablespace不能增加文件,且只能临时把autoextend 改为on,但不是长久之计。
既然是临时段,从理论上smon后台进程应该会对其进行自动回收,可为什么会出现问题呢?
先查查是什么类型没释放,发现有undo,drop等post。于是想会不会是无效索引或导数据未正常关闭引起呢? 正就是顺着这个思路去排查问题。
确实有not running 的导数job和无效索引,清掉处理后,观察临时段的情况。
临时段依然在增长,那是否是smon未唤醒,那就手工处理一下吧!

select pid,spid from v$process where program like %SMON%;
PID SPID
---------- ------------------------------------------------
32 227051
SQL> oradebug setorapid 32;
Unix process pid: 525418, image: (SMON)
SQL> oradebug event 10046 trace name context forever,level 1;
Statement processed.
SQL> oradebug tracefile_name
/u01/app/oracle/diag/rdbms/dbm/dbm1/trace/dbm1_smon_227051.trc
SQL> oradebug wakeup 32;
Statement processed.
SQL> oradebug wakeup 32;
Statement processed.
SQL>
查看等待事件smon进程有等待,手动触发smon进程后,有触发成功,存在update scn_time时间撮语句,但是临时段还是未释放。
那到底是什么引起的, 观察一下后台日志alert,并同时上mos官网查询解决办法,出具了三个方案:
方案一:SMON自动清理临时段
level - tablespace number+1. If the value is 2147483647 then
temp segments in ALL tablespaces are dropped, otherwise, only
segments in a tablespace whose number is equal to the LEVEL
specification are dropped.
select ts# from v$tablespace where name=TBS_1M_SPACE;
alter session set events immediate trace name DROP_SEGMENTS level 17;
alter session set events immediate trace name DROP_SEGMENTS level 2147483647;
方案二:手工清理临时段
1) set event 10061 in the pfile to turn off SMON from cleaning temp segments. This will keep the database from crashing after SMON tries 100 times to clean the segment.
event = 10061 trace name context forever, level 10


2) >select segment_name, segment_type from dba_segments where
header_file=98 and segment_type=TEMPORARY;
SEGMENT_NAME SEGMENT_TYPE
------------------- -----------------------
98.110124                TEMPORARY
98.110124 <---------- datafile and block number
If there are no results make sure the datafile reference is not using the relative file number.
>select rfile#,name,ts#,file# from v$datafile;


3) Mark the segment as corrupted:
exec dbms_space_admin.segment_corrupt(,98,110124)
OR
You can generate a script for all segments using the following :
set lines 5000
set long 9999
set pages 999
set head off
spool corrupt.sql
select exec dbms_space_admin.segment_corrupt(||s.tablespace_name||||,||replace (segment_name,.,,)||)||; from dba_segments s ,dba_tablespaces t where s.TABLESPACE_NAME=upper(&Tablespace_name)
and s.segment_type=TEMPORARY
and t.contents=PERMANENT
and s.TABLESPACE_NAME=t.TABLESPACE_NAME;
spool off
Then execute the sript corrupt.sql
@corrupt.sql


4) Drop the segment
exec dbms_space_admin.segment_drop_corrupt(,98,110124)
OR
You can generate a script for all segments using the following :
spool drop.sql
set lines 5000
set long 9999
set pages 999
set head off
select exec dbms_space_admin.segment_drop_corrupt(||s.tablespace_name||||,||SEGMENT_NAME||)||; from dba_segments s ,dba_tablespaces t where s.TABLESPACE_NAME=upper(&Tablespace_name)
and s.segment_type=TEMPORARY
and t.contents=PERMANENT
and s.TABLESPACE_NAME=t.TABLESPACE_NAME;
spool off
Then execute the sript drop.sql
@drop.sql


5) Rebuild the tablespace bitmap(s)
exec dbms_space_admin.tablespace_rebuild_bitmaps()
;


6) Remove event 10061 from pfile and bounce database


7) exec dbms_space_admin.tablespace_verify ();
方案三:重启数据库

关闭各个实例,并启动数据库。

对比三个方案和评估后,采取了第一个方案进行实施,但最后还是未解决。

到最后把整个思路重新整理了一下,并同时发现差一个环节,会不会是业务侧的问题?
于是逐个排查历史SQL,发现有需多etl程序在创建临时表,虽然没有在跑,但可能是hang住了,并看了sql的执行计划有些异常,bytes居然占了几百G,于是和业务协商,将有问题的进程强制kill后,再手动触smon进程,临时段最后得到完全释放,事情得到解决




事情总结




解决问题的前提,需先熟悉整个问题环节和理论原理,下面就上面案例做一些提取。

1. 临时段何时产生

  • 创建表(普通表或分区);
  • 索引重建rebuild;
  • DROP TABLE;
  • Create snapshot。
2. 临时段的类别
  • 临时表空间的临时段,永久表空间的临时段,一般永久表空间的临时段smon会自动清理,临时表空间的临时段可以通过重启实例或重建临时表空间解决。

3. 临时段的处理方法
  • Smon触发处理;
  • 手动处理,风险极高,不推荐使用;
  • 分析业务逻辑及业务代码,优化后进行释放。


本文作者:唐田寿(上海新炬王翦团队)

本文来源:“IT那活儿”公众号

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/129410.html

相关文章

  • 专访58沈剑:除了架构,我还想认真谈谈管理

    摘要:年月日,第届技术管理工作坊将在深圳华侨城洲际酒店举行。壹佰案例在开始前采访了沈剑老师,先行剧透架构师转型做管理的感悟。 showImg(https://segmentfault.com/img/bVxMfU);2016年6月25-26日,第27届MPD技术管理工作坊将在深圳华侨城洲际酒店举行。本次工作坊,我们邀请了58到家技术总监沈剑老师,分享《技术团队的接手、搭建与发展实践 》, 讲...

    masturbator 评论0 收藏0
  • 云计算“大机会时代”开启,云计算巨头们如何不要机会主义

    摘要:云计算正以空前的发展速度,迎来自己的大机会时代。月日,金山云财报,云业务营收亿元,同比增长。因此,对每个正在行业里寻找机会的企业来说,任正非先生说的一番话似乎都非常值得共同重温一下他说在大机会时代,千万不要机会主义,反而要有战略耐性。后疫情时代,情势倒逼生产服务场景和消费场景快速线上化,数据显示,2020年以来,即使按照最保守的口径估计,中国远程办公企业规模超过1800万家,远程办公人员超过...

    Tecode 评论0 收藏0
  • 一文详解MySQL的锁机制

    摘要:表级锁表级锁表级别的锁定是各存储引擎中最大颗粒度的锁定机制。当前没有其他事务持有表中任意一行的排他锁。为了检测是否满足第二个条件,事务必须在确保表不存在任何排他锁的前提下,去检测表中的每一行是否存在排他锁。一、表级锁、行级锁、页级锁数据库锁定机制简单来说,就是数据库为了保证数据的一致性,而使各种共享资源在被并发访问变得有序所设计的一种规则。MySQL数据库由于其自身架构的特点,存在多种数据存...

    番茄西红柿 评论0 收藏2637
  • 单系统站内信设计概述

    摘要:也可以在凌晨系统不是那么繁忙的时候操作。总结一下少量用户设计简单,但浪费空间,冗余高中量用户设计较简单,对表的操作压力大大量用户这不是增加几个表能解决的问题 基本功能 点到点的消息传送: 用户给用户 管理员给用户 点到面的消息传送 管理员给用户群 少量用户(10-999) 对于用户非常少的情况,没有必要深入的考虑数据库的优化,采用简单的表设计: 如表message ...

    Rainie 评论0 收藏0

发表评论

0条评论

IT那活儿

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<