Oracle 备份恢复详

怼烎@ 2022-08-05 15:19 312阅读 0赞

一、备份方式：  
1、在非归档模式下，只能做冷备份  
2、在归档模式，可以使用热备份，也可以做冷备份。（数据文件 控制文件 临时文件 在线日志文件)  
  
二、冷备份  
(每周做一次)  
1、首先得关闭数据库  
2、然后将所有文件拷贝到备份的文件夹中。  
临时文件和在线日志文件可以不拷贝。但是在线日志文件拷贝和不拷贝的差别是很大的，使用冷备份的时候只是备份的一个时间点的内容，在还原的时候就只还原到当前状态。在只有数据文件和控制文件的时候数据一致性是可以保证的。但是数据库是不能立马开启的，需要把在线日志文件修复  
3、修复在线日志文件  
在mount模式下  
>  recover database until cancel/scn;  （基于用户干涉/SCN号）  
在控制文件和数据文件的头部都有一个SCN号  这两个一致的时候就不需要进行修复  
4、开启数据库  
>alter database open resetlogs;  
  
  
三、热备份  
1.必要条件：数据库必须出于归档模式  
查看是否出于归档模式  
> archive log list;  
  
2.热备份：做热备一般会对数据库做热备份  
基于表空间的热备份  
>  alter tablespace tablespace\_name begin backup;  
然后去物理上进行拷贝，只要拷贝dbf文件就行

>  alter tablespace tablespace\_name end backup;

PS：begin和end之间的时间越短，产生的日志量越少，所以建议使用一个数据库一个数据库的备份。如果在begin和end之间数据库挂了，则会进行报错，这个时候就需要进行介质恢复

相关指令：查看有哪些表空间  
>  desc dba\_tablespaces  
>  select tablespace\_name from dba\_tablespaces  
  
  
3.控制文件备份  
不需要进行关闭数据库,在数据库结构变化的时候需要备份  
比如增加表空间了,增加用户组等等,只要是数据结构变化了就需要备份。  
  
可以使用二进制文件的形式备份  
>  alter database backup controlfile to '/tmp/control.bak';  
  
还可以使用sql脚本的形式来备份

>  alter database backup controlfle to trace as '/tmp/control.sql' ;

这个不是备份控制文件，而是记录把这个空间文件重新建立所需要的操作，重新在建立的时候可以修改一些原本固定的参数  
这里面的语句分为noresetlogs和resetlogs，在可以使用no的时候尽量使用no  
使用no的前提：仅仅是控制文件丢失了，但是在线日志文件仍旧存在  
  
  
4.参数文件和密码文件，都是可以备份，可以不备份，直接CP就行  
  
  
四、恢复  
尽量做完全恢复，对数据库的影响小

完全恢复：

1.在归档模式下

2.需要备份文件+归档日志+在线日志

不完全恢复：在线日志文件丢失了或者归档日志文件有断层（不全）或者控制文件完全损坏  
      对于不完全恢复，启动的时候不能直接启动，而是需要加参数resetlogs  
      resetlogs会进行把日志序列重置，重建在线日志文件等操作，加这个选项必须是在不完全恢复的前提下

不完全恢复的种类：

1、基于用户干涉  可能归档文件和在线日志是全的，而用户要求到这一点停止

2、基于时间的   还原到误删除的状态  
3、SCN  在数据库中有函数可以把SCN和时间之间进行转换  
dbms\_flshback：里面有将SCN和时间进行转换的函数  
  
实例恢复：实例恢复是oracle会自行进行的，是逻辑错误  
  
介质恢复：需要DBA介入进行恢复，是文件损坏，会报如下错误  
ORA-01113:FILE 7 NEED MEDIA RECOVERY  显示的是7号文件出错  
如果是在对system表空间进行备份的时候关闭 则是报1号文件错误  
>  shutdown abort;  
>  desc v$backup;  
>  selecct \* from v$backup;  
>  startup mount;  
>  alter tablespace test2 end backup;  
>  alter database open;  
  
恢复数据库  
system01.dbf被删除的的时候  
>  recover datafile 1;  
>  alter database open;  
  
  
非系统表空间归档模式下的完全恢复  
一、在数据库开启的情况下  
1.1：场景模拟  
>  alter database archivelog;    
>  create tablespace test datafile '/u01/app/oracle/oradata/dodo/test01.dbf' size 10M;  
>  create user test identified by test defult tablespace test;  
>  grant connect,resource to test;  
>  conn test/test;  
>  create table t;  
>  commit;  
>  conn / as sysdba  
>  alter tablespace test begin backup;  
物理上拷贝相关文件  
>  alter tablespace test end backup;  
然后在物理上进行删除  
\#\#在这个时候查询还是能查出来，因为是从buffer cache中查询的，  
  有时候清空buffer cache还是不够，因而需要清空所有脏块  
>  alter system flush buffer\_cache;(清空buffer cache)  
>  alter system checkpoint;        (清空所有脏块)

>  select \* from v$recover\_file; (如果是正常的这里面应该是没有任何的文件的,但是我们删除了dbf文件，所以这里会显现7号文件OFFLINE)

