恢复控制文件后如何避免resetlogs打开数据库?

[[194050]]

恢复控制文件后,数据库使用resetlogs方式打开,在线日志的序列被重置。

  1. SYS@practice >select group#,sequence#,archived,status,first_change#,next_change# from v$log; 
  2.  
  3.    GROUP#  SEQUENCE# ARC STATUS           FIRST_CHANGE# NEXT_CHANGE# 
  4. ---------- ---------- --- ---------------- ------------- ------------ 
  5.         1          1 NO  CURRENT                1014415   2.8147E+14 
  6.         2          0 YES UNUSED                       0            0 
  7.         3          0 YES UNUSED                       0            0 

 如果没有被resetlog截断的话当前日志的序列号应该是7,8,9

  1. SYS@practice >select recid,sequence#,first_change#,next_change# from v$log_history; 
  2.  
  3.     RECID  SEQUENCE# FIRST_CHANGE# NEXT_CHANGE# 
  4. ---------- ---------- ------------- ------------ 
  5.         1          1        925702       955284 
  6.         2          2        955284       955847 
  7.         3          3        955847       971151 
  8.         4          4        971151       987800 
  9.         5          5        987800       997957 
  10.         6          6        997957      1010981 
  11.         7          1       1010981      1013463 
  12.         8          2       1013463      1013471 
  13.         9          3       1013471      1014415 

如果恢复完控制文件,不使用resetlogs是打不开数据库的。

我们可以采取手工创建控制文件的方法打开数据库,保持联机日志的sequence#连续。下面的实验来演示具体操作过程。

在实验之前先手工切换3次日志,使得在线日志的序列号产生变化。在恢复结束后作为参考。

  1. SYS@practice >alter system archive log current
  2.  
  3. SYS@practice >alter system archive log current
  4.  
  5. SYS@practice >alter system archive log current

