ORA-01552: 非系統表空間不能使用系統回退段-問題解決

問題介紹

oracle rac環境下面，一個實例使用的undo表空間出現問題，經現場實施人員調整後，實例可以啓動，可是不能提供寫數據服務，只能提供查詢服務。

實例對應表空間的管理方式已經改爲manual，寫數據（建表或者插入數據）的時候報出ORA-01552錯誤。

問題分析

解決問題以後看這個問題，思路應該仍是比較清晰。oracle的undo在ddl和dml操做的時候都會用到。因爲實例對應的undo是manual方法，不能實現空間的自動擴展，當undo空間滿了以後，不能再分配更多的空間。問題就這麼出來了。

問題解決

這個問題的解決大概有兩種方式，第一經過rman進行恢復，問題的根源我猜想是undo的數據文件損壞，應該是能夠經過rman的方式進行恢復，限於本人的學識，對rman不熟，也沒時間去折騰，因此我沒用這種方式。

第二經過新建undo表空間，修改實例對應的默認undo空間。這個方式應該是比較容易操做的。也是我選用的。下面介紹當時的實施過程。

一、新建undo表空間，注意undo表空間可以自動擴展。

二、修改實例對應的undo表空間。

    如今回過頭來看這個問題估計只要一條命令就能夠了「alter system set undo_tablespace=UTBS1 scope=spfile sid='rac1';」,因爲當時沒有制定sid，執行這條命令後，雖然命令執行成功，可是實例重啓以後，實例的undo表空間仍是原來的。個人分析是，雖然「alter system set undo_tablespace=UTBS1 scope=spfile;」這條命令執行成功了，spfile中確實多了一條記錄*.undo_tablespace=UTBS1,可是spfile中還存在原來的一條記錄rac1.undo_tablespace=UTBS，這種狀況下，實例啓動過的時候是rac1.undo_tablespace=UTBS起做用了，因此實例的undo表空間沒修改爲功。

    當時沒那個覺悟，我選擇的作法是修改pfile中rac1.undo_tablespace的值來實現修改的目的。

    （1）經過spfile生成pfile（注意rac中實例共用一個spfile文件，且都存在asm中）；

    （2）修改pfile的rac1.undo_tablespace值爲新建的undo表空間名；

    （3）經過pfile文件啓動實例。

    （4）經過pfile生成spfile文件。

    （5）利用spfile文件啓動數據庫實例

    （6）修改undo表空間的管理方式。

須要注意的問題：

    （1）生成spfile有兩種方式，經過pfile和memory，memory的方式我試過，這種方式生成的spfile只能啓動一個rac實例，其餘實例不能啓動，我分析的緣由，memory生成的spfile是單個實例的參數文件，兩個或以上的實例使用同一份參數配置的時候，就會出問題，好比說instance_number busy的問題，參數不一致ORA-01105 ORA-01606的問題。這裏個人作法是經過pfile文件直接生成spfile，注意spfile須要制定路徑，並且是asm下面的路徑。

    （2）oracle的startup命令讀參數文件（spfiletrain1.ora，inittrain1.ora）的順序問題。oracle在用startup啓動的時候先找spfileSID.ora文件，不存在該文件的狀況下找initSID.ora文件。因爲我在生成spfile的時候，最開始沒有指定spfile的路徑，這樣在默認的路徑下面就存在了spfiletrain1.ora這個文件，這就形成我啓動實例的一個困惑，從新制定spfile的路徑重建後，重啓實例後，查看spfile的參數都不是asm中的文件。以後移除本地目錄的spfiletrain1.ora文件，再重啓實例，就正常了。

用到的命令

因爲生成環境，考出當時的sql語句很麻煩，這裏只能給出圖片了。