Oracle Study之案例--重建数据库控制文件

简介:

系统环境:

操作系统: Linux RH6

数据库:   Oracle 11gR2

   案例分析:

          数据库中所有的控制文件被意外破坏,非归档的库,在有trace备份的情况下,重建控制文件。

1、控制文件trace脚本

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
[oracle@rh6 ~]$ cat crctr.sql 
CREATE CONTROLFILE REUSE DATABASE  "TEST3"  NORESETLOGS  NOARCHIVELOG
     MAXLOGFILES 10
     MAXLOGMEMBERS 5
     MAXDATAFILES 300
     MAXINSTANCES 1
     MAXLOGHISTORY 292
LOGFILE
   GROUP 1  '/u01/app/oracle/oradata/test3/redo01a.log'   SIZE 100M BLOCKSIZE 512,
   GROUP 2  '/u01/app/oracle/oradata/test3/redo02a.log'   SIZE 100M BLOCKSIZE 512
-- STANDBY LOGFILE
DATAFILE
   '/u01/app/oracle/oradata/test3/system01.dbf' ,
   '/u01/app/oracle/oradata/test3/sysaux01.dbf' ,
   '/u01/app/oracle/oradata/test3/undotbs01.dbf' ,
   '/u01/app/oracle/oradata/test3/users01.dbf'
CHARACTER SET ZHS16GBK;

2、启动Instance到nomount,重建controlfile

1
2
3
4
5
6
7
8
9
10
10:59:05 SYS@ test3 >startup nomount;
ORACLE instance started.
Total System Global Area  313860096 bytes
Fixed Size                  1336232 bytes
Variable Size             213912664 bytes
Database Buffers           92274688 bytes
Redo Buffers                6336512 bytes
 
10:59:41 SYS@ test3 >@/home/oracle/crctr.sql
Control file created.

3、告警日志

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
......
CREATE CONTROLFILE REUSE DATABASE  "TEST3"  NORESETLOGS  NOARCHIVELOG
     MAXLOGFILES 10
     MAXLOGMEMBERS 5
     MAXDATAFILES 300
     MAXINSTANCES 1
     MAXLOGHISTORY 292
LOGFILE
   GROUP 1  '/u01/app/oracle/oradata/test3/redo01a.log'   SIZE 100M BLOCKSIZE 512,
   GROUP 2  '/u01/app/oracle/oradata/test3/redo02a.log'   SIZE 100M BLOCKSIZE 512
-- STANDBY LOGFILE
DATAFILE
   '/u01/app/oracle/oradata/test3/system01.dbf' ,
   '/u01/app/oracle/oradata/test3/sysaux01.dbf' ,
   '/u01/app/oracle/oradata/test3/undotbs01.dbf' ,
   '/u01/app/oracle/oradata/test3/users01.dbf'
CHARACTER SET ZHS16GBK
WARNING: Default Temporary Tablespace not specified  in  CREATE DATABASE command
Default Temporary Tablespace will be necessary  for  a locally managed database  in  future release
Wed Jan 07 11:00:02 2015
Successful mount of redo thread 1, with mount id 991126251
 
Completed: CREATE CONTROLFILE REUSE DATABASE  "TEST3"  NORESETLOGS  NOARCHIVELOG
     MAXLOGFILES 10
     MAXLOGMEMBERS 5
     MAXDATAFILES 300
     MAXINSTANCES 1
     MAXLOGHISTORY 292
LOGFILE
   GROUP 1  '/u01/app/oracle/oradata/test3/redo01a.log'   SIZE 100M BLOCKSIZE 512,
   GROUP 2  '/u01/app/oracle/oradata/test3/redo02a.log'   SIZE 100M BLOCKSIZE 512
-- STANDBY LOGFILE
DATAFILE
   '/u01/app/oracle/oradata/test3/system01.dbf' ,
   '/u01/app/oracle/oradata/test3/sysaux01.dbf' ,
   '/u01/app/oracle/oradata/test3/undotbs01.dbf' ,
   '/u01/app/oracle/oradata/test3/users01.dbf'
CHARACTER SET ZHS16GBK
Wed Jan 07 11:00:59 2015
......

