浏览 3596 次
|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-10-18
1、系统检查点（记录在控制文件中）
SQL> select checkpoint_change# from v$database; CHECKPOINT_CHANGE# ------------------ 539625 2、数据文件检查点（记录在控制文件中） SQL> select file#,checkpoint_change#,last_change# from v$datafile; FILE# CHECKPOINT_CHANGE# LAST_CHANGE# ---------- ------------------ ------------ 1 539625 2 539625 3 539625 4 539625 5 539625 3、数据文件头检查点（记录在数据文件中） SQL> select file#,checkpoint_change# from v$datafile_header; FILE# CHECKPOINT_CHANGE# ---------- ------------------ 1 539625 2 539625 3 539625 4 539625 5 539625 以上三个checkpoint_change#要一致，数据库才能正常打开。否则会需要进行一步的处理。正常关库时，会生成新的检查点，写入上述三个checkpoint_change#，同时数据文件中的last_change#也会记录下该检查点，也就是说三个checkpoint_change#与last_change#记录着同一个值。 通过以下SQL可以证明 SQL> shutdown immediate Database closed. Database dismounted. ORACLE instance shut down. SQL> startup mount ORACLE instance started. Total System Global Area 167772160 bytes Fixed Size 778212 bytes Variable Size 66068508 bytes Database Buffers 100663296 bytes Redo Buffers 262144 bytes Database mounted. SQL> select file#,checkpoint_change#,last_change# from v$datafile; FILE# CHECKPOINT_CHANGE# LAST_CHANGE# ---------- ------------------ ------------ 1 540270 540270 2 540270 540270 3 540270 540270 4 540270 540270 5 540270 540270 SQL> select checkpoint_change# from v$database; CHECKPOINT_CHANGE# ------------------ 540270 SQL> select file#,checkpoint_change# from v$datafile_header; FILE# CHECKPOINT_CHANGE# ---------- ------------------ 1 540270 2 540270 3 540270 4 540270 5 540270 数据库成功打开后，数据文件中的last_change#会被清空。正常关库时，再重新下最后的检查点。shutdown abort关库，这个值是空的（感兴趣可自行验证），此时数据库需要进行实例恢复（不需要用户干预），恢复后数据库才正常打开。 checkpoint_change#、last_change#实际上全部来自于SCN，可以通过下面的语句验证： SQL> select dbms_flashback.get_system_change_number from dual; GET_SYSTEM_CHANGE_NUMBER ------------------------ 540741 使用查询系统SCN号的函数，可以发现checkpoint_change#与之是接近的。SCN有很多触发的条件，可能不会特别接近。 问题1：数据文件损坏的恢复 此时控制文件中记录的checkpoint_change#比数据文件头中记录的要大，数据库需要介质或者实例恢复。 SQL> startup ORACLE instance started. Total System Global Area 167772160 bytes Fixed Size 778212 bytes Variable Size 61874204 bytes Database Buffers 104857600 bytes Redo Buffers 262144 bytes Database mounted. ORA-01113: file 1 needs media recovery ORA-01110: data file 1: '/u02/oradata/orcl/system01.dbf' 恢复一下，数据库就可以打开了。 SQL> recover database; ORA-00279: change 539624 generated at 10/18/2011 08:27:31 needed for thread 1 ORA-00289: suggestion : /u02/oradata/orcl/arc/1_5_764840495.dbf ORA-00280: change 539624 for thread 1 is in sequence #5 Specify log: {<RET>=suggested | filename | AUTO | CANCEL} auto ORA-00279: change 540768 generated at 10/18/2011 12:17:11 needed for thread 1 ORA-00289: suggestion : /u02/oradata/orcl/arc/1_6_764840495.dbf ORA-00280: change 540768 for thread 1 is in sequence #6 ORA-00278: log file '/u02/oradata/orcl/arc/1_5_764840495.dbf' no longer needed for this recovery Log applied. Media recovery complete. SQL> alter database open; Database altered. 问题2：控制文件损坏的恢复 如果控制文件损坏，使用备份的控制文件是无法打开数据库的， SQL> startup ORACLE instance started. Total System Global Area 167772160 bytes Fixed Size 778212 bytes Variable Size 61874204 bytes Database Buffers 104857600 bytes Redo Buffers 262144 bytes Database mounted. ORA-01122: database file 1 failed verification check ORA-01110: data file 1: '/u02/oradata/orcl/system01.dbf' ORA-01207: file is more recent than controlfile - old controlfile 会提示数据文件与控制文件新，实际上就是控制文件中记录的checkpoint_change#比数据文件头中的checkpoint_change#要小，这种情况是不能打开数据库的。但数据可以启动到mount状态，此时可以用命令 alter database backup controlfile to trace; 生成一个控制文件的脚本，在udump目录中。使用该脚本可以重建控制文件，进行实例恢复后或打开数据库。 如果没有备份的控制文件，数据库只能打开的nomount状态，不能获取重建控制文件的脚本，如果也没有备份过重建控制文件脚本，那就悲剧了。如果数据库不太复杂，可以手写一个。 问题3：数据文件、控制文件全部损坏（当然都有备份，日志是好的） 恢复数据文件、控制文件后，数据库仍然是无法打开的。 SQL> startup ORACLE instance started. Total System Global Area 167772160 bytes Fixed Size 778212 bytes Variable Size 61874204 bytes Database Buffers 104857600 bytes Redo Buffers 262144 bytes Database mounted. ORA-00314: log 1 of thread 1, expected sequence# doesn't match ORA-00312: online log 1 thread 1: '/u02/oradata/orcl/redo01.log' 提示的意思也就是日志中的检查点比较控制文件中记录的大。 SQL> select checkpoint_change# from v$datafile; CHECKPOINT_CHANGE# ------------------ 539624 539624 539624 539624 539624 SQL> select checkpoint_change# from v$datafile_header; CHECKPOINT_CHANGE# ------------------ 539624 539624 539624 539624 539624 SQL> select checkpoint_change# from v$database; CHECKPOINT_CHANGE# ------------------ 539624 SQL> select * from v$log; GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM ---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- --------- 1 1 5 10485760 1 NO CURRENT 539571 18-OCT-11 2 1 4 10485760 1 YES INACTIVE 539116 18-OCT-11 3 1 3 10485760 1 YES INACTIVE 537456 18-OCT-11 此时可以使用下面的命令恢复数据库 SQL> recover database using backup controlfile; 恢复成功后，v$database中记录的checkpoint_change#并未发生变化。 SQL> select checkpoint_change# from v$datafile; CHECKPOINT_CHANGE# ------------------ 602574 602574 602574 602574 602574 SQL> select checkpoint_change# from v$datafile_header; CHECKPOINT_CHANGE# ------------------ 602574 602574 602574 602574 602574 SQL> select checkpoint_change# from v$database; CHECKPOINT_CHANGE# ------------------ 539624 因为不致，所以数据库仍然打不开： 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; alter database open resetlogs * ERROR at line 1: ORA-01113: file 1 needs media recovery ORA-01110: data file 1: '/u02/oradata/orcl/system01.dbf' 此时的情况类似于问题2，解决办法也相同。shutdown abort,startup nomount,重建控制文件,recover database,alter database open; 声明：ITeye文章版权属于作者，受法律保护。没有作者书面许可不得转载。
推荐链接
|
| 返回顶楼 | |
