亚洲中字慕日产2020,大陆极品少妇内射AAAAAA,无码av大香线蕉伊人久久,久久精品国产亚洲av麻豆网站

資訊專欄INFORMATION COLUMN

從一個案例談?wù)動谰帽砜臻g的臨時段問題

IT那活兒 / 695人閱讀
從一個案例談?wù)動谰帽砜臻g的臨時段問題
點擊上方“IT那活兒”公眾號，關(guān)注后了解更多內(nèi)容，不管IT什么活兒，干就完了?。?！

  
6月的某一天，我們一個工程師說有個表空間使用率一直在不斷增長，已經(jīng)使用了93%，業(yè)務(wù)反饋未有大數(shù)據(jù)批量變更，也無新業(yè)務(wù)上線，臨時想擴容，但無法擴容。于是這個事情轉(zhuǎn)交我來解決，下面我就此案例和大家分享。




事情解決過程




我們分析問題一般從頭開始， 先看看表空間使用率，XX表空間占了93.43%。
為了知道誰占用的空間比較多，對該XX表空間的對象進行分析，發(fā)現(xiàn)臨時段占用了3.2T，接近此表空間的50%。
為了臨時解決問題，我想先擴容，可發(fā)現(xiàn)該表空間是bigfile tablespace不能增加文件，且只能臨時把autoextend 改為on，但不是長久之計。
既然是臨時段，從理論上smon后臺進程應(yīng)該會對其進行自動回收，可為什么會出現(xiàn)問題呢?
先查查是什么類型沒釋放，發(fā)現(xiàn)有undo,drop等post。于是想會不會是無效索引或?qū)?shù)據(jù)未正常關(guān)閉引起呢? 反正就是順著這個思路去排查問題。
確實有not running 的導(dǎo)數(shù)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進程有等待，手動觸發(fā)smon進程后,有觸發(fā)成功,存在update scn_time時間撮語句,但是臨時段還是未釋放。
那到底是什么引起的， 觀察一下后臺日志alert，并同時上mos官網(wǎng)查詢解決辦法，出具了三個方案：
方案一：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 ();
方案三：重啟數(shù)據(jù)庫

關(guān)閉各個實例，并啟動數(shù)據(jù)庫。

對比三個方案和評估后，采取了第一個方案進行實施，但最后還是未解決。

到最后把整個思路重新整理了一下，并同時發(fā)現(xiàn)差一個環(huán)節(jié)，會不會是業(yè)務(wù)側(cè)的問題？
于是逐個排查歷史SQL，發(fā)現(xiàn)有需多etl程序在創(chuàng)建臨時表，雖然沒有在跑，但可能是hang住了，并看了sql的執(zhí)行計劃有些異常，bytes居然占了幾百G，于是和業(yè)務(wù)協(xié)商，將有問題的進程強制kill后，再手動觸smon進程，臨時段最后得到完全釋放，事情得到解決。




事情總結(jié)




解決問題的前提，需先熟悉整個問題環(huán)節(jié)和理論原理，下面就上面案例做一些提取。

1. 臨時段何時產(chǎn)生

  • 創(chuàng)建表（普通表或分區(qū)）；
  • 索引重建rebuild；
  • DROP TABLE；
  • Create snapshot。
2. 臨時段的類別

  • 臨時表空間的臨時段,永久表空間的臨時段，一般永久表空間的臨時段smon會自動清理，臨時表空間的臨時段可以通過重啟實例或重建臨時表空間解決。

3. 臨時段的處理方法
  • Smon觸發(fā)處理；
  • 手動處理，風(fēng)險極高，不推薦使用；
  • 分析業(yè)務(wù)邏輯及業(yè)務(wù)代碼，優(yōu)化后進行釋放。


本文作者：唐田壽（上海新炬王翦團隊）

本文來源：“IT那活兒”公眾號

文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請注明本文地址：http://www.ezyhdfw.cn/yun/129410.html

相關(guān)文章

  • 專訪58沈劍：除了架構(gòu)，我還想認真談?wù)?/em>管理

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

    masturbator 評論0 收藏0

  • 云計算“大機會時代”開啟，云計算巨頭們?nèi)绾尾灰獧C會主義

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

    Tecode 評論0 收藏0

  • 一文詳解MySQL的鎖機制

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

    番茄西紅柿 評論0 收藏2637

  • 單系統(tǒng)站內(nèi)信設(shè)計概述

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

    Rainie 評論0 收藏0

發(fā)表評論

0條評論

IT那活兒

男|高級講師

TA的文章

閱讀更多
最新活動
閱讀需要支付1元查看
<