undo資料表空間異常增大印發的空間不足問題,undo印發

來源:互聯網
上載者:User

undo資料表空間異常增大印發的空間不足問題,undo印發

今日同事發現他負責的一個資料庫伺服器出現了異常,癥狀為UNDOTBS資料表空間增大,導致磁碟空間不足,其請我協助解決這個問題。
系統是linux的,原則上來講這個問題其實很好解決,建立新的UNDOTBS資料表空間,然後讓系統預設使用這個資料表空間,等到切換完畢,刪除老的UNDOTBS資料表空間即可。
但是在實際解決的時候卻一波三折,現總結如下:
剛開始的時候給了他一個文檔,其內容是如何建立新的UNDOTBS資料表空間並刪除舊的,此文檔詳見http://blog.csdn.net/wxlbrxhb/article/details/14448777
但是他在使用之後等了一會發現現有的UNDOTBS資料表空間並未離線。手工執行了離線命令無效,估計此時應該還有資料在處理。

他有些著急,故此建議他重啟資料庫讓後讓再開起來這樣資料庫預設就直接使用新的UNDOTBS資料表空間了,舊的直接刪掉。
但是重啟後進入sqlplus開啟資料庫發現異常:

提示沒有許可權,有時候oracle沒有加入DBA使用者組也可能會有許可權不足的問題出現,所以讓他查了一下,結果發現oracle已經在DBA使用者組中了。

看來思路還是不對,不是這個問題。嘗試直接使用sqlplus / as sysdba登入,結果如下:
SQL> ORA-09945: Unable to initialize the audit trail file
Linux Error: 28: No space left on device
SQL>
./dbstart: Database instance "tnitsora" warm started.

/u01/app/oracle/product/10.2.0/db_1/bin/dbstart: Starting up database "tnitsora"
注意到一個提示ORA-09945: Unable to initialize the audit trail file
,無法初始化審計檔案。似乎有門,oracle在正常使用的時候會涉及到一個許可權的審計問題,一般來講會建立一個審計的檔案在/u01/app/oracle/admin/tnitsora/adump下,正巧今天有空間磁碟空間不足的現象,會不會是因為這個所以無法建立新的審計檔案從而導致了無法進入sysdba,並且無法正常啟動資料庫呢。
抱著這個想法進入了oracle目錄,進入了/u01/app/oracle/admin/tnitsora目錄下 ,使用du –sh查看各個目錄的佔用率,發現了問題,bdump居然有24G這也太大了。趕緊刪除了bdump下的大部分檔案,此時在使用sysdba登入發現已經可以正常登入了,進入之後開啟資料庫也正常,至此事情暫時告一段落。
Bdump這個目錄存放的是後台進程追蹤檔案目錄,一般來講這個檔案夾下的檔案是可以刪除的。

同事把應用都起來之後發現新的UNDOTBS資料表空間增大的很快,半個小時就已經用了8G了,UNDOTBS增大是正常的,但是這也增大的太快了,決定繼續分析處理。
先詢問了近期是否有對資料庫各類參數調整,同事表示沒有,但是修改過表結構等方面的東西。一般來講如果是undo_retention參數設定的時間過大有可能到導致UNDOTBS資料表空間中有大量未提交的資料從而快速增大,使用show parameter undo進行了查看未見異常。

詢問其是否有自動備份資料庫的指令碼或者程式在運行,其表示沒有。又查看了操作大量資料的job,發現和job也沒關係,job是晚上執行的。

繼續分析,想到如果一個表未做索引,那麼他在進行dml時會產生效率很低,也有可能導致UNDOTBS資料表空間異常增大。一般來說INSERT產生的UNDO最少,因為對於INSERT而言,Oracle 只要記錄其對應的一個“刪除“行的rowid即可。其次就是UPDATE 操作,對於該操作而言,只記錄修改的位元組;通常,在多數情況下,我們只修改行的一小部分,那麼,UNDO會將該部分記錄。相對上述兩種操作,DELETE操作會產生最多的UNDO,因為Oracle必須把整行的前影像都記錄到了undo段中。
請按著我這邊一個未出問題的資料庫的表結構對比了資料量較大的幾個表,發現索引都一樣未見異常,奇怪了問題出在哪裡?
在網上早來一段檢查復原段事務情況的語句
SELECT r.NAME 復原段名,s.sid SID,s.serial# Serial,
       s.username 使用者名稱,s.machine 機器名,
       t.start_time 開始時間,t.status 狀態,
       t.used_ublk 撤消塊,USED_UREC 撤消記錄,
       t.cr_get 一致性取,t.cr_change 一致性變化,
       t.log_io "邏輯I/O",t.phy_io "物理I/O",
       t.noundo NoUndo,g.extents Extents,substr(s.program, 1, 50) 操作程式
  FROM v$session s, v$transaction t, v$rollname r,v$rollstat g
 WHERE t.addr = s.taddr
   AND t.xidusn = r.usn
   AND r.usn = g.usn
 ORDER BY t.used_ublk desc
發現有個進程一直在使用回退段,且已經執行了2個多小時了,狀態還是active

查看到進程的名字為FAKE_xxx_ xxx _ xxx.exe,估計問題就出在他身上。將這個程式關閉之後再次檢查UNDOTBS資料表空間,此時UNDOTBS資料表空間的增大情況已經減小,資料庫回複正常。

相關文章

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.