3、查看数据库状态

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
11:00:03 SYS@ test3 >select status from v$instance;
STATUS
------------
MOUNTED
 
11:00:27 SYS@ test3 >select file#,name ,checkpoint_change# from v$datafile;
      FILE # NAME                                               CHECKPOINT_CHANGE#
---------- -------------------------------------------------- ------------------
          1 /u01/app/oracle/oradata/test3/system01.dbf                     333365
          2 /u01/app/oracle/oradata/test3/sysaux01.dbf                     333365
          3 /u01/app/oracle/oradata/test3/undotbs01.dbf                    333365
          4 /u01/app/oracle/oradata/test3/users01.dbf                      333365
 
11:00:46 SYS@ test3 >select file#,name ,checkpoint_change# from v$datafile_header;
      FILE # NAME                                               CHECKPOINT_CHANGE#
---------- -------------------------------------------------- ------------------
          1 /u01/app/oracle/oradata/test3/system01.dbf                     333365
          2 /u01/app/oracle/oradata/test3/sysaux01.dbf                     333365
          3 /u01/app/oracle/oradata/test3/undotbs01.dbf                    333365
          4 /u01/app/oracle/oradata/test3/users01.dbf                      333365

4、打开数据库

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
11:00:54 SYS@ test3 >alter database open;
alter database open
*
ERROR at line 1:
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1:  '/u01/app/oracle/oradata/test3/system01.dbf'
 
---打开数据库报错,需要做“media recovery”
 
执行介质恢复:
由于本库为非归档模式,只能通过current redolog来恢复
 
查看当前日志组:
[oracle@rh6 ~]$ sqlplus  '/as sysdba'
SQL*Plus: Release 11.2.0.1.0 Production on Wed Jan 7 11:02:12 2015
Copyright (c) 1982, 2009, Oracle.  All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
 
11:02:12 SYS@ test3 >select member from v$logfile;
 
MEMBER
------------------------------------------------------------------------------------------------------------------------
/u01/app/oracle/oradata/test3/redo01a. log
/u01/app/oracle/oradata/test3/redo02a. log
 
11:02:22 SYS@ test3 >select group#,sequence#,status from v$ log ;
 
     GROUP#  SEQUENCE# STATUS
---------- ---------- ----------------
          2         12 INACTIVE
          1         13 CURRENT
 
 
11:00:59 SYS@ test3 >recover database until cancel;
ORA-00279: change 333365 generated at 01/07/2015 10:30:26 needed  for  thread  1
ORA-00289: suggestion : /u01/app/oracle/product/11.2.0/db_1/dbs/arch1_13_868275293.dbf
ORA-00280: change 333365  for  thread  1 is in sequence #13
11:01:42 Specify  log : {<RET>=suggested | filename | AUTO | CANCEL}
/u01/app/oracle/oradata/test3/redo01a. log
Log applied.
Media recovery complete.
---恢复完成!
 
11:02:46 SYS@ test3 >alter database open;
alter database open
*
ERROR at line 1:
ORA-01589: must use RESETLOGS or NORESETLOGS option  for  database open
Elapsed: 00:00:00.01
 
11:02:52 SYS@ test3 >alter database open resetlogs;
Database altered.
 
---Database open成功!