1.2：恢复  
>  alter database datafile 7 offline ;        (针对某一个文件)  
>  restore datafile 7;  
然后把备份的文件拷贝过来  
>  recover datafile 7;  
>  select \* from v$recover\_file; (这里应该显示no rows selected)  
>  alter database datafile 7 online  
  
  
实际步骤：  
(1)将相应的表空间或者文件offline    
(2)进行restore  
(3)拷贝文件  
(4)进行recover  
(5)最后online  
  
  
二、在数据库关闭后发现出错的情况下  
前提：！！在没有备份的情况下进行完全恢复  
条件：不能是系统表空间，所有的归档文件都在，控制文件是最新的  
1.场景  
创建好了不去做备，直接删除  
同时要注意，必须是在revocer\_file里面能够查到才能进行  
下面两条指令是在sysdba中进行的  
>  alter system checkpoint;  
>  select \* from v$recover\_file;  
>  alter database create datafile '/u01/app/oracle/oradata/dodo/test01.dbf';   
>  recover datafile 6;  
>  alter database datafile 6 online;  
这个时候就可以了  
  
  
控制文件丢失  
1、如果控制文件没有完全丢失，则可以在其他控制文件复制一下就行  
2、控制文件的完全丢失在实际意义上都是完全丢失  
  
当备份成二进制文件时  
>  alter database backup controlfile to '/u01/control.bak';(首先先备份控制文件)  
物理上删除控制文件  
>  shutdown abort;   (这个时候理论上正常关机是关闭不了的)  
物理上拷贝控制文件  
$  cp control.bak /u01/app/oracle/oradata/dodo/control01.ctl  
$  cp control.bak /u01/app/oracle/oradata/dodo/control02.ctl  
$  cp control.bak /u01/app/oracle/oradata/dodo/control03.ctl  
$  sqlplus / as sysdba  
>  startup mount  
>  recover database using backup controlfile;          (告诉数据库现在的的控制文件是旧的)  
如果归档之前配置过，则可以选择AUTO就行  
/u01/app/oracle/oradata/dodo/redo02.log  
Log applied.  
Media recovery complete.  
可能会报错：则可能是损坏后时间太短，还没有来得及切换日志组；也有可能是控制文件旧的，找不到目前的组  
这个时候就需要选择filename  一个一个的去试用redo01.log redo02.log  redo03.log  
>  alter database open resetlogs;  
  
  
当备份成脚本时  
>  alter database backup controlfile to trace as '/u01/control.sql';  (备份控制文件)  
把脚本里面的内容拷贝过来    
$  rm -rf \*.ctl  
>  shutdown abort  
>  startup nomount  
>  @createctl  
这个时候创建的控制文件是最新的，并且数据库会自动切换到mount状态  
但是这个时候临时文件是不可用的，需要把脚本里面和临时文件有关的也要拷贝上或者运行一次  
>  desc V$database;  
>  select open\_mode from v$database;  
>  recover database;  
>  alter database open;  
  
控制文件和在线文件都丢失,resetlogs      
这个时候所有的文件都不一致了,原来是靠在线日志文件把控制文件拉到最新

冷备份,来保证控制文件和在线日志文件保持一次  
在物理上将控制文件和在线日志文件全部删除  
$  rm -rf \*ctl  
$  rm -rf \*log  
>  shutdown abort  
>  startup nomount  
$  rm -rf \*dbf  
把数据文件删除，然后再把冷备份的数据文件拷贝进去(因为在冷备份里面是一致性的)  
$  cp \*dbf /u01/app/oracle/oradata/dodo/  
>  @createctl(运行脚本将控制文件恢复)  
>  recover database using backup controlfile until cancel;  
然后接下来选择 auto  然后在运行一次 cancel  
>  alter database open resetlogs;  
这个只能恢复到归档的最新状态

场景：在数据库结构变化后，没有备份控制文件，这个时候控制文件丢失了，在老的控制文件里面是没有新的表空间，但事实中确实存在新的表空间，使用旧的控制文件来恢复

新建一个表空间

在物理上删除控制文件  
>  shutdown abort  
然后在物理上把三个都拷贝进去  
>  startup mount  
>  recover database using backup controlfile  
先auto   找不到再找redo  
>  desc v$datafile;  
>  select name from v$datafile；会发现一个不正常的文件  
>  alter database rename file '/home/oracle......' to '/home/xinming';  
>  recover database using backup controlfile;  
然后就会显示complete  
>  alter database open resetlogs;  
  
  
不完全恢复  
基于时间，基于用户干涉，基于SCN  
基于时间的：会丢数据，在迫不得已的情况下才进行  
比如删除了某个用户之类的，alter是有一个表格，可以在里面进行查找时间  
$ cd admin/xinming/bdump/  
> select to\_char(sysdate,'yyyy-mm-dd hh24:mi:ss')from dual;  
冷备和热备份不能跨多个生命周期，如果有resetlogs等操作需要重新备份  
>  drop user qq cascade;  
>  shutdown immediate;  
在物理上将现在的数据文件全部删除  
从冷备中将数据文件拷贝回来  
>  recover database until time '2015-03-04 11:46:00';  
这个是不完全恢复  
>  alter database open resetlogs;