切换后当前连接日志状态如下

  1. SYS@practice >select group#,sequence#,archived,status,first_change#,next_change# from v$log; 
  2.  
  3.    GROUP#  SEQUENCE# ARC STATUS           FIRST_CHANGE# NEXT_CHANGE# 
  4. ---------- ---------- --- ---------------- ------------- ------------ 
  5.         1          4 NO  CURRENT                1030130   2.8147E+14 
  6.         2          2 YES INACTIVE               1030109      1030117 
  7.         3          3 YES ACTIVE                 1030117      1030130 

 1、恢复控制文件

  1. RMAN> startup force nomount; 
  2.  
  3. Oracle instance started 
  4.  
  5. Total System Global Area     580395008 bytes 
  6.  
  7. Fixed Size                     2255392 bytes 
  8. Variable Size                402654688 bytes 
  9. Database Buffers             171966464 bytes 
  10. Redo Buffers                   3518464 bytes 
  11.  
  12. RMAN> restore controlfile from autobackup; 
  13.  
  14. Starting restore at 06-OCT-14 
  15. using target database control file instead of recovery catalog 
  16. allocated channel: ORA_DISK_1 
  17. channel ORA_DISK_1: SID=19 device type=DISK 
  18.  
  19. recovery area destination: /u01/fast_recovery_area 
  20. database name (or database unique name) used for search: PRACTICE 
  21. channel ORA_DISK_1: AUTOBACKUP /u01/fast_recovery_area/PRACTICE/autobackup/2014_10_06/o1_mf_s_860251717_b35s05gm_.bkp found in the recovery area 
  22. channel ORA_DISK_1: looking for AUTOBACKUP on day: 20141006 
  23. channel ORA_DISK_1: restoring control file from AUTOBACKUP /u01/fast_recovery_area/PRACTICE/autobackup/2014_10_06/o1_mf_s_860251717_b35s05gm_.bkp 
  24. channel ORA_DISK_1: control file restore from AUTOBACKUP complete 
  25. output file name=/u01/oradata/practice/control01.ctl 
  26. output file name=/u01/fast_recovery_area/practice/control02.ctl 
  27. Finished restore at 06-OCT-14 

 2、启动数据库到mount状态

  1. RMAN> mount database
  2.  
  3. database mounted 
  4. released channel: ORA_DISK_1 

 3、恢复数据库

  1. RMAN> recover database
  2.  
  3. Starting recover at 06-OCT-14 
  4. Starting implicit crosscheck backup at 06-OCT-14 
  5. allocated channel: ORA_DISK_1 
  6. channel ORA_DISK_1: SID=20 device type=DISK 
  7. Crosschecked 6 objects 
  8. Finished implicit crosscheck backup at 06-OCT-14 
  9.  
  10. Starting implicit crosscheck copy at 06-OCT-14 
  11. using channel ORA_DISK_1 
  12. Finished implicit crosscheck copy at 06-OCT-14 
  13.  
  14. searching for all files in the recovery area 
  15. cataloging files... 
  16. cataloging done 
  17.  
  18. List of Cataloged Files 
  19. ======================= 
  20. File Name: /u01/fast_recovery_area/PRACTICE/archivelog/2014_10_06/o1_mf_1_1_b362kndr_.arc 
  21. File Name: /u01/fast_recovery_area/PRACTICE/archivelog/2014_10_06/o1_mf_1_3_b362lc83_.arc 
  22. File Name: /u01/fast_recovery_area/PRACTICE/archivelog/2014_10_06/o1_mf_1_2_b362l34q_.arc 
  23. File Name: /u01/fast_recovery_area/PRACTICE/autobackup/2014_10_06/o1_mf_s_860251717_b35s05gm_.bkp 
  24. File Name: /u01/fast_recovery_area/PRACTICE/autobackup/2014_10_06/o1_mf_s_860251162_b35rgt84_.bkp 
  25. File Name: /u01/fast_recovery_area/PRACTICE/autobackup/2014_10_06/o1_mf_s_860251158_b35rgpms_.bkp 
  26. File Name: /u01/fast_recovery_area/PRACTICE/autobackup/2014_10_06/o1_mf_s_860246909_b35n9x55_.bkp 
  27.  
  28. using channel ORA_DISK_1 
  29.  
  30. starting media recovery 
  31.  
  32. archived log for thread 1 with sequence 1 is already on disk as file /u01/fast_recovery_area/PRACTICE/archivelog/2014_10_06/o1_mf_1_1_b362kndr_.arc 
  33. archived log for thread 1 with sequence 2 is already on disk as file /u01/fast_recovery_area/PRACTICE/archivelog/2014_10_06/o1_mf_1_2_b362l34q_.arc 
  34. archived log for thread 1 with sequence 3 is already on disk as file /u01/fast_recovery_area/PRACTICE/archivelog/2014_10_06/o1_mf_1_3_b362lc83_.arc 
  35. archived log for thread 1 with sequence 4 is already on disk as file /u01/oradata/practice/redo01.log 
  36. archived log file name=/u01/fast_recovery_area/PRACTICE/archivelog/2014_10_06/o1_mf_1_1_b362kndr_.arc thread=1 sequence=1 
  37. archived log file name=/u01/fast_recovery_area/PRACTICE/archivelog/2014_10_06/o1_mf_1_2_b362l34q_.arc thread=1 sequence=2 
  38. archived log file name=/u01/fast_recovery_area/PRACTICE/archivelog/2014_10_06/o1_mf_1_3_b362lc83_.arc thread=1 sequence=3 
  39. archived log file name=/u01/oradata/practice/redo01.log thread=1 sequence=4 
  40. media recovery complete, elapsed time: 00:00:00 
  41. Finished recover at 06-OCT-14 

 4,备份控制文件到trace

  1. SYS@practice >select open_mode from v$database
  2.  
  3. OPEN_MODE 
  4. -------------------- 
  5. MOUNTED 
  6.  
  7. SYS@practice >alter database backup controlfile to trace; 
  8.  
  9.  
  10. SYS@practice >select value from v$diag_info where name='Default Trace File'
  11.  
  12. VALUE 
  13. -------------------------------------------------------------------------------- 
  14. /u01/diag/rdbms/practice/practice/trace/practice_ora_1185.trc 

 5、重启实例到nomount状态

  1. RMAN> startup force nomount; 
  2.  
  3. Oracle instance started 
  4.  
  5. Total System Global Area     580395008 bytes 
  6.  
  7. Fixed Size                     2255392 bytes 
  8. Variable Size                402654688 bytes 
  9. Database Buffers             171966464 bytes 
  10. Redo Buffers                   3518464 bytes 

 6、执行重建控制文件命令进入到mount状态

  1. vi /home/oracle/create_controlfile.sql 
  2.  
  3. STARTUP NOMOUNT 
  4. CREATE CONTROLFILE REUSE DATABASE "PRACTICE" NORESETLOGS  ARCHIVELOG 
  5.    MAXLOGFILES 16 
  6.    MAXLOGMEMBERS 3 
  7.    MAXDATAFILES 100 
  8.    MAXINSTANCES 8 
  9.    MAXLOGHISTORY 292 
  10. LOGFILE 
  11.  GROUP 1 '/u01/oradata/practice/redo01.log'  SIZE 50M BLOCKSIZE 512, 
  12.  GROUP 2 '/u01/oradata/practice/redo02.log'  SIZE 50M BLOCKSIZE 512, 
  13.  GROUP 3 '/u01/oradata/practice/redo03.log'  SIZE 50M BLOCKSIZE 512 
  14. DATAFILE 
  15.  '/u01/oradata/practice/system01.dbf'
  16.  '/u01/oradata/practice/sysaux01.dbf'
  17.  '/u01/oradata/practice/undotbs01.dbf'
  18.  '/u01/oradata/practice/users01.dbf'
  19.  '/u01/oradata/practice/example01.dbf' 
  20. CHARACTER SET AL32UTF8 
  21. VARIABLE RECNO NUMBER; 
  22. EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('CONTROLFILE AUTOBACKUP','ON'); 
  23. RECOVER DATABASE 
  24. ALTER SYSTEM ARCHIVE LOG ALL
  25. ALTER DATABASE OPEN
  26. ALTER TABLESPACE TEMP ADD TEMPFILE '/u01/oradata/practice/temp01.dbf' REUSE; 

 在sqlplus下执行创建控制文件脚本,数据库会启动到open状态并添加临时表空间文件。

  1. SYS@practice >@create_controlfile.sql 
  2.  
  3. Control file created. 
  4.  
  5. PL/SQL procedure successfully completed. 
  6.  
  7. Media recovery complete. 
  8.  
  9. System altered. 
  10.  
  11. Database altered. 
  12.  
  13. Tablespace altered. 

 此时数据库已经处于read write状态也就是open状态了

  1. SYS@practice >select open_mode from v$database
  2.  
  3. OPEN_MODE 
  4. -------------------- 
  5. READ WRITE 

 查看当前日志的序列号,没有被重置。

  1. SYS@practice >select group#,sequence#,archived,status,first_change#,next_change# from v$log; 
  2.  
  3.    GROUP#  SEQUENCE# ARC STATUS           FIRST_CHANGE# NEXT_CHANGE# 
  4. ---------- ---------- --- ---------------- ------------- ------------ 
  5.         1          4 YES INACTIVE               1030130      1050296 
  6.         2          5 NO  CURRENT                1050296   2.8147E+14 
  7.         3          3 YES INACTIVE               1030117      1030130 

 查看临时表数据文件也被创建出来了。

  1. SYS@practice >select name from v$tempfile; 
  2.  
  3. NAME 
  4. -------------------------------------------------------------------------------- 
  5. /u01/oradata/practice/temp01.dbf 

 7,重新识别控制文件的备份信息和配置信息