查看告警日志:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
alter database open
Errors in file /u01/app/oracle/diag/rdbms/test3/test3/trace/test3_ora_3294.trc:
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1:  '/u01/app/oracle/oradata/test3/system01.dbf'
ORA-1113 signalled during: alter database open...
Wed Jan 07 11:01:40 2015
ALTER DATABASE RECOVER  database until cancel  
Media Recovery Start
Serial Media Recovery started
ORA-279 signalled during: ALTER DATABASE RECOVER  database until cancel  ...
Wed Jan 07 11:02:44 2015
ALTER DATABASE RECOVER    LOGFILE  '/u01/app/oracle/oradata/test3/redo01a.log'  
Media Recovery Log /u01/app/oracle/oradata/test3/redo01a. log
Incomplete recovery applied all redo ever generated.
Recovery completed through change 334001  time  01/07/2015 10:51:13
Media Recovery Complete (test3)
Completed: ALTER DATABASE RECOVER    LOGFILE  '/u01/app/oracle/oradata/test3/redo01a.log'  
alter database open
Errors in file /u01/app/oracle/diag/rdbms/test3/test3/trace/test3_ora_3294.trc:
ORA-01589: must use RESETLOGS or NORESETLOGS option  for  database open
ORA-1589 signalled during: alter database open...
Wed Jan 07 11:03:04 2015
alter database open resetlogs
RESETLOGS after complete recovery through change 334001
Resetting resetlogs activation ID 990996637 (0x3b11689d)
Errors in file /u01/app/oracle/diag/rdbms/test3/test3/trace/test3_ora_3294.trc:
ORA-00367: checksum error in  log  file header
ORA-00322:  log  1 of  thread  1 is not current copy
ORA-00312: online  log  thread  1:  '/u01/app/oracle/oradata/test3/redo01a.log'
Wed Jan 07 11:03:05 2015
Errors in file /u01/app/oracle/diag/rdbms/test3/test3/trace/test3_m000_3336.trc:
ORA-00316:  log  1 of  thread  1, type 0 in header is not  log  file
ORA-00312: online  log  thread  1:  '/u01/app/oracle/oradata/test3/redo01a.log'
Errors in file /u01/app/oracle/diag/rdbms/test3/test3/trace/test3_ora_3294.trc:
ORA-00367: checksum error in  log  file header
ORA-00322:  log  2 of  thread  1 is not current copy
ORA-00312: online  log  thread  1:  '/u01/app/oracle/oradata/test3/redo02a.log'
Errors in file /u01/app/oracle/diag/rdbms/test3/test3/trace/test3_m000_3336.trc:
ORA-00316:  log  2 of  thread  1, type 0 in header is not  log  file
ORA-00312: online  log  thread  1:  '/u01/app/oracle/oradata/test3/redo02a.log'
Wed Jan 07 11:03:18 2015
Setting recovery target incarnation to 2
Wed Jan 07 11:03:20 2015
Checker run found 4  new  persistent data failures
Wed Jan 07 11:03:21 2015
Assigning activation ID 991126251 (0x3b1362eb)
Thread 1 opened at  log  sequence 1
   Current  log # 1 seq# 1 mem# 0: /u01/app/oracle/oradata/test3/redo01a. log
Successful open of redo  thread  1
Wed Jan 07 11:03:22 2015
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Wed Jan 07 11:03:23 2015
SMON: enabling cache recovery
Successfully onlined Undo Tablespace 2.
Dictionary check beginning
Tablespace  'TEMPTS1'  #3 found in data dictionary,
but not in the controlfile. Adding to controlfile.
Dictionary check complete
Verifying file header compatibility  for  11g tablespace encryption..
Verifying 11g file header compatibility  for  tablespace encryption completed
SMON: enabling tx recovery
*********************************************************************
WARNING: The following temporary tablespaces contain no files.
          This condition can occur when a backup controlfile has
          been restored.  It may be necessary to add files to these
          tablespaces.  That can be done  using  the SQL statement:
  
          ALTER TABLESPACE <tablespace_name> ADD TEMPFILE
  
          Alternatively,  if  these temporary tablespaces are no longer
          needed, then they can be dropped.
            Empty temporary tablespace: TEMPTS1
*********************************************************************
Database Characterset is ZHS16GBK
No Resource Manager plan active
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
Wed Jan 07 11:03:27 2015
QMNC started with pid=19, OS id=3341 
LOGSTDBY: Validating controlfile with logical metadata
LOGSTDBY: Validation complete
Completed: alter database open resetlogs
Wed Jan 07 11:13:27 2015
Starting background process SMCO
Wed Jan 07 11:13:27 2015
SMCO started with pid=22, OS id=3382

---至此,通过trace脚本,重建控制文件成功!











