模拟控制文件丢失的数据库恢复

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介:
更多精彩内容尽在 www.leonarding.com
 数据库版本
SYS@LEO1>showuser
USER is"SYS"
SYS@LEO1>select* from v$version;
BANNER
--------------------------------------------------------------------------------
Oracle Database11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
PL/SQL Release11.2.0.1.0 - Production
CORE    11.2.0.1.0      Production
TNS for Linux:Version 11.2.0.1.0 - Production
NLSRTL Version11.2.0.1.0 - Production
1.模拟控制文件丢失后的数据库恢复(完全恢复)
今天的主题是备份与恢复,目的就是保护数据的安全性,众所周知Oracle之所以在市场上占据了50%的份额,与它提供了强大的数据保护措施是分不开的,下面我们就来简捷的介绍一下。
1)物理备份
冷备:这是最原始的一种备份方法,又是最简单可行的,就和copy一份文件一样,直接把库shutdown拷贝一份即可,操作简单,恢复快。当在一个没有专业人员的场合下,告诉他们这么操作是简单可行的,不是不可能只是你没遇到,一切皆有可能哦!
热备:Oracle专业备份工具RMAN,这是在8i就有的东东,很强大,可以在很多维度层面进行备份恢复,利用RMAN可以在联机的情况下进行在线备份与恢复。
2)逻辑备份
Exp/Imp:表级  用户级  数据库级进行逻辑备份,逻辑是对于业务层面而言的,例如我只想备份 person employment  address表的内容用这种方法将会非常简单,它的亮点更在于备份出来的文件非常好迁移,兼容不同版本
Expdp/Impdp:这是上面2个工具的高级版,可压缩 速度更快 传输表空间的最佳利器,但只能用在服务器端
3)实例恢复
实例是什么,就是内存区+后台进程,那么实例恢复也就是恢复内存数据,例如 突然死机  掉电  强制关库等,在你startup 启动时候后台会自动进行实例恢复。SMON进程负责执行
4)介质恢复
就是恢复硬盘数据,例如  文件被误删除  坏块等,需要手工恢复
在介绍了几种备份恢复方法后,我们进入topic,如何进行控制文件丢失恢复,先看一下数据库各种状态
5SYS@LEO1>archivelog list        数据库处于非归档状态
Database logmode              No Archive Mode
Automaticarchival             Disabled
Archivedestination            /u02/app/oracle/product/11.2.0/db_1/dbs/arch
Oldest online logsequence     71
Current logsequence           73
我们要先做一个RMAN全备,首先启动归档功能
[oracle@leonarding1oracle]$ pwd
/u02/app/oracle
[oracle@leonarding1oracle]$ mkdir archdata        创建一个归档日志目录
ORACLE10g11g版本,ORACLE默认的日志归档路径为闪回恢复区,但我们也可以修改为自己指定的目录路径
SYS@LEO1>altersystem set log_archive_dest_1='location=/u02/app/oracle/archdata' scope=both;
System altered.
SYS@LEO1>setlinesize 300 pagesize 999
设置的归档日志保存路径已经生效
SYS@LEO1>selectdest_name,destination,status,error from v$archive_dest where dest_name='LOG_ARCHIVE_DEST_1';
DEST_NAME           DESTINATION               STATUS    ERROR
------------------------------------------------------------------------------------------------------------------------------------------
LOG_ARCHIVE_DEST_1   /u02/app/oracle/archdata    VALID
启动到mount状态,启动归档模式
SYS@LEO1>shutdownimmediate                 关库
Database closed.
Databasedismounted.
ORACLE instanceshut down.
SYS@LEO1>startupmount                       mount状态
ORACLE instancestarted.
Total SystemGlobal Area  471830528 bytes
Fixed Size                  2214456 bytes
Variable Size             150996424 bytes
DatabaseBuffers          310378496 bytes
Redo Buffers                8241152 bytes
Database mounted.
SYS@LEO1>alterdatabase archivelog;             启动归档模式
Database altered.
SYS@LEO1>alterdatabase open;                 打开数据库
Database altered.
注:凡是alter database操作都是对控制文件进行修改
    凡是alter system 操作都是对参数文件进行修改
