1 手工完全恢复

1.1 完全恢复的步骤

执行用户管理的数据库完全恢复：概览
用户管理的数据库完全恢复：
 将数据库恢复到最新的SCN

可以一次处理整个数据库，也可以一次处理一个数据文件或表空间
需要当前控制文件
需要有待恢复的所有文件的备份
需要到目前为止的所有归档日志。

完全恢复过程

（1）restore： OS拷贝命令还原所有或部分datafile
（2）recover：SQL*PLUS利用归档日志和当前的redo日志做恢复

1.1.2 完全恢复可以基于三个级别

recover database所有数据文件损坏，或包括大部分datafile丢失，一般在mount状态完成
recover tablespace非关键空间损坏，表空间某些数据文件不能访问，一般在open下完成
recover datafile 单一或少数数据文件损坏，可以在mount或open状态完成。

1.1.3 什么是关键字

如果关键文件损坏，数据库将不能维持在open状态，或者奔溃或死机
关键文件：①system01 file，②undotbs file，③control file，④current log

1.1.4 恢复过程可以查看的视图

（1）vrecover_file 查看需要恢复的datafile （2）vrecovery_log 查看recover需要的redo日志
（3）varchived_log 查看已经归档的日志 SQL> select file#,error from vrecover_file;
SQL> select archive_name from vrecovery_log; 1.2 适用场景实验 有一套datafile全备，使用当前控制文件，自上次备份以来的归档日志和当前联机日志是完整的。 recover恢复要用到redo日志，归档日志，模拟故障实验时不要删除日志。 1.2.1 recover database 所有大部分数据文件损坏，mount或open下进行恢复。如果system01.dbf损坏，只能mount下恢复。 OS:使用cp还原受损的dbf（不一定是全部，vrecover_file记录的都需要还原）
SQLPLUS：
①recover database;
②alter database open;

1.2.2 recover database实验

查看当前日志组
SQL> select group#,sequence#,status from v$log;

1.2.2.1创建测试表

建表、插入数据、提交、切日志组

SQL> create table test( id number);

Table created.

SQL> insert into test values(1);

1 row created.

SQL> commit 
  2  ;
切换日志
SQL> alter system switch logfile;

