從一個案例談談永久表空間的臨時段問題

IT那活兒發布于2023-01-11 13:19 / 649人閱讀

從一個案例談談永久表空間的臨時段問題

點擊上方“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那活兒”公眾號

云服務器 GPU云服務器 ecs服務器一個時段內的流量查詢方法代理服務器問題案例 js從最后一個輸出從云服務器發布一個網站

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/129410.html

專訪58沈劍：除了架構，我還想認真談談管理

摘要：年月日，第屆技術管理工作坊將在深圳華僑城洲際酒店舉行。壹佰案例在開始前采訪了沈劍老師，先行劇透架構師轉型做管理的感悟。 showImg(https://segmentfault.com/img/bVxMfU);2016年6月25-26日，第27屆MPD技術管理工作坊將在深圳華僑城洲際酒店舉行。本次工作坊，我們邀請了58到家技術總監沈劍老師，分享《技術團隊的接手、搭建與發展實踐》，講...

masturbator 2019-06-21 16:08 評論0 收藏0
云計算“大機會時代”開啟，云計算巨頭們如何不要機會主義

摘要：云計算正以空前的發展速度，迎來自己的大機會時代。月日，金山云財報，云業務營收億元，同比增長。因此，對每個正在行業里尋找機會的企業來說，任正非先生說的一番話似乎都非常值得共同重溫一下他說在大機會時代，千萬不要機會主義，反而要有戰略耐性。后疫情時代，情勢倒逼生產服務場景和消費場景快速線上化，數據顯示，2020年以來，即使按照最保守的口徑估計，中國遠程辦公企業規模超過1800萬家，遠程辦公人員超過...

Tecode 2022-06-28 18:59 評論0 收藏0
一文詳解MySQL的鎖機制

摘要：表級鎖表級鎖表級別的鎖定是各存儲引擎中最大顆粒度的鎖定機制。當前沒有其他事務持有表中任意一行的排他鎖。為了檢測是否滿足第二個條件，事務必須在確保表不存在任何排他鎖的前提下，去檢測表中的每一行是否存在排他鎖。一、表級鎖、行級鎖、頁級鎖數據庫鎖定機制簡單來說，就是數據庫為了保證數據的一致性，而使各種共享資源在被并發訪問變得有序所設計的一種規則。MySQL數據庫由于其自身架構的特點，存在多種數據存...

番茄西紅柿 2021-11-23 09:51 評論0 收藏2637
單系統站內信設計概述

摘要：也可以在凌晨系統不是那么繁忙的時候操作。總結一下少量用戶設計簡單，但浪費空間，冗余高中量用戶設計較簡單，對表的操作壓力大大量用戶這不是增加幾個表能解決的問題基本功能點到點的消息傳送：用戶給用戶管理員給用戶點到面的消息傳送管理員給用戶群少量用戶（10-999）對于用戶非常少的情況，沒有必要深入的考慮數據庫的優化，采用簡單的表設計：如表message ...

Rainie 2019-08-16 10:54 評論0 收藏0