Netbackup for sap 7.0學習之七：使用nbu進行sap系統的災難恢複測試

       隻要不是為了學習使用的sap系統，最擔心的就是系統癱瘓，而且這個還是不可能避免，隻是時間早晚的問題，作為系統維護人員，唯有做好備份以應對。

      隻是有些時候我們可能很尴尬，成天看着日志都說是成功備份，可真遇到事情的那天，卻發現所有的備份都是不可以用的。那個時候全世界都是你的仇人，可你最想的還是地上有個洞可以鑽進去。

      災難恢複的大緻步驟

    1.先安裝好新機器的作業系統

    2.安裝好資料庫和sap系統；

    3.配置好nbu接口backint、init.sap、init.utl,注意clint應該是老機器的名字

    4.開始恢複：前面的都是小事，主要是我們的存檔檔案有效是最重要的；

       4.1先恢複saparch存檔檔案夾

       4.2啟動資料庫到nomount狀态，以便恢複控制檔案

             sqlplus>startup nomount;

              brrestore -d util_file -b last -m 0

       4.3啟動資料到mount狀态，恢複資料檔案

              sqlplus>alter database mount;

              brrestore -d util_file -b last -m full

            這個執行時間看你資料庫大小。

       4.4成功後繼續執行

            recover database using backup controlfile until cancel;

       4.5打開資料庫

              sqlplus>alter database open resetlogs;

       到了這裡已經成功還原了資料庫，但是因為sap的運作機理，如果就這樣運作sap系統，還是會提示很多錯誤。主要原因兩個：

              a.opc機制

               b.temp表空間問題

       4.6建立sap的臨時表空間

                 sqlplus>select * from dba_temp_files

                 sqlplus>alter tablespace psaptemp add tempfile 'x:\oracle\sid\sapdata2\temp_1\psaptemp.data1‘ size 1024M reuse  AUTOEXTEND ON NEXT 20M;

       4.7檢查使用者狀态

                sqlplus>select username,account_status from dba_user;

               如果發現裡面的saprs3使用者是locked，就需要unlock它，如果unlock後有被lock，就需要修改一下他的密碼

                  sqlplus>alter user saprs3 identified by sap;

                  sqlplus>alter user saprs3 account unlock;

      4.8.如果日志導緻的錯誤還可以繼續操作，避免st22的時候出錯

               sqlplus>delete saprs3.snap或

               sqlplus>truncate table sapsr3.snap;

          重新啟動sap控制台，應該可以正常進入系統操作了。如果還存在問題需要檢查alert_<sid>.log和sap的work目錄下日志，找到症結所在。