SQL> select group#,sequence#,status from v$log;
![图片.png](https://oss-emcsprod-public.modb.pro/image/editor/20230221-be778794-689c-4ec1-ad2c-56d959c5a925.png)
插入第二行，提交，不切日志组
SQL> insert into test values(2);

1 row created.

SQL> commit;

Commit complete.
插入第三行，不提交
SQL> insert into test values(3);

1 row created.

1.2.2.2 模拟介质故障，删除所有.dbf数据文件

SQL> shutdown abort    
ORACLE instance shut down.

模拟掉电引起实例故障，介质故障。
[oracle@primary ~]$ cd /oracle/app/oracle/oradata/oracle/

删除所有数据文件，模拟介质损坏。
[oracle@primary oracle]$ rm *.dbf

1.2.2.3 database，报错！

SQL> startup
ORACLE instance started.

Total System Global Area 2455228416 bytes
Fixed Size                  2255712 bytes
Variable Size             620758176 bytes
Database Buffers         1811939328 bytes
Redo Buffers               20275200 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 1 - see DBWR trace file
ORA-01110: data file 1: '/oracle/app/oracle/oradata/oracle/system01.dbf'
SQL> select file#,error from v$recover_file;

SQL> select status from v$instance;

1.2.2.4 restore还原数据文件（转储）

[oracle@primary ~]$ cp /oracle/backup/oracle/cold/*.dbf /oracle/app/oracle/oradata/oracle/

1.2.2.5 open database报错

SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1: '/oracle/app/oracle/oradata/oracle/system01.dbf'

1.2.2.6 比较控制文件和数据文件头SCN

SQL> select file#,checkpoint_change# from v$datafile;

SQL> select file#,checkpoint_change# from v$datafile_header;

1.2.2.7 recover database恢复数据库

SQL> recover database;

需要使用归档，指定auto

SQL> select file#,checkpoint_change# from v$datafile;
SQL> select file#,checkpoint_change# from v$datafile_header;

可以看到scn已经一致了。
打开数据库

SQL> alter database open;
Database altered.

1.2.2.8 查看表中数据验证

SQL> select * from test;

插入3之后没有提交，因此表中只有1,2两条数据。

1.2.3 recover tablespace

（针对表空间的非关键数据损坏，一般是open下进行）
OS:使用cp还原该表空间xxx下的所有数据文件
SQLPLUS：
①alter tablespace XXX offline;
②recover tablespace XXX;
③alter tablespace XXX on
1.2.4 recover tablespace实验
（状态：database open）
针对的是非关键表空间的损坏，基于表空间的完全恢复实际上还是对其下的datafile的恢复。
模拟这种情形非常实用，通常是某个非关键表空间下的数据文件受损，但并没有造成Oracle奔溃，我们只需针对个别有问题的tablespace去做单独的在线恢复操作，也就是说恢复时数据库整体是online的，而局部表空间是offline的，数据库不需要shutdown。

恢复表空间（删除了tablespace下的所有的datafile）
1.2.4.1模拟表空间损坏
数据库open下，直接删除表空间下的数据文件

SQL> set pagesize 300
SQL> set linesize 300
SQL> select table_name,tablespace_name from user_tables where table_name='EMP';

[oracle@primary oracle]$ rm users01.dbf 
[oracle@primary oracle]$ pwd
/oracle/app/oracle/oradata/oracle

1.2.4.2 查证该表空间上的表不可访问了

清除data buffer

SQL> alter system flush buffer_cache;
System altered.

新开session登录，访问t1表，因为内存里已经清除了buffer块，只好去做物理读，所以报错！

SQL> select * from scott.emp;

1.2.4.3 查看scn的情况

SQL> select file#,checkpoint_change# from v$datafile;
SQL> select file#,checkpoint_change# from v$datafile_header;

1.2.4.4 将tset表空间offline

SQL> alter tablespace users offline;
alter tablespace users offline
*
ERROR at line 1:
ORA-01116: error in opening database file 4
ORA-01110: data file 4: '/oracle/app/oracle/oradata/oracle/users01.dbf'
ORA-27041: unable to open file
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3


SQL> alter tablespace users offline immediate;

Tablespace altered.

immediate 使表空间能立即脱机，不等Oracle对任何数据文件做检查

1.2.4.5 数据库open下，使用备份还原这个表空间下的所有数据文件

cp /oracle/backup/oracle/cold/users01.dbf /oracle/app/oracle/oradata/oracle/
[oracle@primary ~]$ ll /oracle/app/oracle/oradata/oracle/

1.2.4.6 恢复tablespace

SQL> recover tablespace users;
ORA-00279: change 1303637 generated at 02/09/2023 11:22:09 needed for thread 1
ORA-00289: suggestion : /oracle/arch/1_3_1128333462.dbf
ORA-00280: change 1303637 for thread 1 is in sequence #3


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
auto
ORA-00279: change 1303641 generated at 02/09/2023 11:27:36 needed for thread 1
ORA-00289: suggestion : /oracle/arch/1_4_1128333462.dbf
ORA-00280: change 1303641 for thread 1 is in sequence #4


Log applied.
Media recovery complete.

SQL> select file#,checkpoint_change# from v$datafile_header;

1.2.4.7 使表空间online

SQL> alter tablespace users online;
SQL> select file#,checkpoint_change# from v$datafile;

查看表空间以及状态

SQL> select tablespace_name,status from dba_data_files;
SQL> set pagesize 300
SQL> set linesize 300
SQL> select * from scott.emp;

1.2.5 recover datafile

(单个或几个数据文件损坏，关键文件在mount下进行，非关键文件在open下进行）
第一种情形
OS：使用cp还原相关的关键数据文件（mount）
SQLPLUS：
①recover datafile 6,8;
②alter database open;

第二种情形
OS：使用CP还原相关的非关键数据文件（open）
SQLPLUS：
①alter database datafile 6,8 offline;
②recover datafile 6,8;
③alter database datafile 6,8

1.2.6 recover datafile实验

（datafile mount或open状态）
恢复datafile，同范2不同的是模拟undo文件损坏：因undo数据文件也是关键文件，所以只能在mount状态下恢复。

1.2.6.1 模拟环境：插入数据提交，删除数据不提交

SQL> conn scott/tiger
SQL> truncate table emp;

Table truncated.
SQL> insert into test values(1);
SQL> insert into test values(2);
SQL> select * from test;

        ID
----------
         1
         2

删除test表中数据，不提交。老值在undo里。

SQL> delete from test;

2 rows deleted.

1.2.6.2 shutdown abort关闭数据库，删undotbs.dbf

SQL> shutdown abort
ORACLE instance shut down.

删除undotbs.dbf
[oracle@primary oracle]$ rm undotbs01.dbf

1.2.6.3 启动数据库到mount状态

SQL> startup
ORACLE instance started.

Total System Global Area 2455228416 bytes
Fixed Size                  2255712 bytes
Variable Size             620758176 bytes
Database Buffers         1811939328 bytes
Redo Buffers               20275200 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 3 - see DBWR trace file
ORA-01110: data file 3: '/oracle/app/oracle/oradata/oracle/undotbs01.dbf'
SQL> select file#,error from v$recover_file;

1.2.6.4 转储（还原）undo数据文件

[oracle@primary oracle]$ cp /oracle/backup/oracle/cold/undotbs01.dbf ./
[oracle@primary oracle]$ ll

1.2.6.5 恢复undo数据文件

SQL> recover datafile 3;
ORA-00279: change 1303637 generated at 02/09/2023 11:22:09 needed for thread 1
ORA-00289: suggestion : /oracle/arch/1_3_1128333462.dbf
ORA-00280: change 1303637 for thread 1 is in sequence #3


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
auto
ORA-00279: change 1303641 generated at 02/09/2023 11:27:36 needed for thread 1
ORA-00289: suggestion : /oracle/arch/1_4_1128333462.dbf
ORA-00280: change 1303641 for thread 1 is in sequence #4


Log applied.
Media recovery complete.

打开数据库

SQL> alter database open;

1.2.6.7 验证（会完成undo表空间数据的回滚）

SQL> select * from test;