本文转自 客居天涯 51CTO博客,原文链接:http://blog.51cto.com/tiany/1600356,如需转载请自行联系原作者
目录
打赏
0
0
0
0
235
分享
相关文章
【赵渝强老师】Oracle数据库的闪回表
本文介绍了Oracle数据库中的闪回表(Flashback Table)功能,它能够将表的数据快速恢复到特定时间点或系统改变号(SCN),无需备份。文章通过实战示例详细演示了如何使用闪回表恢复数据,包括授权、创建测试表、记录时间与SCN号、删除数据、启用行移动功能、执行闪回操作以及验证恢复结果等步骤。同时,还展示了如何通过触发器禁止插入操作,并在闪回过程中处理触发器的启用问题。文末附有视频讲解,帮助读者更好地理解闪回表的使用方法。
26 10
【赵渝强老师】Oracle数据库的闪回查询
本文介绍了Oracle数据库的闪回查询(Flashback Query)功能及其实际应用。闪回查询通过`AS OF`子句,结合时间戳或SCN号,可查询历史数据状态,帮助分析数据差异。文中通过具体示例演示了如何使用闪回查询:创建测试表、记录当前SCN号、更新数据并提交事务,最后通过闪回查询获取历史数据。附带的视频和代码块详细展示了操作步骤与结果。
崖山异构数据库迁移利器YMP初体验-Oracle迁移YashanDB
文章是作者小草对崖山异构数据库迁移利器 YMP 的初体验分享,包括背景、YMP 简介、体验环境说明、YMP 部署(含安装前准备、安装、卸载、启动与停止)、数据迁移及遇到的问题与解决过程。重点介绍了 YMP 功能、部署的诸多细节和数据迁移流程,还提到了安装和迁移中遇到的问题及解决办法。
【赵渝强老师】Oracle数据库的闪回技术
在Oracle数据库操作中,难免会遇到误删表或提交错误事务等问题,可能导致数据丢失甚至数据库停止运行。传统解决方法依赖备份恢复,但需提前准备正确备份。为此,Oracle提供了闪回技术,无需备份即可快速恢复数据。它支持7种类型的操作,如闪回查询、版本查询、表恢复等,能有效应对逻辑损坏和用户错误。闪回技术基于还原(undo)数据管理,启用自动管理后可实现高效恢复。
【赵渝强老师】Oracle数据库的客户端工具
本文介绍了Oracle数据库的三种客户端工具:SQL*Plus、Oracle Enterprise Manager Database Express(EM)和SQL Developer的使用方法。首先通过命令行工具SQL*Plus登录数据库,创建用户并授权,建立部门与员工表,插入数据并查询;接着讲解了如何通过浏览器访问EM界面监控数据库及表空间状态;最后演示了SQL Developer的下载安装、连接配置以及执行查询的过程,帮助用户快速上手Oracle数据库管理与操作。
服务器数据恢复—云服务器上mysql数据库数据恢复案例
某ECS网站服务器,linux操作系统+mysql数据库。mysql数据库采用innodb作为默认存储引擎。 在执行数据库版本更新测试时,操作人员误误将在本来应该在测试库执行的sql脚本在生产库上执行,导致生产库上部分表被truncate,还有部分表中少量数据被delete。
81 25
数据库数据恢复—SQL Server报错“错误 823”的数据恢复案例
SQL Server数据库附加数据库过程中比较常见的报错是“错误 823”,附加数据库失败。 如果数据库有备份则只需还原备份即可。但是如果没有备份,备份时间太久,或者其他原因导致备份不可用,那么就需要通过专业手段对数据库进行数据恢复。
虚拟化数据恢复—误还原快照导致虚拟机上数据库丢失的数据恢复案例
虚拟化数据恢复环境&故障: vmfs文件系统,存储的数据是SqlServer数据库及其他办公文件。 工作人员误将快照还原,导致了SqlServer数据库数据的丢失,需要恢复原来的SqlServer数据库文件。
81 22
数据库数据恢复——MySQL简介和数据恢复案例
MySQL数据库数据恢复环境&故障: 本地服务器,安装的windows server操作系统。 操作系统上部署MySQL单实例,引擎类型为innodb,表空间类型为独立表空间。该MySQL数据库没有备份,未开启binlog。 人为误操作,在用Delete命令删除数据时未添加where子句进行筛选导致全表数据被删除,删除后未对该表进行任何操作。
数据库数据恢复—MongoDB数据库迁移过程中丢失文件的数据恢复案例
某单位一台MongoDB数据库由于业务需求进行了数据迁移,数据库迁移后提示:“Windows无法启动MongoDB服务(位于 本地计算机 上)错误1067:进程意外终止。”

推荐镜像

更多
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等