這兩天遇到客戶因為誤操作，將RAC環(huán)境下的所有共享存儲格式化掉了，客戶只有一個最近的RMAN的0級全備（無數(shù)據(jù)文件，無控制文件，無歸檔日志，無redo日志），需要幫忙恢復(fù)。將大致的恢復(fù)過程記錄一下。
0.恢復(fù)共享存儲是第一步，給存儲原廠打電話，原廠推是os的問題，讓給os打電話，結(jié)果只能初始化了，最后只能恢復(fù)到被識別的狀態(tài)，一切從頭開始。
1.因為集群軟件是裝在本地的，所以恢復(fù)rac的集群環(huán)境，只需要將ocr和vdisk重新配置一下，就可以了。可以執(zhí)行root.sh腳本來進(jìn)行重新的配置，如果中間報一個已經(jīng)被配置過的提示，那就先用dd清除ocr和vdisk的信息，并刪除相應(yīng)的目錄文件，如下:
rm -rf /usr/tmp/.oracle /var/tmp/.oracle /tmp/.oracle /etc/oracle/* /var/opt/oracle/*
rm -rf /etc/init.cssd /etc/init.crs* /etc/init.evmd /etc/init.d/init.cssd /etc/init.d/init.crs
rm -rf /etc/init.d/init.crsd /etc/init.d/init.evmd /etc/rc3.d/K96init.crs /etc/rc3.d/S96init.crs
rm -rf /etc/rc.d/rc2.d/K96init.crs /etc/rc.d/rc2.d/S96init.crs
2.恢復(fù)完集群環(huán)境之后，開始恢復(fù)數(shù)據(jù)庫。因為詢問到客戶有去年年底的一個RMAN的0級全備，以及控制文件的快照沒有放到共享存儲上，故可以采用重建控制文件+restore備份的方法來恢復(fù)。中途遇到很多問題，因為所有的日志備份均放到共享存儲下的，故這次恢復(fù)在recover的步驟時是沒有日志用來補(bǔ)充的。所以restore databse until 時間后，再recover，再alter database open resetlogs后，會報一個需要恢復(fù)數(shù)據(jù)文件的錯誤提示，操作的時候運氣不好，剛好遇到的是需要恢復(fù)datafile 1，再折騰了幾個小時候，終于發(fā)現(xiàn)按照正常的手段是行不通的.
3.因為沒有日志，無法使得數(shù)據(jù)庫達(dá)到一致性，所以只有采取修改隱藏參數(shù)的辦法來忽略數(shù)據(jù)庫的不一致，來強(qiáng)行打開數(shù)據(jù)庫.先將數(shù)據(jù)庫打到mount狀態(tài)，在做完restore，recover之后，將隱藏參數(shù)修改 alter system set "_allow_resetlogs_corruption"=true scope=spfile;再shutdown數(shù)據(jù)庫，啟動到mount狀態(tài)之后，alter database open resetlogs; resetlogs打開數(shù)據(jù)庫后，運氣仍然不是太好，又遇到了ORA-00600 2662號的錯誤.
4. 當(dāng)使用修改_allow_resetlogs_corruption ，再打開數(shù)據(jù)庫時遇到了ORA-00600 2662號的錯誤， 如果SCN相差不多，可以通過多次重起數(shù)據(jù)庫解決 ，但是這次遇到的SCN相差很大(通過查v$datafile和v$datafile_header的CHECKPOINT_CHANGE#來判斷)，這個時候只有再修改另外一個隱藏參數(shù) _minimum_giga_scn來解決問題._minimum_giga_scn的作用是推進(jìn)SCN號，該參數(shù)值的單位是billion，也就是說設(shè)置了該參數(shù)后，SCN號會變成XX* (1024*1024*1024) ，XX可以通過2662的幾個參數(shù)來確定. 2662后的參數(shù)[2662],[a],[b],[c],[d],[e]…[a] Current SCN WRAP，[b] Current SCN BASE，[c] dependent SCN WRAP，[d] dependent SCN BASE，[e] Where present this is the DBA where the dependent SCN came from.
5.當(dāng)修改了2個隱藏參數(shù)之后，數(shù)據(jù)庫終于能啟動了，但是alert日志還是會報一些600的錯誤，暫時忽略.用exp(expdp可能會報錯)將數(shù)據(jù)全部導(dǎo)出，重建新的實例，再用imp導(dǎo)入數(shù)據(jù)到新的庫中.exp的時候需要注意一個參數(shù)compress，這個參數(shù)可以降低HWM，使的imp的時候，時間相對盡量少一些.
posted @
2012-04-12 00:24 xrzp 閱讀(400) |
評論 (0) |
編輯 收藏
早上做個實驗,update數(shù)據(jù)的時候報錯ora-30036:無法按8擴(kuò)展段（在還原表空間‘undotbs_new’中）
1.查詢了一下undo表空間的使用,發(fā)現(xiàn)已經(jīng)超過了80%
SELECT a.tablespace_name as tablespace_name,
to_char(b.total/1024/1024,999999.99) as Total,
to_char((b.total-a.free)/1024/1024,999999.99) as Used,
to_char(a.free/1024/1024,999999.99) as Free,
to_char(round((total-free)/total,4)*100,999.99) as Used_Rate
FROM (SELECT tablespace_name, sum(bytes) free FROM DBA_FREE_SPACE GROUP BY tablespace_name) a,
(SELECT tablespace_name, sum(bytes) total FROM DBA_DATA_FILES GROUP BY tablespace_name ) b
WHERE a.tablespace_name=b.tablespace_name
AND a.tablespace_name='UNDOTBS_NEW'
ORDER BY a.tablespace_name;
2.將undo表空間大小重新加大點,解決問題~
alter database datafile 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\SUREDD\UNTOTBS_NEW_01.DBF' resize 2048M;
posted @
2011-11-07 10:30 xrzp 閱讀(18095) |
評論 (0) |
編輯 收藏v$sqltext:存儲的是完整的SQL,SQL被分割
v$sqlarea:存儲的SQL 和一些相關(guān)的信息,比如累計的執(zhí)行次數(shù),邏輯讀,物理讀等統(tǒng)計信息.v$sqlarea 忽略了執(zhí)行計劃等差異,只是在形式上sql文本看起來一樣.相當(dāng)于做了個聚合,是多個不同執(zhí)行計劃的sql的聚合和累計信息
v$sql:存儲的是具體的SQL 和執(zhí)行計劃相關(guān)信息,v$sqlarea 可以看做 v$sql 根據(jù) sqltext 等 做了 group by 之后的信息
v$sql_plan:代表了具體的sql的執(zhí)行計劃,通過下面3個字段做連接(與v$sql)
ADDRESS RAW(4),HASH_VALUE NUMBER,CHILD_NUMBER NUMBER
posted @
2011-11-07 00:00 xrzp 閱讀(360) |
評論 (0) |
編輯 收藏