SYS@LEO1>altersystem switch logfile;            手工切换日志(不会触发检查点,自动切换会)
System altered.
SYS@LEO1>selectsequence#,name,archived,applied from v$archived_log; 查看已经归档的日志信息
SEQUENCE#  NAME                                     ARC   APPLIED
---------------------------------------------------------------------------------------------------------------------------------------------
73            /u02/app/oracle/archdata/1_73_813654649.dbf   YES    NO
操作系统层面查看,没有问题也生成了
[oracle@leonarding1archdata]$ ll
total 5624
-rw-r----- 1oracle asmadmin 5757952 Apr 25 21:28 1_73_813654649.dbf
SYS@LEO1>archivelog list
Database logmode              Archive Mode         归档模式
Automaticarchival             Enabled               自动归档启动
Archivedestination           /u02/app/oracle/archdata 归档日志目录
Oldest online logsequence     72                     旧在线日志序号
Next log sequenceto archive   74                     下一个归档日志序号
Current logsequence         74                     当前日志序号
下面我们就要进行RMAN全库备份了,在此之前还需要设置一下RMAN的环境变量
6)登陆RMAN
[oracle@leonarding1archdata]$ rman target sys/oracle
Recovery Manager:Release 11.2.0.1.0 - Production on Fri Apr 26 06:05:24 2013
Copyright (c)1982, 2009, Oracle and/or its affiliates. All rights reserved.
connectedto target database: LEO1 (DBID=1692458681)  只有连接到目标库才能显示环境变量,这些元数据是存放在控制文件中的
显示当前RMAN的环境变量
RMAN> show all;
using targetdatabase control file instead of recovery catalog
RMAN configurationparameters for database with db_unique_name LEO1 are:
CONFIGURERETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUPOPTIMIZATION OFF; # default
CONFIGURE DEFAULTDEVICE TYPE TO DISK; # default
CONFIGURECONTROLFILE AUTOBACKUP OFF; # default
CONFIGURECONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICETYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILEBACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOGBACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGUREMAXSETSIZE TO UNLIMITED; # default
CONFIGUREENCRYPTION FOR DATABASE OFF; # default
CONFIGUREENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURECOMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE ;# default
CONFIGUREARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOTCONTROLFILE NAME TO '/u02/app/oracle/product/11.2.0/db_1/dbs/snapcf_LEO1.f'; #default
创建RMAN默认备份介质保存目录/u02/app/oracle/backup
[oracle@leonarding1oracle]$ mkdir backup
RMAN> configure channel device type disk format'/u02/app/oracle/backup/DB_%U';
new RMANconfiguration parameters:
CONFIGURE CHANNELDEVICE TYPE DISK FORMAT   '/u02/app/oracle/backup/DB_%U';
new RMANconfiguration parameters are successfully stored    man配置参数生效
配置控制文件自动备份并保存到/u02/app/oracle/backup/control目录
[oracle@leonarding1backup]$ mkdir control
[oracle@leonarding1control]$ pwd
/u02/app/oracle/backup/control
RMAN> configure controlfile autobackup on;                启动控制文件自动备份
new RMANconfiguration parameters:
CONFIGURECONTROLFILE AUTOBACKUP ON;
new RMANconfiguration parameters are successfully stored
RMAN> configure controlfile autobackup format for device type diskto '/u02/app/oracle/backup/control/cf_%F';
new RMANconfiguration parameters:       配置控制文件自动备份目录和格式
CONFIGURECONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO'/u02/app/oracle/backup/control/cf_%F';
new RMANconfiguration parameters are successfully stored
调整备份介质保留期为7
RMAN> configureretention policy to recovery window of 7 days;
new RMANconfiguration parameters:
CONFIGURERETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
new RMANconfiguration parameters are successfully stored
显示配置后RMAN环境变量
RMAN> show all;
RMAN configurationparameters for database with db_unique_name LEO1 are:
CONFIGURERETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
CONFIGURE BACKUPOPTIMIZATION OFF; # default
CONFIGURE DEFAULTDEVICE TYPE TO DISK; # default
CONFIGURECONTROLFILE AUTOBACKUP ON;
CONFIGURECONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO'/u02/app/oracle/backup/control/cf_%F';
CONFIGURE DEVICETYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILEBACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGUREARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURECHANNEL DEVICE TYPE DISK FORMAT  '/u02/app/oracle/backup/DB_%U';
CONFIGUREMAXSETSIZE TO UNLIMITED; # default
CONFIGUREENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTIONALGORITHM 'AES128'; # default
CONFIGURECOMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE ;# default
CONFIGUREARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOTCONTROLFILE NAME TO '/u02/app/oracle/product/11.2.0/db_1/dbs/snapcf_LEO1.f'; #default
带颜色的就是我们刚刚修改过的变量
7)启动RMAN的压缩备份功能对数据库进行全备Oracle10g只压缩RMAN元数据11g真正压缩了数据
backup as compressed backupset full database format                命令行中直接指定压缩选项即可
'/u02/app/oracle/backup/full_bk1_%u%p%s.rmn'include current controlfile
plus
archivelog format'/u02/app/oracle/backup/arch_bk1_%u%p%s.rmn' delete all input; 全部备份完之后,删除备份过的旧归档日志
如果我们想使用默认通道默认配置备份一次数据库,同时删除备份过的归档日志,那么命令为
RMAN> backup ascompressed backupset full database include current controlfile plus archivelogdelete all input;
Starting backup at26-APR-13      备份时间
current logarchived
allocated channel:ORA_DISK_1     默认通道磁盘
channelORA_DISK_1: SID=140 device type=DISK
channelORA_DISK_1: starting compressed archived log backup set   先压缩备份的归档日志
channel ORA_DISK_1:specifying archived log(s) in backup set       备份了73 74归档日志
input archived logthread=1 sequence=73 RECID=1 STAMP=813706084
input archived logthread=1 sequence=74 RECID=2 STAMP=813739820
channelORA_DISK_1: starting piece 1 at 26-APR-13                    启动备份片
channelORA_DISK_1: finished piece 1 at 26-APR-13                    完成备份片
piece handle= /u02/app/oracle/backup/DB_01o81bpd_1_1 tag=TAG20130426T065020 comment=NONE
channelORA_DISK_1: backup set complete, elapsed time: 00:00:01   备份完成用时1
channelORA_DISK_1: deleting archived log(s)               删除已备份的归档日志73 74
archived log filename=/u02/app/oracle/archdata/1_73_813654649.dbf RECID=1 STAMP=813706084
archived log filename=/u02/app/oracle/archdata/1_74_813654649.dbf RECID=2 STAMP=813739820
Finished backup at26-APR-13
Starting backup at26-APR-13
using channelORA_DISK_1
channelORA_DISK_1: starting compressed full datafile backup set    再压缩备份数据文件
channelORA_DISK_1: specifying datafile(s) in backup set        指定备份如下数据文件
input datafilefile number=00001 name=/u02/app/oracle/oradata/LEO1/system01.dbf
input datafilefile number=00002 name=/u02/app/oracle/oradata/LEO1/sysaux01.dbf
input datafilefile number=00003 name=/u02/app/oracle/oradata/LEO1/undotbs01.dbf
input datafilefile number=00005 name=/u02/app/oracle/oradata/LEO1/leo1.dbf
input datafilefile number=00004 name=/u02/app/oracle/oradata/LEO1/users01.dbf
channelORA_DISK_1: starting piece 1 at 26-APR-13             启动备份片
channelORA_DISK_1: finished piece 1 at 26-APR-13             完成备份片
piece handle= /u02/app/oracle/backup/DB_02o81bpf_1_1 tag=TAG20130426T065022 comment=NONE
channelORA_DISK_1: backup set complete, elapsed time: 00:01:45备份完成用时145
channelORA_DISK_1: starting compressed full datafile backup set
channelORA_DISK_1: specifying datafile(s) in backup set
includingcurrent control file in backupset          这个是备份数据文件的同时包含备份控制文件
channelORA_DISK_1: starting piece 1 at 26-APR-13
channel ORA_DISK_1:finished piece 1 at 26-APR-13
piece handle= /u02/app/oracle/backup/DB_03o81bso_1_1 tag=TAG20130426T065022 comment=NONE
channelORA_DISK_1: backup set complete, elapsed time: 00:00:01 备份完成用时1
Finished backup at26-APR-13
Starting backup at26-APR-13
current logarchived
using channelORA_DISK_1
channelORA_DISK_1: starting compressed archived log backup set
channelORA_DISK_1: specifying archived log(s) in backup set
input archived logthread=1 sequence=75 RECID=3 STAMP=813739930  备份75归档日志
channel ORA_DISK_1:starting piece 1 at 26-APR-13
channelORA_DISK_1: finished piece 1 at 26-APR-13
piece handle= /u02/app/oracle/backup/DB_04o81bsq_1_1 tag=TAG20130426T065210 comment=NONE
channelORA_DISK_1: backup set complete, elapsed time: 00:00:01     备份完成用时1
channelORA_DISK_1: deleting archived log(s)                删除已备份的归档日志75
archived log filename=/u02/app/oracle/archdata/1_75_813654649.dbf RECID=3 STAMP=813739930
Finished backup at26-APR-13
Starting ControlFile and SPFILE Autobackup at 26-APR-13  启动控制文件和参数文件自动备份
piece handle= /u02/app/oracle/backup/control/cf_c-1692458681-20130426-00 comment=NONE
Finished ControlFile and SPFILE Autobackup at 26-APR-13  完成自动备份
在操作系统上都可以找到对应的备份集并且已经删除了备份过的旧归档日志
[oracle@leonarding1backup]$ pwd
/u02/app/oracle/backup
[oracle@leonarding1backup]$ ll
total 249468
drwxr-xr-x 2oracle oinstall      4096 Apr 26 06:52control
-rw-r-----1 oracle asmadmin   2790912 Apr 26 06:50DB_01o81bpd_1_1
-rw-r-----1 oracle asmadmin 251551744 Apr 26 06:52 DB_02o81bpf_1_1
-rw-r-----1 oracle asmadmin   1097728 Apr 26 06:52DB_03o81bso_1_1
-rw-r-----1 oracle asmadmin      7168 Apr 26 06:52DB_04o81bsq_1_1
[oracle@leonarding1 backup]$ cd control/
[oracle@leonarding1control]$ ll
total 9600
-rw-r-----1 oracle asmadmin 9830400 Apr 26 06:52 cf_c-1692458681-20130426-00
[oracle@leonarding1archdata]$ pwd
/u02/app/oracle/archdata
[oracle@leonarding1archdata]$ ll       归档日志全没有了
total 0
新的归档日志是从76号开始,75号之前都已经备份并删除
SYS@LEO1>archivelog list
Database logmode             Archive Mode
Automaticarchival             Enabled
Archivedestination           /u02/app/oracle/archdata
Oldest online logsequence      74
Next log sequenceto archive    76
Current logsequence          76
到此我们的备份准备已经完成,稍微休息一下:)坐车上班班
8SYS@LEO1>selectstatus from v$instance;         检查数据库状态
STATUS
------------
OPEN
LEO1@LEO1>showparameter control_files        我们检查一下控制文件个数
NAME                                 TYPE        VALUE
----------------------------------------------- ------------------------------
control_files                        string      /u02/app/oracle/oradata/LEO1/control01.ctl,
/u02/app/oracle/oradata/LEO1/control02.ctl
[oracle@leonarding1LEO1]$ ll                   操作系统上也是2个没有问题
total 2618136
-rw-r----- 1oracle asmadmin   9748480 Apr 26 09:01control01.ctl
-rw-r----- 1oracle asmadmin   9748480 Apr 26 09:01control02.ctl
一般控制文件丢失大多数都是被误删除了,用rm 命令删除control01.ctl文件
[oracle@leonarding1trace]$ pwd
/u02/app/oracle/diag/rdbms/leo1/LEO1/trace
[oracle@leonarding1 trace]$ tail -10falert_LEO1.log       实时监控告警日志看看有什么变化
Fri Apr 2606:50:20 2013
Thread 1 advancedto log sequence 75 (LGWR switch)
  Current log# 3 seq# 75 mem# 0:/u02/app/oracle/oradata/LEO1/redo03.log
