Rumah > Artikel > pangkalan data > 一次误操作引起的Oracle数据库大恢复
事情起由是在Oracle 10g手动建库脚本中看到dbms_backup_restore.zerodbid(0)过程,其中作用是修改数据库的dbid。于是想通过该
事情起由是在Oracle 10g手动建库脚本中看到dbms_backup_restore.zerodbid(0)过程,其中作用是修改数据库的dbid。于是想通过该存储直接在sqlplus中执行修改dbid。
修改之前记录其dbid
引用
SQL> select dbid from v$database;
DBID
----------
1488207495
修改dbid
引用
SQL> exec dbms_backup_restore.zerodbid(0);
PL/SQL procedure successfully completed.
貌似执行成功了,但随后alert日志显示ckpt进程将数据实例终止
引用
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
再次启动数据库报错
引用
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数据文件头
引用
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
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
当然第一反应是重建控制文件,,看看能不能恢复成功
引用
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