rman備份發生的一點事情（sysaux表空間丟失）

今天突發奇想，想玩一下rman這個命令，本身虛擬機很久都沒有備份了，因此就來個全備，果不其然給了我一個報錯。

RMAN> backup 

Starting backup at 20-OCT-16
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=134 device type=DISK
RMAN-06169: could not read file header for datafile 2 error reason 1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of backup command at 10/20/2016 05:19:19
RMAN-06056: could not access datafile 2

而後進入數據庫開始查詢爲何不能備份

SQL> select file#,name from v$datafile;

     FILE#
----------
NAME
--------------------------------------------------------------------------------
         1
/u01/oracle/product/oradata/wrc/system01.dbf

         2
/u01/oracle/product/11.2.0/db_1/dbs/MISSING00002

         3
/u01/oracle/product/oradata/wrc/undotbs01.dbf


     FILE#
----------
NAME
--------------------------------------------------------------------------------
         4
/u01/oracle/product/oradata/wrc/users01.dbf

         5
/u01/oracle/product/11.2.0/db_1/dbs/MISSING00005

         6
/u01/oracle/product/11.2.0/db_1/dbs/MISSING00006


6 rows selected.
SQL> select TS#,name from v$tablespace;

       TS# NAME
---------- ------------------------------
         0 SYSTEM
         2 UNDOTBS1
         4 USERS
         1 SYSAUX
         3 TEMP
         6 EXAMPLE
         7 RMAN

發現這兩個命令不能告訴我到底哪一個表空間丟失了，後來上網查資料

SQL>  select a.file#,a.name,b.name from v$datafile a,v$tablespace b where a.ts#=b.ts#
  2  ;

     FILE# NAME                           NAME
---------- ------------------------------ ------------------------------
         1 /u01/oracle/product/oradata/wr SYSTEM
           c/system01.dbf

         2 /u01/oracle/product/11.2.0/db_ SYSAUX
           1/dbs/MISSING00002

         3 /u01/oracle/product/oradata/wr UNDOTBS1
           c/undotbs01.dbf

         4 /u01/oracle/product/oradata/wr USERS
           c/users01.dbf

     FILE# NAME                           NAME
---------- ------------------------------ ------------------------------

         5 /u01/oracle/product/11.2.0/db_ EXAMPLE
           1/dbs/MISSING00005

         6 /u01/oracle/product/11.2.0/db_ RMAN
           1/dbs/MISSING00006


6 rows selected.

一查詢丟失三個文件，而後就開始想辦法解決

rman這個表空間是最好刪的，可是不要忘記刪的時候要

 including contents and datafiles

而後後來開始刪除example這個表空間，這個顯示有index以及關係因此不能刪除，當時找了下確實有對象，刪除全部對象再刪除這個表空間應該也是能夠的，最後到了sysaux這個表空間，sysaux這個表空間雖然是系統表空間，system表空間的輔助表空間，例如存放一些報告信息等，基本不會對性能有啥影像。

第一種方式

SQL> drop tablespace sysaux including contents and datafiles;
drop tablespace sysaux including contents and datafiles
*
ERROR at line 1:
ORA-13501: Cannot drop SYSAUX tablespace

第二種方式

SQL> alter database datafile 2 offline drop
  2  ;

Database altered.

SQL> select a.file#,a.name,b.name from v$datafile a,v$tablespace b where a.ts#=b.ts#;

     FILE#
----------
NAME
--------------------------------------------------------------------------------
NAME
------------------------------
         1
/u01/oracle/product/oradata/orcl/system01.dbf
SYSTEM

         2
/u01/oracle/product/oradata/orcl/sysaux01.dbf
SYSAUX

     FILE#
----------
NAME
--------------------------------------------------------------------------------
NAME
------------------------------

         3
/u01/oracle/product/oradata/orcl/undotbs01.dbf
UNDOTBS1

         4
/u01/oracle/product/oradata/orcl/users01.dbf

     FILE#
----------
NAME
--------------------------------------------------------------------------------
NAME
------------------------------
USERS

         5
/u01/oracle/product/oradata/orcl/example01.dbf
EXAMPLE

能夠看出來明顯都是沒有刪掉的，這個時候開始思考這個sysaux是否是寫入控制文件，因此你無論怎麼刪都是刪不掉，後來就開始想經過初始化控制文件，看能不能成功。

先建立腳本

