時(shí)間:2015/6/28來源:IT貓撲網(wǎng)作者:網(wǎng)管聯(lián)盟我要評(píng)論(0)
事情起由是在oracle 10g手動(dòng)建庫腳本中看到dbms_backup_restore.zerodbid(0)過程,其中作用是修改數(shù)據(jù)庫的dbid。于是想通過該存儲(chǔ)直接在sqlplus中執(zhí)行修改dbid。
修改之前記錄其dbid
引用
SQL> select dbid from v$database;
DBID
----------
1488207495
修改dbid
引用
SQL> exec dbms_backup_restore.zerodbid(0);
PL/SQL procedure successfully completed.
貌似執(zhí)行成功了,但隨后alert日志顯示ckpt進(jìn)程將數(shù)據(jù)實(shí)例終止
引用
Tue Mar 9 01:43:22 2010
CKPT: terminating instance due to error 1242
Instance terminated by CKPT, pid = 16653
Tue Mar 9 01:43:53 2010
再次啟動(dòng)數(shù)據(jù)庫報(bào)錯(cuò)
引用
Tue Mar 9 01:56:09 2010
Errors in file /ora10g/app/admin/ldbra/udump/ldbra_ora_12275.trc:
ORA-01221: data file 1 is not the same file to a background process
ORA-1221 signalled during: ALTER DATABASE OPEN...
dump Oracle數(shù)據(jù)文件頭
引用
SQL> ALTER SESSION SET EVENTS 'immediate trace name file_hdrs level 3';
通過跟蹤文件可以看到dbid以被重置為0
引用
V10 STYLE FILE HEADER:
Compatibility Vsn = 169870080=0xa200300
Db ID=0=0x0, Db Name='LDBRA'
Activation ID=0=0x0
Control Seq=8122=0x1fba, File size=65280=0xff00
File Number=1, Blksiz=8192, File Type=3 DATA
還有一種途徑是通過bbed工具觀察
引用
struct kcvfhhdr, 76 bytes @20
ub4 kccfhswv @20 0x00000000
ub4 kccfhcvn @24 0x0a200300
ub4 kccfhdbi @28 0x00000000
當(dāng)然第一反應(yīng)是重建控制文件,看看能不能恢復(fù)成功
引用
SQL> alter database backup controlfile to trace;
Database altered.
STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE "LDBRA" RESETLOGS ARCHIVELOG
MAXLOGFILES 16
MAXLOGMEMBERS 3
MAXDATAFILES 100
MAXINSTANCES 8
MAXLOGHISTORY 292
LOGFILE
GROUP 1 '/ora10g/app/oradata/ldbra/redo01.log' SIZE 50M,
GROUP 2 '/ora10g/app/oradata/ldbra/redo02.log' SIZE 50M,
GROUP 3 '/ora10g/app/oradata/ldbra/redo03.log' SIZE 50M
-- STANDBY LOGFILE
DATAFILE
'/ora10g/app/oradata/ldbra/system01.dbf',
'/ora10g/app/oradata/ldbra/undotbs01.dbf',
'/ora10g/app/oradata/ldbra/sysaux01.dbf',
'/ora10g/app/oradata/ldbra/users01.dbf',
'/ora10g/app/oradata/ldbra/example01.dbf',
'/ora10g/app/product/10.2.0/db_1/dbs/company.dbf',
'/ora10g/app/product/10.2.0/db_1/dbs/streams.dbf'
CHARACTER SET ZHS16GBK
;
#p#副標(biāo)題#e#
郁悶的是重建控制文件不成功:
引用
CREATE CONTROLFILE REUSE DATABASE "LDBRA" RESETLOGS NOARCHIVELOG
*
ERROR at line 1:
ORA-01503: CREATE CONTROLFILE failed
ORA-01227: log is inconsistent with other logs
想到還有另外一種語法重建控制文件(重建控制文件之前,備份controlfile和online redolog):
引用
Create controlfile reuse set database "LDBRA"
MAXINSTANCES 8
MAXLOGHISTORY 1
MAXLOGFILES 16
MAXLOGMEMBERS 3
MAXDATAFILES 100
Datafile
'/ora10g/app/oradata/ldbra/system01.dbf',
'/ora10g/app/oradata/ldbra/undotbs01.dbf',
'/ora10g/app/oradata/ldbra/sysaux01.dbf',
'/ora10g/app/oradata/ldbra/users01.dbf',
'/ora10g/app/oradata/ldbra/example01.dbf',
'/ora10g/app/product/10.2.0/db_1/dbs/ company.dbf',
'/ora10g/app/product/10.2.0/db_1/dbs/streams.dbf'
LOGFILE GROUP 1 ('/ora10g/app/oradata/ldbra/redo01.log') SIZE 51200K,
GROUP 2 ('/ora10g/app/oradata/ldbra/redo02.log') SIZE 51200K,
GROUP 3 ('/ora10g/app/oradata/ldbra/redo03.log') SIZE 51200K RESETLOGS;
似乎重建成功了!但是進(jìn)行recover的時(shí)候報(bào)錯(cuò)了!
引用
SQL> RECOVER DATABASE USING BACKUP CONTROLFILE;
ORA-00283: recovery session canceled due to errors
ORA-00600: internal error code, arguments: [kcvhvdf_1], [], [], [], [], [], [],
[]
可以看到控制文件在重建的過程中進(jìn)行了dbid重置
引用
SQL> select dbid from v$database;
DBID
----------
1498845164
問題到這里似乎失去了頭緒,呵呵,拷回之前備份的控制文件替換剛建的控制文件。因?yàn)槲也捎玫氖莚esetlog選項(xiàng)創(chuàng)建控制文件,從理論上來講,應(yīng)該是會(huì)重置redolog的,即重新創(chuàng)建redolog。但是目前采用此選項(xiàng)確報(bào)ORA-01227錯(cuò)誤。不可思議!后來一想可能是跟數(shù)據(jù)文件中的dbid為0有關(guān)。于是采用終極修復(fù)方法,bbed!首先將所有數(shù)據(jù)文件的dbid用bbed工具重置為1488207495,其次將fuzzy標(biāo)記打?yàn)?x2000(因?yàn)閿?shù)據(jù)庫被ckpt進(jìn)程異常終止,將標(biāo)記打?yàn)?x2000表示數(shù)據(jù)庫是shutdown immediate關(guān)閉),采用上述方法之后控制文件成功創(chuàng)建!
引用
SQL> STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE "LDBRA" RESETLOGS ARCHIVELOG
MAXLOGFILES 16
MAXLOGMEMBERS 3
MAXDATAFILES 100
MAXINSTANCES 8
MAXLOGHISTORY 292
LOGFILE
ORACLE instance started.
Total System Global Area 1073741824 bytes
Fixed Size 1271616 bytes
Variable Size 461375680 bytes
Database Buffers 608174080 bytes
Redo Buffers 2920448 bytes
GROUP 1 '/ora10g/app/oradata/ldbra/redo01.log' SIZE 50M,
GROUP 2 '/ora10g/app/oradata/ldbra/redo02.log' SIZE 50M,
GROUP 3 '/ora10g/app/oradata/ldbra/redo03.log' SIZE 50M
-- STANDBY LOGFILE
DATAFILE
'/ora10g/app/oradata/ldbra/system01.dbf',
'/ora10g/app/oradata/ldbra/undotbs01.dbf',
'/ora10g/app/oradata/ldbra/sysaux01.dbf',
'/ora10g/app/oradata/ldbra/users01.dbf',
'/ora10g/app/oradata/ldbra/example01.dbf',
'/ora10g/app/product/10.2.0/db_1/dbs/company.dbf',
'/ora10g/app/product/10.2.0/db_1/dbs/streams.dbf'
CHARACTER SET ZHS16GBK
21 ;
Control file created.
嘗試打開數(shù)據(jù)庫
SQL> alter database open RESETLOGS;
出現(xiàn)數(shù)據(jù)庫掛起狀態(tài),后臺(tái)alert日志顯示[2662]錯(cuò)誤,呵呵,看到這個(gè)錯(cuò)誤,希望就來了!
引用
SMON: enabling cache recovery
Tue Mar 9 03:11:38 2010
Errors in file /ora10g/app/admin/ldbra/udump/ldbra_ora_13676.trc:
ORA-00600: internal error code, arguments: [2662], [2268], [3799096903], [2268], [3799098345], [8388617], [], []
關(guān)鍵詞標(biāo)簽:Oracle數(shù)據(jù)庫恢復(fù)
相關(guān)閱讀
熱門文章 Oracle中使用alter table來增加,刪除,修改列oracle中使用SQL語句修改字段類型-oracle修使用低權(quán)限Oracle數(shù)據(jù)庫賬戶得到管理員權(quán)限Oracle對(duì)user的訪問控制
人氣排行 ORACLE SQL 判斷字符串是否為數(shù)字的語句Oracle中使用alter table來增加,刪除,修改列的語法ORACLE和SQL語法區(qū)別歸納(1)oracle grant 授權(quán)語句如何加速Oracle大批量數(shù)據(jù)處理Oracle刪除表的幾種方法ORACLE修改IP地址后如何能夠使用Oracle 10g創(chuàng)建表空間和用戶并指定權(quán)限