Archived Log entry2 added for thread 1 sequence 74 ID 0x64e13fb9 dest 1:
Fri Apr 2606:52:10 2013
ALTER SYSTEMARCHIVE LOG
Fri Apr 2606:52:10 2013
Thread 1 advancedto log sequence 76 (LGWR switch)
  Current log# 1 seq# 76 mem# 0:/u02/app/oracle/oradata/LEO1/redo01.log
Archived Log entry3 added for thread 1 sequence 75 ID 0x64e13fb9 dest 1:
[oracle@leonarding1LEO1]$ rm control01.ctl             模拟control01文件丢失的场景
LEO1@LEO1>createtablespace test datafile '/u02/app/oracle/oradata/LEO1/test01.dbf' size 10mautoextend off;
create tablespacetest datafile '/u02/app/oracle/oradata/LEO1/test01.dbf' size 10m autoextend off
l       我们创建一个表空间,此时突然报错
ERROR at line 1:
ORA-00210:cannot open the specified control file  不能打开指定的控制文件
ORA-00202:control file: '/u02/app/oracle/oradata/LEO1/control01.ctl'    控制文件丢失
ORA-27041:unable to open file                 无法打开这个文件
Linux-x86_64Error: 2: No such file or directory     找不到这个文件,好恐怖bless,赶紧看看alert日志
Additionalinformation: 3
Alert_LEO1.log日志内容
create tablespacetest datafile '/u02/app/oracle/oradata/LEO1/test01.dbf' size 10m autoextend off
ORA-210 signalledduring: create tablespace test datafile'/u02/app/oracle/oradata/LEO1/test01.dbf' size 10m autoextend off...
Fri Apr 2609:14:15 2013
Errors in file/u02/app/oracle/diag/rdbms/leo1/LEO1/trace/LEO1_m000_7975.trc:
ORA-00210: cannotopen the specified control file
ORA-00202: controlfile: '/u02/app/oracle/oradata/LEO1/control01.ctl'
ORA-27041: unableto open file
Linux-x86_64Error: 2: No such file or directory
Additionalinformation: 3
是不是和上面报的错误信息一样啊,由于是我们自己搞的鬼,所以我们明白是怎么回事,如果在生产库上就要首先查看日志信息进行分析啦,好了现在我们开始修复吧->start on
思路:我们首先要清楚oracle为了保证其稳定性,控制文件都是多路复用的,如果使用dbca安装10g默认有3个控制文件 11g有两个,我们删除了其中一个,可能有的朋友会说,我们镜像出来一个控制文件不就好了么,没错思路很正确,但前提是要关闭数据库使所有的SCN号一致,也有可能你会遇上无法立即关闭的情况,木有办法只能强制关闭了,
SYS@LEO1>shutdownimmediate
ORA-00210: cannotopen the specified control file
ORA-00202: controlfile: '/u02/app/oracle/oradata/LEO1/control01.ctl'
ORA-27041: unableto open file
Linux-x86_64Error: 2: No such file or directory
Additionalinformation: 3
SYS@LEO1>shutdownabort
ORACLE instanceshut down.
[oracle@leonarding1LEO1]$ cp control02.ctl control01.ctl  使用完好的控制文件恢复被删除的控制文件
[oracle@leonarding1LEO1]$ ll
total 2618136
-rw-r----- 1oracle oinstall   9748480 Apr 26 09:34control01.ctl
-rw-r----- 1oracle asmadmin   9748480 Apr 26 09:28control02.ctl
SYS@LEO1>startupmount   启动到mount状态没有报错,说明我们恢复成功了
ORACLE instancestarted.
Total SystemGlobal Area  471830528 bytes
Fixed Size                  2214456 bytes
Variable Size             150996424 bytes
DatabaseBuffers          310378496 bytes
Redo Buffers                8241152 bytes
Database mounted.
SYS@LEO1>selectcheckpoint_change# from v$database;  数据库全局SCN号,放在控制文件里
CHECKPOINT_CHANGE#
--------------------------------
            909922