SELECT    d.VALUE
       || '/'
       || LOWER (RTRIM (i.INSTANCE, CHR (0)))
       || '_ora_'
       || p.spid
       || '.trc' trace_file_name
  FROM (SELECT p.spid
          FROM v$mystat m, v$session s, v$process p
         WHERE m.statistic# = 1 AND s.SID = m.SID AND p.addr = s.paddr) p,
       (SELECT t.INSTANCE
          FROM v$thread t, v$parameter v
         WHERE v.NAME = 'thread'
           AND (v.VALUE = 0 OR t.thread# = TO_NUMBER (v.VALUE))) i,
       (SELECT VALUE
          FROM v$parameter
         WHERE NAME = 'user_dump_dest') d
/

在Linux下執行該腳本

SQL> @gettrcname
TRACE_FILE_NAME
---------------------------------------------------------------------------------------------------
/opt/oracle/admin/eygle/udump/eygle_ora_8415.trc

alter database backup controlfile to trace;

經過看這個eygle_ora_8415.trc文件，編輯從新建立控制文件

STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE "ORCL" RESETLOGS  noARCHIVELOG
    MAXLOGFILES 5
    MAXLOGMEMBERS 3
    MAXDATAFILES 100
    MAXINSTANCES 1
    MAXLOGHISTORY 1168
LOGFILE
  GROUP 1 '/u01/oracle/product/oradata/wrc/redo01.log'  SIZE 50M BLOCKSIZE 512,
  GROUP 2 '/u01/oracle/product/oradata/wrc/redo02.log'  SIZE 50M BLOCKSIZE 512,
  GROUP 3 '/u01/oracle/product/oradata/wrc/redo03.log'  SIZE 50M BLOCKSIZE 512,
  GROUP 4 '/u01/oracle/product/oradata/wrc/redo04.rdo'  SIZE 50M BLOCKSIZE 512
-- STANDBY LOGFILE
DATAFILE
  '/u01/oracle/product/oradata/wrc/system01.dbf',
  '/u01/oracle/product/11.2.0/db_1/dbs/sysaux02.dbf',
  '/u01/oracle/product/oradata/wrc/undotbs01.dbf',
  '/u01/oracle/product/oradata/wrc/users01.dbf',
  '/u01/oracle/product/11.2.0/db_1/dbs/sysaux03.dbf',
  '/u01/oracle/product/11.2.0/db_1/dbs/sysaux04.dbf'
CHARACTER SET ZHS16GBK
;

進入sqlplus跑這個腳本，而後開始進行數據庫的恢復，忽然發現又來個錯誤

SQL> RECOVER DATABASE
ORA-00283: recovery session canceled due to errors
ORA-01610: recovery using the BACKUP CONTROLFILE option must be done


SQL> alter database archivelog;

Database altered.

1. recover database using backup controlfile

若是丟失當前控制文件，用冷備份的控制文件恢復的時候，用來告訴oracle，不要以controlfile中的scn做爲恢復的終點；

2. recover database until cancel

若是丟失current/active redo的時候，手動指定終點。

3. recover database using backup controlfile until cancel;

若是丟失當前controlfile而且current/active redo都丟失，會先去自動應用歸檔日誌,能夠實現最大的恢復；

4. recover database until cancel using backup controlfile;

結果以下：

若是控制文件丟失，restore備份的控制文件後，則必須使用using backup controlfile選項。而until cancel則是不徹底恢復，即current/active redo丟失，或者從restore數據庫後某個歸檔文件缺失，則終止。

結論：

一、適用於restore舊的控制文件，且歸檔日誌和cuurrent/active redo都沒有丟失狀況。若是一切歸檔日誌和在線日誌無缺，能夠不丟失數據。相似於recover database

二、當前控制文件未丟失（不須要restore舊的控制文件），此時有歸檔日誌或者current/active log有丟失狀況下，則終止。最大可能恢復數據

三、4:我在oracle 10.2.0.4環境下測試效果是相同的，即適用於restore舊的控制文件，在恢復到控制文件備份那刻後，系統會提示應用控制文件備份後的歸檔日誌，若是沒有則中止。也是最大可能的恢復數據。

SQL> alter database archivelog;

Database altered.

SQL>  recover database using backup controlfile until cancel;
ORA-00279: change 1995899 generated at 10/20/2016 07:46:55 needed for thread 1
ORA-00289: suggestion :
/u01/oracle/product/flash_recovery_area/ORCL/archivelog/2016_10_20/o1_mf_1_47_%u
_.arc
ORA-00280: change 1995899 for thread 1 is in sequence #47


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/u01/oracle/product/oradata/wrc/redo04.rdo
ORA-00310: archived log contains sequence 45; sequence 47 required
ORA-00334: archived log: '/u01/oracle/product/oradata/wrc/redo04.rdo'


SQL> /u01/oracle/product/oradata/wrc/redo04.rdo
SP2-0734: unknown command beginning "/u01/oracl..." - rest of line ignored.
SQL>  recover database using backup controlfile until cancel;
ORA-00279: change 1995899 generated at 10/20/2016 07:46:55 needed for thread 1
ORA-00289: suggestion :
/u01/oracle/product/flash_recovery_area/ORCL/archivelog/2016_10_20/o1_mf_1_47_%u
_.arc
ORA-00280: change 1995899 for thread 1 is in sequence #47


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/u01/oracle/product/oradata/wrc/redo03.log
Log applied.
Media recovery complete.

發現control file裏面找不到sequence#47，而後只能一個一個redo日誌的位置來試，最後成功了

SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open


SQL> alter database open resetlogs;

Database altered.

最後開啓數據庫，須要制定是resetlogs仍是noresetlogs模式下，可是發現仍是不行，sysaux仍是依舊存在，說明sysaux丟失是不能挽救的，須要從新創庫。