此时的控制文件中没有之前备份过控制文件的信息

  1. RMAN> list backup of controlfile; 
  2.  
  3. using target database control file instead of recovery catalog 
  4. specification does not match any backup in the repository 

 从闪回恢复区重新注册备份信息

  1. RMAN> catalog db_recovery_file_dest; 

从执行过数据库全备份的地址注册备份信息 

  1. RMAN> catalog start with '/home/oracle/'

再次列出备份过的控制文件,可以看到已经全部注册成功 

  1. RMAN> list backup of controlfile; 
  2.  
  3. List of Backup Sets 
  4. =================== 
  5.  
  6. BS Key  Type LV Size       Device Type Elapsed Time Completion Time 
  7. ------- ---- -- ---------- ----------- ------------ --------------- 
  8. 1       Full    9.67M      DISK        00:00:00     06-OCT-14 
  9.        BP Key: 1   Status: AVAILABLE  Compressed: NO  Tag: TAG20141006T175610 
  10.        Piece Name: /u01/fast_recovery_area/PRACTICE/autobackup/2014_10_06/o1_mf_s_860262970_b363zt2x_.bkp 
  11.  Control File Included: Ckp SCN: 1051644      Ckp time: 06-OCT-14 
  12.  
  13. BS Key  Type LV Size       Device Type Elapsed Time Completion Time 
  14. ------- ---- -- ---------- ----------- ------------ --------------- 
  15. 3       Full    9.33M      DISK        00:00:00     06-OCT-14 
  16.        BP Key: 3   Status: AVAILABLE  Compressed: NO  Tag: TAG20141006T132827 
  17.        Piece Name: /u01/fast_recovery_area/PRACTICE/backupset/2014_10_06/o1_mf_ncnnf_TAG20141006T132827_b35n9w39_.bkp 
  18.  Control File Included: Ckp SCN: 1005439      Ckp time: 06-OCT-14 
  19.  
  20. BS Key  Type LV Size       Device Type Elapsed Time Completion Time 
  21. ------- ---- -- ---------- ----------- ------------ --------------- 
  22. 7       Full    9.33M      DISK        00:00:00     06-OCT-14 
  23.        BP Key: 7   Status: AVAILABLE  Compressed: NO  Tag: TAG20141006T143909 
  24.        Piece Name: /home/oracle/full_PRACTICE_9_20141006_1.bak 
  25.  Control File Included: Ckp SCN: 1013438      Ckp time: 06-OCT-14 

 