SYS@LEO1>selectname,checkpoint_change# from v$datafile; 数据文件SCN号,放在控制文件里
NAME                                       CHECKPOINT_CHANGE#
----------------------------------------------------------------------------------------------------------------------------------------------
/u02/app/oracle/oradata/LEO1/system01.dbf        909922
/u02/app/oracle/oradata/LEO1/sysaux01.dbf        909922
/u02/app/oracle/oradata/LEO1/undotbs01.dbf       909922
/u02/app/oracle/oradata/LEO1/users01.dbf         909922
/u02/app/oracle/oradata/LEO1/leo1.dbf            909922
SYS@LEO1>selectname,checkpoint_change# from v$datafile_header; 数据文件头SCN号,放在数据文件头里
NAME                                       CHECKPOINT_CHANGE#
----------------------------------------------------------------------------------------------------------------------------------------------
/u02/app/oracle/oradata/LEO1/system01.dbf        909922
/u02/app/oracle/oradata/LEO1/sysaux01.dbf        909922
/u02/app/oracle/oradata/LEO1/undotbs01.dbf       909922
/u02/app/oracle/oradata/LEO1/users01.dbf         909922
/u02/app/oracle/oradata/LEO1/leo1.dbf            909922
SYS@LEO1>selectname,last_change# from v$datafile;   数据文件结束SCN号,放在控制文件里
NAME                                       LAST_CHANGE#
----------------------------------------------------------------------------------------------------------------------------------------------
/u02/app/oracle/oradata/LEO1/system01.dbf
/u02/app/oracle/oradata/LEO1/sysaux01.dbf
/u02/app/oracle/oradata/LEO1/undotbs01.dbf
/u02/app/oracle/oradata/LEO1/users01.dbf
/u02/app/oracle/oradata/LEO1/leo1.dbf
这个LAST_CHANGENULL,我们要知道Oracle做不做实例恢复就是看这个SCN是否为NULL
如果数据库非正常关闭值为NULL
如果数据库正常关闭值为xxxxxx
特例:数据库为open状态时LAST_CHANGE也为NULL,但现在我们是mount状态
SYS@LEO1>selectstatus from v$instance;
STATUS
------------
MOUNTED
我们在开打数据库的一霎那就会启动实例恢复,看alert日志即可
SYS@LEO1>alterdatabase open;
Database altered.
Alert日志内容
Fri Apr 2609:50:08 2013
alter databaseopen                          打开数据库
Beginningcrash recovery of 1 threads            进行实例恢复
parallel recovery started with 2 processes        启动2个恢复进程
Started redo scan
Completed redoscan
read 30 KB redo, 31 data blocks need recovery
Started redoapplication at
Thread 1: logseq 76, block 23074
Recovery of OnlineRedo Log: Thread 1 Group 1 Seq 76 Reading mem 0 76号日志为起始位置
  Mem# 0:/u02/app/oracle/oradata/LEO1/redo01.log  应用redo日志进行恢复
