所有DBA都应该掌握备份数据库的方法,而掌握恢复数据库的方法更加重要。出现介质失效情况时,大家都指望DBA使数据库恢复正常。Oracle提供了两种常用的备份与恢复方法。
1.用户管理方法
2.RMAN
用户管理的备份可以自定义备份名称,因为所有备份与恢复步骤都是手动执行的。用户管理的备份分为两类:热备份和冷备份。冷备份也称之为脱机备份,因为在备份过程中数据库属于脱机状态。热备份也称为联机备份,因为在备份过程中,数据库处于运行状态。
RMAN是Oracle备份与恢复的期间工具。它可以自动管理绝大部分备份与恢复操作。在执行备份与恢复操作时,应该使用RMAN。既然如此,为什么还要学习有十多年历史的用户管理方法呢?下面是这样做的原因:
1.有些公司仍旧使用用户管理的备份与恢复方法。因此,你必须要了解这种技术。
2.手动执行用户管理的备份与恢复操作,可以嘉善你对Oracle备份与恢复体系结构的了解。有助于几解决备份与恢复工具的问题,并掌握Oracle关键工具基础知识。
3.有助于更详细的了解RMAN和该功能的价值。
4.有助于深入了解曾经出现过的极困难的数据恢复情况。
因此,你应该熟悉用户管理的备份与恢复技巧。亲手实践可以大幅度加深对备份与恢复操作的了解,如果要备份哪些文件以及在恢复时如何使用备份。你可能会更喜欢RMAN。RMAN可以自动完成许多备份与恢复操作。而且,掌握手动备份与恢复数据库的知识可以帮助你从备份技术的角度思考疑难问题。
为没有处于归档日志模式的数据库实现冷备份策略
在数据库关闭后可以通过复制文件执行用户管理冷备份。这种备份也称为脱机备份。在进行冷备份时,数据库可能处于归档日志模式或者非归档日志模式。
DBA习惯将冷备份视为备份非归档日志模式数据库的同义词。这种观点是不正确的。可以对处于归档日志模式的数据库进行冷备份,而且许多公司都在使用的备份策略。
冷备份非归档模式数据库
冷备份非归档模式数据库的一个主要作用,是可以将数据库恢复到过去的某个时间点。只应在不需要在备份创建后执行的事务的情况下使用这种备份。只有在业务需求允许损失数据和出现停运时间的情况下,才能使用这种备份和恢复策略。产品数据库极少使用这种备份与恢复解决方案。
话虽如此,实现这种备份也有一些充分理由。一种常见用法是冷备份开发/测试/培训数据库,定期将数据库重置回某个点。这可以通过数据库的时间点快照,重启性
能测试和培训会话。
备份数据库中所有关键文件的方法
这些文件包括所有控制文件,数据文件,临时数据文件和联机重做日志文件。这种备份可以将数据库重置为创建该备份时的时间点。该方法的主要有点事概念简单并易于实现。下面是冷备份非归档日志模式数据库的具体步骤:
1.确定存储备份文件的位置和空间
2.找到需要复制的数据库文件
3.使用IMMEDIATE,TRANSACTIONAL或NORMAL子句关闭数据库
4.将文件(步骤2中找到的)复制到备份位置(步骤1确定的)
5.重启数据库
确定存储备份文件的位置和空间
在理想情况下,备份的数据库文件应该存储在活动的数据库文件不同的硬盘中。然而,许多公司没有做到这一点的条件,只能让备份数据库公用挂载点。本例数据库备份位置为/u02/backup/test。
大致估算备份文件所需要的空间
select sum(sum_bytes)/1024/1024||'M' my_bytes from (
select sum(bytes) sum_bytes from v$datafile
union all
select sum(bytes) sum_bytes from v$tempfile
union all
select (sum(bytes) * members )sum_bytes from v$log
group by members );
Linux/Unix的df命令可以查看多少可用空间。应该保证OS提供的磁盘空间大于上面查询语句获得结果的总和:
找到需要复制的数据库文件
select 'cp '||name||' /u02/backup/test/' from v$datafile
union all
select 'cp '||name||' /u02/backup/test/' from v$controlfile
union all
select 'cp '||name||' /u02/backup/test/' from v$tempfile
union all
select 'cp '||member||' /u02/backup/test/' from v$logfile;
关闭数据库
使用SYS用户连接数据库,然后使用IMMEDIATE/TRANSACTIONAL或者NORMAL子句关闭数据库。IMMEDIATE子句通常是首选方法,该子句可以判断用户的连接,回滚未
完成的事物,然后关闭数据库:
sqlplus / as sysdba
SQL> shutdown immediate;
创建备份文件
使用OS试用程序将步骤2中找到的所有文件,复制到备份目录(步骤1确定的)。将所有数据文件、控制文件、临时文件和联机重做日志都复制到同一目录中。
$ cp /u01/*.* /u02/backup/test
重启数据库
复制了所有文件后,重新启动数据库:
sqlplus / as sysdba
SQL> startup
使用含有联机重做日志的冷备份恢复
下面的例子介绍了使用非归档日志模式数据库的冷备份执行恢复操作的方法。如果你在冷备份中包含了联机重做日志,在恢复文件时也可以包含他们。
恢复过程步骤:
1.关闭数据库
2.将数据文件,联机重做文件,临时文件和控制文件,复制回存储数据库文件的位置;
3.启动数据库
关闭数据库
如果数据库正在运行就关闭它。在这种情况下,关闭数据库的方式无关紧要,因为这会将数据库恢复到过去的某个时间点。当复制会备份文件时,数据库目录的
所有文件都会被覆盖。如果数据库正在运行,可以直接终止它。使用SYSDBA权限用户运行下面命令;
sqlplus / as sysdba
SQL> shutdown immediate;
将备份文件复制会数据库目录中
这个步骤是备份的反向操作:将数据库文件从备份位置,复制会数据库目录:
$ cp /u02/backup/test/*.* /u01
启动数据库
sqlplus / as sysdba
SQL> startup;
冷备份处于归档日志模式的数据库
归档日志模式数据库的备份可以将数据库恢复到出现失效事件前的状态。因此,与备份非归档日志模式数据库不同,这种备份不是专门用于在别无选择的情况下,将互数据库重置回谋而时间点。备份归档日志模式数据库的目的通常是通过前滚应用事物彻底恢复数据库。
这对恢复具有重大意义。前面介绍过在备份非归档日志模式的数据库时,DBA有时会在备份中包含联机重做日志。在备份归档日志模式的数据库时,永远不应再备份中包含联机重做日志。联机重做日志中含有最近生成的重做事物信息。当前联机重做日志中含有还没有归档的所有事物,他们都是完全恢复必须的数据。在失效事件中,无需使用过去某时间点的联机重做日志覆盖当前的联机重做日志;否则会导致无法执行完全恢复。
冷备份归档日志模式数据库的步骤,与冷备份非归档日志模式数据库的步骤大致相同
1.确定存储备份文件的位置和空间;
2.找到需要备份的文件;
3.使用IMMEDIATE,TRANSACTIONAL或NORMAL子句关闭数据库
4.将文件(步骤2中找到的)复制到备份位置(步骤1确定的)
5.重启数据库
冷备份归档日志模式数据库与冷备份非归档日志模式数据库的主要差异在步骤2中。
只需要查找数据文件和控制文件:
select name from v$datafile
union all
select name from v$controlfile;
在冷备份归档日志模式数据库时,无需备份与临时表空间有关的数据文件。Oracle Database 10g出现后,Oracle已经能在数据库启动时,自动创建缺少的临时表空间
数据文件。
热备份策略
如前所述,执行任何类型(不论是联机还是脱机)的Oracle数据库备份操作都应该使用RMAN。RMAN比用户管理的备份更加高效,并且能够以自动方式完成大多数任务。
话虽如此,了解Oracle备份与恢复原理的最佳方法之一,还是手动创建热备份然后恢复数据库。热备份手动恢复数据库可以帮助你了解每种文件(控制文件,数据文件,
归档重做日志和联机重做日志)的作用。
创建热备份
下面是创建热备份的步骤:
1.确保数据库处于归档日志模式;
2.确定存储备份文件的位置:
3.找到需要备份的文件
4.记下联机重做日志的最大序列号;
5.将数据库/表空间更改为辈分模式
6.使用OS使用程序,将数据文件复制到步骤2确定的存储位置;
7.使数据库/表空间退出备份模式
8.归档当前联机重做日志,并记下联机重做日志的最大序列号
9.备份控制文件
10.备份在执行备份过程中生成的所有归档重做日志。
确保数据库处于归档日志模式
SQL> archive log list
下面输出结果表明数据库处于归档模式
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
确定存储文件的位置
本例确定的备份文件存储位置是/u02/backup/test。估算需要使用的空间:
select sum(bytes)/1024/1024||'M' from dba_data_files;
找到需要备份的文件
select name from v$datafile;
在执行表空间切换为备份模式时,就需要知道哪些数据文件与哪些表空间关联:
select tablespace_name,file_name from dba_data_files order by 1,2;
记下练级重做日志的最大序列号
要使用热备份恢复数据,需要备份所有归档重做日志。因此,在执行热备份前需要记下归档日志的序列号:
select thread#,max(sequence#) from v$log group by thread# order by thread#; --67
将数据库/表空间更改为备份模式
SQL> alter database begin backup;
在处理活动的OLTP数据库时,这样做会大幅度降低性能。这是因为当表空间切换为备份模式时,Oracle会将所有数据块(在第一次修改时)的完整镜像复制到重做流
中。
另一种处理方法是一次将表空间切换为备份模式。将表空间切换到备份模式后,可以复制相关数据库文件,然后使表空间退出备份模式。
SQL> alter tablespace tablespace_name begin backup;
使用OS使用程序复制数据库文件
cp /u02/datafile/*.dbf /u02/backup/test/
使数据库/表空间推出备份模式
alter database end backup ;
如果要逐个使多个表空间推出备份模式,需要在复制了每个表空间的数据文件后推出备份模式:
SQL> alter tablespace tablespace_name end backup;
如果你没有使用表空间推出备份模式,就会严重降低数据库的性能和可用性。
验证表空间退出了备份模式(没有文件处于ACTIVE状态)
alter session set nls_date_format='DD-MON-RRRR HH24:MI:SS';
seslect * from v$backup where status='ACTIVE';
归档当前联机重做日志,并记下联机重做日志的最大序列号。
下面命令可以使Oracle归档所有还未归档的联机重做日志并执行日志切换。这可以确保将备份结束标记写入归档重做日志:
SQL> alter system archive log current;
还应记下联机重做日志的最大序列号。如果在热泵欸分后立刻出现失效时间,需要使用热备份过程中生成的所有归档重做日志,完全恢复数据库:
select thread#,max(sequence#) from v$log group by thread# order by thread#;
备份控制文件
在进行热备份时,无法使用OS复制命令备份控制文件。Oracle的热备份过程必须使用ALTER DATABASE BACKUP CONTROLFILE 语句。
SQL> alter database backup controlfile to '/u02/backup/controlbk.ctl' reuse;
REUSE子句可以使Oracle使用新备份文件覆盖存储位置中已经存在的同名文件。
备份在执行备份过程中生成的所有归档重做日志
cp
这样做可以确保在热备份完成后立刻出现失效事件时,也有可用的日志。应确保没有备份当前正在由归档进程写入的归档重做日志,避免使用备份文件不完整。
有时DBA会使用脚本通过V$ ARCHIVED_LOG视图的RESETLOGS_ID列获取最大序列号执行该存储过程。当完成归档重做日志写入磁盘的操作后,Oracle会自动更新该视图。
因此,V$ ARCHIVED_LOG视图中含有所有的所有归档重做日志文件都是可以备份的。
使用脚本执行热备份
在产品数据库环境中,创建热备份的脚本相当复杂。此处介绍的脚本提供了热备份脚本的基础框架。如果你要在自己的环境中使用下面的代码,需要修改以下变量:
ORACLE_SID;ORACLE_HOME;hbdir
OS变量ORACLE_SID定义了数据库的名称。OS变量ORACLE_HOME定义了Oracle的安装目录。SQL*Plus变量hbdir指定热备份的存储位置:
#!/bin/bash
ORACLE_SID=orcl
ORACLE_HOME=/u01/app/product/12.1/db_1
PATH=$PATH:$ORACLE_HOME/bin
#
sqlplus -s <<EOF
/ as sysdba
set head off pages0 lines 132 verify off feed off trimsp on
define hbdir=/u02/backup/test
spool hotback.sql
select 'spo &&hbdir/hotlog.txt' from dual;
select 'select max(sequence#) from v\$log;' from dual;
select 'alter database begin backup;' from dual;
select '!cp ' || name ||' ' ||'&&hbdir' from v\$datafile;
select 'alter database end backup;' from dual;
select 'alter database backup controlfile to '|| '''' || '&&hbdir'
||'/controlbk.ctl'||''''||' reuse;' from dual;
select 'alter system archive log current;' from dual;
select 'select max(sequence#) from v\$log;' from dual;
select 'select member from v\$logfile;' from dual;
select 'spo off;' from dual;
spo off;
@@hotback.sql
EOF
了解数据文件的更新情况
有些DBA认为:'锁定了数据文件的头部以为和无法更改数据文件。'Oracle确实回通过锁定这些SCN,表名开始对数据文件执行热备份操作,而且表空间推出备份模
式前不会更新这些SCN。锁定这些SCN并不意味着在备份过程中,不向数据文件中写入数据块。
查明在备份过程中数据文件会被写入数据
1.将表空间切换为备份模式:
alter tablespace users begin backup;
2.创建表
create table test_cc(cc varchar2(50)) tablespace users;
3.向该表中插入字符串
insert into test_cc values ('DBWR does write');
4.强制执行检查点(确保将所有已修改的缓存内容写入磁盘):
alter system checkpoint;
5.在OS界面中,使用string和grep命令收缩数据文件中的字符串
strings /u02/datafile/users.dbf |grep "DBWR does write"
6.下面是输出结果,表名数据库写进程确实向磁盘写入了数据:
DBWR does write
7.使表空间退出备份模式:
alter tablespace users end backup;
处于归档重做日志模式的数据库执行完全恢复
术语完全恢复意味着可以恢复在失效时间出现前已提交的所有事务。完全恢复并不意味着彻底恢复整个数据库。例如,如果仅有一个数据文件出现了介质失效时间,只需对唯一受损的数据文件执行完全恢复。
执行下面的步骤可以备份任何处于归档日志模式的数据库。这些步骤既可以创建冷备份也可以创建热备份。当数据库处于归档日志模式时,使用这两种备份文件恢复数据库文件的步骤是相同的。要执行完全恢复:
1.必须能够在数据文件中介质失效情况时恢复它们;
2.必须能够访问上次备份操作完成后,生成的所有归档重做日志。
3.必须有完整的联机重做日志。
下面是执行完全恢复的基本过程
1.将数据库启动到mount模式,这可以防止用户事务进程对要恢复 的数据文件执行读/写操作。(如果你不是恢复SYSTEM或UNDO表空间,可以在恢复数据文件前打开数据库并通过手动操作使数据文件脱机。在这样做时,应确保在恢复操作完成后,使数据文件重新联机。)
2.使用OS复制实用程序恢复受损的数据文件。
3.执行SQL*Plus的RECOVER命令,可以应用归档重做日志和联机重做日志中的信息。
4.打开数据库
在脱机情况下恢复数据库
创建一个表并插入数据,在完全恢复过程的末尾会通过选择这个表和数据,以表明成功执行了恢复操作:
创建测试表并插入数据
create table backup_test (a number) tablespace users;
insert into backup_test values (1);
commit;
将联机重做日志多切换几次。这样确保可以在恢复过程中应用重做日志
alter system switch logfile;
重命名与USERS表空间关联的数据文件,模拟介质失效情况。
查找数据文件
select file_name from dba_data_files where tablespace_name='USERS';
使用OS命令重命名该文件
mv /u02/datafile/users.dbf /u02/datafile/users.dbf.old
尝试关闭数据库
sqlplus / as sysdba
SQL>shutdown immediate;
系统会显示下面的错误:
SQL> shutdown immediate;
ORA-01116: error in opening database file...
真正处理这类故障时,最好切换到数据文件目录,查看出问题的数据文件是否位于正确位置。还应检查alert.log文件,看Oracle是否在其中正确的记录了相关信息。
上面的例子模拟了介质失效事件,执行下列步骤可以完全恢复这个故障。
1.将数据库启动到mount模式
sqlplus / as sysdba
SQL>shutdown abort;
SQL>startup mount;
2.使用备份恢复数据文件
cp /u02/backup/test/users.dbf /u02/datafile/users.dbf
仔细检查启动数据库时Oracle执行的操作。当你执行ALTER DATABASE OPEN 语句时,Oracle会在控制文件中检查所有数据文件的SCN。
查询V$DATAFILE视图可以查看这些SCN;
SQL> select checkpoint_change# from v$datafile where file#=7;
CHECKPOINT_CHANGE#
------------------
5966590
Oracle会比较控制文件中的SCN与数据文件头部的SCN。通过V$DATAFILE_HEADER视图可以查看数据文件头部的SCN
select file#,fuzzy,checkpoint_change# from v$datafile_header where file#=7;
FILE# FUZZY CHECKPOINT_CHANGE#
---------- --------- ------------------
7 YES 5946096
注意:在这种情况下V
D
A
T
A
F
I
L
E
H
A
D
E
R
视
图
中
记
录
的
S
C
N
比
V
DATAFILE_HADER视图中记录的SCN比V
DATAFILEHADER视图中记录的SCN比VDATAFILE视图中记录的SCN少。如果你尝试打开数据库,Oracle就会显示需要执行介质恢复的错误提示(这意味着需要应用重做日志中的信息),使数据文件中的SCN与控制文件中的SCN同步。V$DATAFILE_HEADER视图的FUZZY列呗设置为YES。这表明使用数据文件前。必须
对数据文件应用重做日志。
下面是打开数据库会出现的状况:
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01113: file 4 needs media recovery ...
ORA-01110: datafile 7: '/u02/datafile/users.dbf'
在数据文件头部的所有SCN与控制文件中的SCN匹配前,Oracle不会允许你打开数据库。
3.执行适当的RECOVER语句
归档重做日志和联机重做日志,含有将数据文件中SCN添加到控制文件中所需的信息。执行下列SQL*Plus语句之一,可以对需要执行介质恢复的数据文件应用重做日志。
1.RECOVER DATAFILE
2.RECOVER TABLESPACE
3.RECOVER DATABASE
因本例中仅需要恢复一个数据文件,所以使用RECOVER DATAFILE语句最合适。然而你也可以运行上述语句中的任意一个,Oracle会自动找到需要恢复的数据文件。在
这种情况下,你会发现记忆含有需要恢复的数据文件的表空间名称,比记忆数据文件的名称更加容易。
恢复USERS表空间中的所有数据文件:
SQL>recover tablespace users;
如果只需要使用归档重做日志中含有的信息,Oracle会提示你应该先应用那个归档重做日志:
ORA-00279: change 5946096 generated at 04/13/2018 10:54:54 needed for thread 1
ORA-00289: suggestion: /u02/fra/ORCL/archivelog/2018_04_13/o1_mf_1_69_ff0752bp_.arc
ORA-00280: change 5946096 for thread 1 is in sequence #69
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
按Enter或Return可以使Oracle应用它推荐的归档重做日志文件,设置文件名和AUTO命令,可以使Oracle自动应它推荐的归档重做日志文件,输入CANCEL命令可以停止
恢复过程。
本例使用了AUTO命令。Oracle会应用所有归档重做日志和联机重做日志文件中的信息,执行完全恢复操作:
AUTO
4.打开数据库
SQL>alter database open;
验证在介质失效时间前提交的事务是否已经恢复:
SQL> select * from backup_test;
A
----------
1
恢复联机数据库
如果SYSTEM和UNDO表空间之外的其他表空间的数据文件失效了,可以在使用数据库保持联机的状态下恢复受损的数据文件。要做到这一点,必须先使需要恢复的数据文
件脱机。
用户在数据文件失效的情况中更新表时,系统会显示下列错误提示:
insert into backup_test values (2);
ORA-01116:error in opening database file ...
可以先切到OS目录,并确定数据文件没有被系统管理员误删。
本例使USERS表空间的数据文件脱机,然后在数据库处于联机状态时恢复它。先使这个数据文件脱机:
SQL>alter tablespace users offline;
从备份出恢复该数据文件
cp /u02/backup/test/users.dbf /u02/datafile/users.dbf
在这种情况下,无法使用RECOVER DATABASE语句。RECOVER DATABASE语句会恢复数据库中数据库中的所有数据文件,其中包括SYSTEM表空间。当数据库处于联机状态时,
无法恢复SYSTEM表空间。如果你使用RECOVER TABLESPACE语句,就必须先使与表空间关联的所有数据文件都脱机。在本例这类情况中,更合适执行数据文件级的恢复操作:
SQL>recover datafile '/u02/datafile/users.dbf';
恢复成功后,就可以使用数据文件重新联机:
alter database datafile '/u02/datafile/users.dbf' online;
恢复控制文件
在用户管理的备份操作中,通常会在下列情况中恢复控制文件:
1.控制文件被损坏,并且被多路复用;
2.所有控制文件都损坏了
1.恢复受损的多路复用控制文件
如果为数据库配置了一个以上的控制我呢间,可以关闭数据库并使用OS命令将现存的控制文件复制到缺失控制文件的位置。
SQL> show parameter control_files;
NAME TYPE VALUE
------------------------------------ --------------------------------- --------------------------------
control_files string /u01/control_file/control02.ctl,
/u02/controlfile/control01.ctl
control02.ctl文件损坏了。当你查询数据字典目录时,Oracle就会显示下列错误提示:
ORA-00210:cannot open the specified control file ...
其他控制文件未被损坏时,可以关闭数据库,移动旧/损坏的控制文件(保留他们,以便将来分析问题来源),并通过移动和重命名现存的正常控制文件执行恢复操作:
SQL>shutdown abort;
mv /u01/control_file/control02.ctl /u01/control_file/control02.ctl.old
cp /u02/controlfile/control01.ctl /u01/control_file/control02.ctol
重启数据库
SQL>startup
这种方式可以使用现存的控制文件恢复受损的控制文件。
–在所有控制文件都损坏时执行恢复操作
如果所有控制文件都失效了,可以通过备份恢复它们,也可以重新创建控制文件。如果你拥有所有的数据文件和必需的重做日志(归档重做日志和联机重做日志),
可以对数据库执行完全恢复。具体步骤:
1.关闭数据库
2.通过备份恢复控制文件
3.将数据库启动到mount模式。使用RECOVER DATABASE USING BACKUP CONTROLFILE 子句执行恢复数据库的操作;
4.在执行完全恢复时,手动应用联机重做日志
5.使用OPEN RESETLOGS子句打开数据库
数据库的所有控制文件都被误删除了,Oracle显示了下面的错误提示:
ORA-00210:cannot open the specified control file...
1.关闭数据库
SQL>shutdown abort;
2.使用备份恢复控制文件
cp /u02/backup/test/controlbk.ctl /u01/control_file/control02.ctl
cp /u02/backup/test/controlbk.ctl /u02/controlfile/control01.ctl
3.将数据库启动到mount模式,并执行恢复数据库的操作
SQL>start mount
复制了正常的控制文件和数据文件后,就可以执行恢复操作了。Oracle可以识别出通过备份(因为这是使用ALTER DATABASE BACKUP CONTROLFILE语句创建的)复制
的控制文件,此时必须使用USING BACKUP CONTROLFILE子句执行恢复操作:
SQL>recovre database using backup controlfile;
ORA-00279: 更改 5946185 (在 04/13/2018 10:52:46 生成) 对于线程 1 是必需的 ORA-00289:
建议: /u02/fra/ORCL/archivelog/2018_04_13/o1_mf_1_69_ff0752bp_.arc
ORA-00280: 更改 5946185 (用于线程 1) 在序列 #69 中
指定日志: {<RET>=suggested | filename | AUTO | CANCEL}
输入AUTO命令可以使用Oracle自动应用所有归档重做日志:
AUTO
恢复过程会应用所有可用的归档重做日志。恢复过程无法确定归档重做流的终点,因而会尝试用不存在的归档重做日志,导致系统现实下列的错误:
ORA-00279: 更改 5946194 (在 04/13/2018 10:57:38 生成) 对于线程 1 是必需的 ORA-00289:
建议: /u02/fra/ORCL/archivelog/2018_04_17/o1_mf_1_70_ffcfwlxh_.arc
ORA-00280: 更改 5946194 (用于线程 1) 在序列 #70 中 ORA-00278:
此恢复不再需要日志文件 '/u02/fra/ORCL/archivelog/2018_04_13/o1_mf_1_69_ff0752bp_.arc'
上述信息是正常提示。此时你尝试打开数据库:
alter database open resetlogs;
Oracle会显示下列错误提示:
第 1 行出现错误:
ORA-01113: 文件 1 需要介质恢复
ORA-01110: 数据文件 1: '/u02/datafile/system.dbf'
4.应用联机重做日志
Oracle需要应用更多重做日志,才能使控制文件中的SCN与数据文件头部的SCN同步。在这种情况中联机重做日志文件仍旧完整无缺,并含有必须的重做信息。要
应用联机重做日志中的重要信息,应先找到联机重做日志文件:
select a.sequence#,a.status,a.first_change#,b.member from v$log a,v$logfile b where a.GROUP#=b.GROUP# order by a.SEQUENCE#;
SEQUENCE# STATUS FIRST_CHANGE# MEMBER
---------- -------------- --------------- -------------------------------------------------------------------------
66 INACTIVE 5661501 /u02/redofile/redulog04b.rdo
66 INACTIVE 5661501 /u02/redofile/redulog04a.rdo
67 INACTIVE 5695672 /u01/app/oradata/ORCL/onlinelog/o1_mf_2_f1zl3tv5_.log
67 INACTIVE 5695672 /u01/app/fast_recovery_area/orcl/ORCL/onlinelog/o1_mf_2_f1zl437t_.log
68 INACTIVE 5898613 /u01/app/fast_recovery_area/orcl/ORCL/onlinelog/o1_mf_3_f1zl4ly5_.log
68 INACTIVE 5898613 /u01/app/oradata/ORCL/onlinelog/o1_mf_3_f1zl4j1p_.log
69 CURRENT 5946003 /u01/app/oradata/ORCL/onlinelog/o1_mf_1_f1zl3ttp_.log
69 CURRENT 5946003 /u01/app/fast_recovery_area/orcl/ORCL/onlinelog/o1_mf_1_f1zl425o_.log
再次执行恢复过程
SQL>recover database using backup controlfile;
在执行恢复过程时,Oracle会提示归档重做日志不存在:
recover database using backup controlfile;
ORA-00279: 更改 6525256 (在 04/24/2018 14:52:12 生成) 对于线程 1 是必需的 ORA-00289:
建议: /u02/fra/ORCL/archivelog/2018_04_25/o1_mf_1_83_%u_.arc
ORA-00280: 更改 6525256 (用于线程 1) 在序列 #83 中
指定日志: {<RET>=suggested | filename | AUTO | CANCEL}
应输入当前联机重做日志文件的名称(可能必须猪哥尝试联机重做日志文件,知道找到Oracle需要的那个为止),而不是输入归档重做日志文件的名称。这会使恢
复过程应用联机重做日志文件中的所有重做信息:
应用了正确的联机重做日志后,系统会显示下列提示信息:
Log applied.
Media recovery complete.
5.使用RESETLOGS子句打开数据库
数据库已经完全恢复。然而,因为恢复过程中使用了一个备份的控制文件,所以必须在打开数据库时使用RESETLOGS子句:
SQL>alter database open resetlogs;
–处于归档日志模式的数据库执行不完全恢复
不完全恢复是指不回复失效时间出现前提交的所有事务。通过这种恢复操作,可以将数据库恢复到过去的某个时间点,但会失去失效事件出现前提交的事务。所以
不完全恢复也称为数据库时间点恢复。
不完全恢复并不意味着仅恢复部分数据文件。实际上,在大多数不完全恢复情况中,必须通过备份恢复所有数据文件。如果你不想恢复所有数据文件,就需要先使
不参与不完全恢复过程的数据文件脱机。在执行恢复操作时,Oracle仅会恢复在V$DATAFILE_HEADER视图中STATUS列的值为ONLINE的数据文件。
下面是需要执行不完全恢复的原因:
1.在执行完全恢复时缺少必需的归档重做日志或联机重做日志;
2.仅需要使数据库恢复到用户错误操作(删除数据,删除表等)前的某个时间点
3.测试环境中含有数据库基点副本,完成测试后需要将数据库重置回基点,以便进行下一轮测试。
–可以通过三种方式执行用户管理的不完全恢复操作
1.用户控制的恢复
2.基于SCN的恢复
3.基于时间的恢复
使用用户控制的恢复,可以应用归档重做日志并根据归档重做日志文件停止恢复过程。例如,如果在恢复数据库时缺少某个归档重做日志,就必须在应用了最后一个
良好的归档重做日志后停止恢复过程。可以使用RECOVER DATABASE语句和CANCEL子句,执行用户控制的恢复:
SQL>recover database until cancel;
如果想要恢复到特定的SCN号,可以根据SCN的恢复。可以通过告警日志或LogMiner的输出结果确定需要恢复到的SCN序列号。UNTIL CHANGE子句可以执行不完全恢复
操作:
SQL>recover database until scn 12345;
如果知道停止恢复过程的时间,可以用基于时间的恢复。例如,可能知道删除表的时间并想将数据库恢复到特定的时间点。基于时间恢复的时间格式永远都是
YYYY-MM-DD HH24:MI:SS .
SQL>recover database until time '2016-01-01 00:00:00';
在执行不完全恢复时,必须恢复所有将联机的数据文件。下面是不完全恢复的步骤:
1.关闭数据库
2.通过备份恢复所有的数据文件
3.将数据库启动到mount模式
4.应用重做日志(前滚)将数据库恢复到某个时间,并停止恢复过程(使用用户控制的恢复、基于SCN的恢复或基于时间的恢复)
5.使用OPEN RESETLOGS子句打开数据库。
关闭数据库:
SQL>shutdown immediate;
复制备份的所有数据文件。
cp /u02/backup/test/system01.dbf /u02/datafile/system01.dbf
cp /u02/backup/test/sysaux01.dbf /u02/datafile/sysaux01.dbf
cp /u02/backup/test/undotbs01.dbf /u02/datafile/undotbs01.dbf
cp /u02/backup/test/users01.dbf /u02/datafile/users01.dbf
复制了备份的数据文件后就可以恢复过程了。
sqlplus / as sysdba
SQL>startup mount
SQL>recover database until time '2017-01-01 00:00:00';
应用重做日志将数据库恢复到你想要的时间点。然后输入CANCEL命令:
CANCEL
这样做可以停止恢复过程,然后就可以用RESETLOGS子句打开数据库
SQL>alter database open resetlogs;