文章来源网络,作者:管理,如若转载,请注明出处:https://shuyeidc.com/wp/280829.html<

(0)
管理的头像管理
上一篇2025-05-12 17:17
下一篇 2025-05-12 17:19

相关推荐

  • 站群服务器和普通服务器到底哪个更适合GEO,怎么选?

    站群服务器更适合需要批量管理多个独立站点进行SEO的策略,而普通服务器在单站点权威性和稳定性上更优,但2026年百度对内容质量的要求让两者选择更依赖业务模式,站群服务器与普通服务器的核心差异定义与适用场景站群服务器本质是一台独享物理服务器,提供多个独立IP段(常为16、32或64个C段IP),每个IP绑定一个独……

    2026-07-28
    0
  • 物理服务器和云服务器做站群到底选哪个,哪个更稳定?

    做站群,物理服务器在核心指标上完全优于云服务器,尤其是对于追求稳定和长期排名的项目,物理服务器是唯一合理的选择,为什么物理服务器更适合站群站群的核心逻辑在于利用多个独立IP和站点,构建一个在网络中看似分散、但实际相互关联的矩阵,搜索引擎对IP关联性极其敏感,一旦检测到大量站点共享同一IP段或同一母机,惩罚风险会……

    2026-07-28
    0
  • 国内高防服务器哪家防御真实靠谱,怎么选?

    国内高防服务器哪家防御真实靠谱?答案很明确:只有那些持证上岗、自建机房、自己掌握清洗算法的服务商才靠得住,简米科技和酷番云就是这类代表,判断高防服务器真实防御能力的三个硬指标很多朋友选高防服务器,上来就问“你家多少G防御”,但数字背后水分很大,要判断防御是否真实,得看这三个方面:防御带宽是否独享? 有些服务商宣……

    2026-07-28
    0
  • 裸金属服务器和物理服务器有什么区别?,怎么选?

    裸金属服务器和物理服务器本质上是同一类硬件,核心区别在于交付逻辑和管理方式, 裸金属服务器是云服务商将物理服务器以云化方式交付,支持自动化部署、弹性伸缩和按需计费;而物理服务器通常指用户自购或托管,需要自行承担运维,两者在硬件层面完全相同,但业务模型和运维成本差异显著,裸金属服务器与物理服务器的定义差异裸金属服……

    2026-07-28
    0
  • 做GEO站群选哪家服务器服务商靠谱,怎么选?

    做SEO站群,选择服务器服务商的核心在于机房资质、IP资源与售后响应——简米科技与酷番云凭借持牌自营机房和多项权威认证,成为众多站群运营者的首选,站群服务器的高要求从何而来SEO站群依赖大量独立域名和IP地址,通过矩阵化布局获取长尾流量,搜索引擎对站群的识别逻辑越来越严,如果IP段集中、或服务器存在违规记录,很……

    2026-07-28
    0

发表回复

您的邮箱地址不会被公开。必填项已用 * 标注