Completed redoapplication of 0.02MB
Completed crashrecovery at
Thread 1: logseq 76, block 23134, scn 934394    一直应用到redo最后一个SCN
31 data blocks read, 31 data blocks written,30 redo k-bytes read  恢复了31个数据块,读取了30K redo
Fri Apr 2609:50:08 2013
LGWR: STARTINGARCH PROCESSES           启动归档进程进行归档
Fri Apr 2609:50:08 2013
ARC0 started withpid=22, OS id=8396
ARC0: Archivalstarted
LGWR: STARTINGARCH PROCESSES COMPLETE
ARC0: STARTINGARCH PROCESSES
Fri Apr 2609:50:09 2013
ARC1 started withpid=23, OS id=8400
Fri Apr 2609:50:09 2013
ARC2 started withpid=24, OS id=8404
ARC1: Archivalstarted
Fri Apr 2609:50:09 2013
ARC3 started withpid=25, OS id=8408
ARC2: Archivalstarted
ARC1: Becoming the'no FAL' ARCH
ARC1: Becoming the'no SRL' ARCH
ARC2: Becoming theheartbeat ARCH
Thread 1 advancedto log sequence 77 (thread open)
Thread 1 opened atlog sequence 77
  Current log# 2 seq# 77 mem# 0:/u02/app/oracle/oradata/LEO1/redo02.log
Successful open ofredo thread 1
MTTR advisory isdisabled because FAST_START_MTTR_TARGET is not set
Fri Apr 2609:50:09 2013
SMON: enablingcache recovery          SMON进程负责实例的恢复
Archived Log entry4 added for thread 1 sequence 76 ID 0x64e13fb9 dest 1:
ARC3: Archivalstarted
ARC0: STARTINGARCH PROCESSES COMPLETE
Successfullyonlined Undo Tablespace 2.
Verifying fileheader compatibility for 11g tablespace encryption..
Verifying 11g fileheader compatibility for tablespace encryption completed
SMON: enabling txrecovery
DatabaseCharacterset is ZHS16GBK
No ResourceManager plan active
replication_dependency_trackingturned off (no async multimaster replication found)
Startingbackground process QMNC
Fri Apr 2609:50:14 2013
QMNC started withpid=26, OS id=8412
Completed: alterdatabase open         到此我们完成数据库的open动作,实例恢复完毕
Fri Apr 2609:50:18 2013
Startingbackground process CJQ0
Fri Apr 2609:50:18 2013
CJQ0 started withpid=30, OS id=8436
alter日志的流程上我们就可以看出,oracle实例恢复的内容过程是什么样的,通过以上案例我们即了解了控制文件的恢复过程又了解了数据库实例的恢复过程,可谓一举两得,大家好好的消化消化,休息一下,该上班工作啦:)
9)下了班我们继续,上次讲到了,使用copy方式来恢复控制文件,下面再讲一种使用备份集来恢复控制文件的方法。
【参】Books-> Backupand Recovery Reference -> RESTORE   RECOVER   参考官方文档是个好习惯
SYS@LEO1>shutdownimmediate                  我们先关闭数据库
Database closed.
Databasedismounted.
ORACLE instanceshut down.
[oracle@leonarding1LEO1]$ rm -rf control01.ctl     删除控制文件
SYS@LEO1>startup
ORACLE instancestarted.
Total SystemGlobal Area  471830528 bytes
Fixed Size                  2214456 bytes
Variable Size             150996424 bytes
DatabaseBuffers          310378496 bytes
Redo Buffers                8241152 bytes
ORA-00205: errorin identifying control file, check alert log for more info
指定的控制文件错误,检查alert日志获取更多信息
[oracle@leonarding1trace]$ tail -20f alert_LEO1.log
ALTERDATABASE   MOUNT
ORA-00210: cannotopen the specified control file
ORA-00202: controlfile: '/u02/app/oracle/oradata/LEO1/control01.ctl'  这写着1号控制文件丢失
ORA-27037: unableto obtain file status
Linux-x86_64Error: 2: No such file or directory       找不到这个文件
Additionalinformation: 3
ORA-205 signalledduring: ALTER DATABASE   MOUNT...
Fri Apr 2619:44:05 2013
Checker run found1 new persistent data failures
SYS@LEO1>shutdownimmediate                   关库
ORA-01507:database not mounted
ORACLE instanceshut down.
[oracle@leonarding1~]$ rman target sys/oracle        链接RMAN
Recovery Manager:Release 11.2.0.1.0 - Production on Fri Apr 26 19:49:00 2013
Copyright (c)1982, 2009, Oracle and/or its affiliates. All rights reserved.
connected totarget database (not started)   库没有启动
RMAN> startupnomount                 把库启动到nomount状态
Oracle instancestarted
Total System GlobalArea     471830528 bytes
Fixed Size                     2214456 bytes
Variable Size                150996424 bytes
DatabaseBuffers             310378496 bytes
Redo Buffers                   8241152 bytes
有一个地方容易出错,大家都喜欢用这条语句来恢复
RMAN> RESTORECONTROLFILE FROM AUTOBACKUP;
Starting restoreat 26-APR-13
using channelORA_DISK_1
channelORA_DISK_1: looking for AUTOBACKUP on day: 20130426
channelORA_DISK_1: looking for AUTOBACKUP on day: 20130425
channelORA_DISK_1: looking for AUTOBACKUP on day: 20130424
channelORA_DISK_1: looking for AUTOBACKUP on day: 20130423
channelORA_DISK_1: looking for AUTOBACKUP on day: 20130422
channelORA_DISK_1: looking for AUTOBACKUP on day: 20130421
channelORA_DISK_1: looking for AUTOBACKUP on day: 20130420
channelORA_DISK_1: no AUTOBACKUP in 7 days found
RMAN-00571:===========================================================
RMAN-00569:=============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571:===========================================================
RMAN-03002:failure of restore command at 04/26/2013 20:01:04
RMAN-06172: noAUTOBACKUP found or specified handle is not a valid copy or piece
报错:说找不到指定的备份集
RMAN> show all;
RMAN configurationparameters for database with db_unique_name LEO1 are:
CONFIGURERETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUPOPTIMIZATION OFF; # default
CONFIGURE DEFAULTDEVICE TYPE TO DISK; # default
CONFIGURECONTROLFILE AUTOBACKUP OFF; # default
CONFIGURECONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
原来我们配置的控制文件自动备份保存目录是不是失效啦,这是为什么呢,原来rman元数据信息是写在controlfile中的,而现在控制文件又损坏了不能打开,一个不能打开的文件我们是不是读不到里面的内容啊,我们只启动到了nomount状态只读取参数文件信息,因此我们在恢复控制文件的时候指定一下“原来备份的保存目录”告诉rman从哪个路径下可以找到备份集就可以了。
RMAN> restore controlfile from'/u02/app/oracle/backup/control/cf_c-1692458681-20130426-00';
Starting restoreat 26-APR-13
using channelORA_DISK_1
channelORA_DISK_1: restoring control file
channelORA_DISK_1: restore complete, elapsed time: 00:00:04
output filename=/u02/app/oracle/oradata/LEO1/control01.ctl
output filename=/u02/app/oracle/oradata/LEO1/control02.ctl
Finished restoreat 26-APR-13
[oracle@leonarding1LEO1]$ ll
total 2618136
-rw-r----- 1oracle asmadmin   9748480 Apr 26 20:17control01.ctl
-rw-r----- 1oracle asmadmin   9748480 Apr 26 20:17control02.ctl
我们一起恢复了所有的控制文件
RMAN> alterdatabase mount;                  现在数据库可以正常加载了对吧
database mounted
released channel:ORA_DISK_1
那我们可以alter database open来打开数据库吗,显然是不行的,大家知道为什么吗?
你想想如果这个控制文件是从10天之前的一个备份还原的与当前的数据库物理结构能一致吗!
显然是不可以的,我们只有用备份在重新同步数据库
RMAN> restoredatabase;              RMAN备份还原restore(复制)数据文件
Starting restoreat 26-APR-13
allocated channel:ORA_DISK_1
channel ORA_DISK_1:SID=134 device type=DISK
channelORA_DISK_1: starting datafile backup set restore
channelORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1:restoring datafile 00001 to /u02/app/oracle/oradata/LEO1/system01.dbf
channelORA_DISK_1: restoring datafile 00002 to/u02/app/oracle/oradata/LEO1/sysaux01.dbf
channelORA_DISK_1: restoring datafile 00003 to/u02/app/oracle/oradata/LEO1/undotbs01.dbf
channelORA_DISK_1: restoring datafile 00004 to/u02/app/oracle/oradata/LEO1/users01.dbf
channelORA_DISK_1: restoring datafile 00005 to /u02/app/oracle/oradata/LEO1/leo1.dbf
channelORA_DISK_1: reading from backup piece /u02/app/oracle/backup/DB_02o81bpf_1_1
channelORA_DISK_1: piece handle=/u02/app/oracle/backup/DB_02o81bpf_1_1tag=TAG20130426T065022
channelORA_DISK_1: restored backup piece 1
channelORA_DISK_1: restore complete, elapsed time: 00:02:36
Finished restoreat 26-APR-13
RMAN> recoverdatabase;                应用redo日志恢复recover(同步)数据库
Starting recoverat 26-APR-13
using channelORA_DISK_1
starting mediarecovery
archived log forthread 1 with sequence 75 is already on disk as file/u02/app/oracle/oradata/LEO1/redo03.log
archived log forthread 1 with sequence 76 is already on disk as file/u02/app/oracle/oradata/LEO1/redo01.log
archived log forthread 1 with sequence 77 is already on disk as file/u02/app/oracle/oradata/LEO1/redo02.log
archived log filename=/u02/app/oracle/oradata/LEO1/redo03.log thread=1 sequence=75
archived log filename=/u02/app/oracle/oradata/LEO1/redo01.log thread=1 sequence=76
archived log filename=/u02/app/oracle/oradata/LEO1/redo02.log thread=1 sequence=77
mediarecovery complete, elapsed time: 00:00:14   这就是介质恢复,要把数据文件同步到损坏的前一刻
因为这是不完全恢复,因此我们不能用alter database open来打开数据库
RMAN> alterdatabase open resetlogs;
database opened
SYS@LEO1>selectstatus from v$instance;           数据库已打开,可以正常使用
STATUS
------------
OPEN
小结:因为我们进行了不完全恢复,恢复到之前的某一点,现在数据库以这点为一个新的起点(相当是一个焕然一新的库),resetlogs就是重置归档日志从1开始编码,之前的归档全部无效。
SYS@LEO1>altersystem switch logfile;             我们重新切换一次
System altered.
[oracle@leonarding1oracle]$ cd archdata
[oracle@leonarding1archdata]$ ll
total 14028
-rw-r-----1 oracle asmadmin   222720 Apr 26 21:051_1_813790699.dbf
-rw-r----- 1oracle asmadmin     5632 Apr 26 20:581_75_813654649.dbf
-rw-r----- 1oracle asmadmin 11844608 Apr 26 20:58 1_76_813654649.dbf
-rw-r----- 1oracle asmadmin  2284032 Apr 26 20:581_77_813654649.dbf
注意:归档日志编码重置了,从1开始了,75 76 77归档日志全部无效了,为了不碍眼你可以删除掉。





 本文转自 ztfriend 51CTO博客,原文链接:http://blog.51cto.com/leonarding/1188596 ,如需转载请自行联系原作者

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
2月前
|
SQL 关系型数据库 MySQL
数据库导入SQL文件:全面解析与操作指南
在数据库管理中,将SQL文件导入数据库是一个常见且重要的操作。无论是迁移数据、恢复备份,还是测试和开发环境搭建,掌握如何正确导入SQL文件都至关重要。本文将详细介绍数据库导入SQL文件的全过程,包括准备工作、操作步骤以及常见问题解决方案,旨在为数据库管理员和开发者提供全面的操作指南。一、准备工作在导
481 0
|
16天前
|
关系型数据库 MySQL 数据库
数据库数据恢复—MYSQL数据库文件损坏的数据恢复案例
mysql数据库文件ibdata1、MYI、MYD损坏。 故障表现:1、数据库无法进行查询等操作;2、使用mysqlcheck和myisamchk无法修复数据库。
|
20天前
|
SQL 关系型数据库 MySQL
MySQL导入.sql文件后数据库乱码问题
本文分析了导入.sql文件后数据库备注出现乱码的原因,包括字符集不匹配、备注内容编码问题及MySQL版本或配置问题,并提供了详细的解决步骤,如检查和统一字符集设置、修改客户端连接方式、检查MySQL配置等,确保导入过程顺利。
|
27天前
|
Oracle 关系型数据库 数据库
Oracle数据恢复—Oracle数据库文件有坏快损坏的数据恢复案例
一台Oracle数据库打开报错,报错信息: “system01.dbf需要更多的恢复来保持一致性,数据库无法打开”。管理员联系我们数据恢复中心寻求帮助,并提供了Oracle_Home目录的所有文件。用户方要求恢复zxfg用户下的数据。 由于数据库没有备份,无法通过备份去恢复数据库。
|
2月前
|
SQL 关系型数据库 MySQL
|
2月前
|
存储 关系型数据库 MySQL
PACS系统 中 dicom 文件在mysql 8.0 数据库中的 存储和读取(pydicom 库使用)
PACS系统 中 dicom 文件在mysql 8.0 数据库中的 存储和读取(pydicom 库使用)
43 2
|
3月前
|
Oracle 关系型数据库 数据库
数据库数据恢复—Oracle数据库文件出现坏块的数据恢复案例
打开oracle数据库报错“system01.dbf需要更多的恢复来保持一致性,数据库无法打开”。 数据库没有备份,无法通过备份去恢复数据库。用户方联系北亚企安数据恢复中心并提供Oracle_Home目录中的所有文件,急需恢复zxfg用户下的数据。 出现“system01.dbf需要更多的恢复来保持一致性”这个报错的原因可能是控制文件损坏、数据文件损坏,数据文件与控制文件的SCN不一致等。数据库恢复工程师对数据库文件进一步检测、分析后,发现sysaux01.dbf文件损坏,有坏块。 修复并启动数据库后仍然有许多查询报错,export和data pump工具使用报错。从数据库层面无法修复数据库。
数据库数据恢复—Oracle数据库文件出现坏块的数据恢复案例
|
2月前
|
SQL 存储 关系型数据库
SQL文件导入MySQL数据库的详细指南
数据库中的数据转移是一项常规任务,无论是在数据迁移过程中,还是在数据备份、还原场景中,导入导出SQL文件显得尤为重要。特别是在使用MySQL数据库时,如何将SQL文件导入数据库是一项基本技能。本文将详细介绍如何将SQL文件导入MySQL数据库,并提供一个清晰、完整的步骤指南。这篇文章的内容字数大约在
356 1
|
2月前
|
Java 关系型数据库 数据库连接
SpringBoot项目使用yml文件链接数据库异常
【10月更文挑战第3天】Spring Boot项目中数据库连接问题可能源于配置错误或依赖缺失。YAML配置文件的格式不正确,如缩进错误,会导致解析失败;而数据库驱动不匹配、连接字符串或认证信息错误同样引发连接异常。解决方法包括检查并修正YAML格式,确认配置属性无误,以及添加正确的数据库驱动依赖。利用日志记录和异常信息分析可辅助问题排查。
335 10
|
2月前
|
Java 关系型数据库 MySQL
SpringBoot项目使用yml文件链接数据库异常
【10月更文挑战第4天】本文分析了Spring Boot应用在连接数据库时可能遇到的问题及其解决方案。主要从四个方面探讨:配置文件格式错误、依赖缺失或版本不兼容、数据库服务问题、配置属性未正确注入。针对这些问题,提供了详细的检查方法和调试技巧,如检查YAML格式、验证依赖版本、确认数据库服务状态及用户权限,并通过日志和断点调试定位问题。
177 6