介质恢复的原理是囊个回事

下面我来讲下手工热备的步骤嘛！！！
在热备过程中数据文件头SCN被锁定，此时不会有任何数据在写入数据文件，那么为什么还支持DML操作呢？那是因为数据的变化都写

入了重做日志文件中撒，当表空间结束备份模式时，会触发检查点恢复过程，将涉及到表空间的所有变化数据写入该表空间，提升数

据文件头部的SCN，使得控制文件和数据文件中记录的SCN一致。

实验：
select file_id,file_name,tablespace_name  from dba_data_files;--首先查看要备份的表空间 
D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\TEST.DBF

alter tablespace test begin backup;--开始设置备份模式状态

SQL> host copy D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\TEST.DBF  e:\test1.bak;--表空间以备份集的形式备份到e盘撒
已复制         1 个文件。

 select *  from v$backup;

 FILE# STATUS                CHANGE# TIME
------ ------------------ ---------- --------------
     1 NOT ACTIVE                  0
     2 NOT ACTIVE                  0
     3 NOT ACTIVE                  0
     4 NOT ACTIVE                  0
     5 NOT ACTIVE                  0
     6 NOT ACTIVE                  0
     7 ACTIVE                1741976 03-10月-13

--查看备份模式的状态

特别注意：为什么设置为备份模式表空间对应的数据文件的检查点SCN比其他几个文件的检查点要大，原因是一旦使用开始备份模式状

态就会触发检查点事件，刷新数据文件的文件头SCN，并冻结该SCN ，如果结束备份模式的话都一样了。

 

alter tablespace test end backup;--结束备份模式，千万要结束

alter system archive log current;--写入归档模式

select checkpoint_change#,file# from v$datafile;--此时的检查点都一致了
SQL> select checkpoint_change#,file# from v$datafile;

CHECKPOINT_CHANGE#      FILE#
------------------ ----------
           1742374          1
           1742374          2
           1742374          3
           1742374          4
           1742374          5
           1742374          6
           1742374          7

 

介质恢复的原理又是囊个一回事？？？
修复(restore)该操作的目的是使用备份的文件替换或丢失的文件，使用操作命令完成，将备份的文件复制到损坏的文件目录下。
恢复(recovery)是将归档的日志文件以及联机重做日志文件里的重做记录应用到还原出来的文件上。先restore，然后recovery。
在打开数据库的时候，oralce需要读取控制文件，并对控制文件以及数据文件中的SCN确定是否恢复，此时数据文件，控制文件，联机

重做日志文件必须同步，如果不同步需要恢复 ，SCN是基于时间的一个函数值，作为系统的时间戳，整个系统内的SCN是唯一的。

1.select name,checkpoint_change# from v$database;--查看系统检查点SCN
系统检查点SCN：当检查点进程启动时，会将检查点结束时间转化成SCN记录号记录在控制文件中，该检查点是全局范围内的，当发生

文件级别的检查点时，不会更新该系统检查点SCN。

2.select name,checkpoint_change#,last_change# from v$datafile;--查看数据文件检查点SCN和结束SCN
数据文件检查点SCN：当检查点进程启动时，包括全局范围内以及文件级别的(将表空间设置为只读、begin backup、offline等)，检

查点都会在控制文件里面记录每个数据文件上锁发生的检查点SCN.

数据文件结束SCN：每个数据文件都有一个结束SCN，在数据库正常运行期间，只要是在线的，可读写的数据文件，其结束SCN都为空，

而对正常关闭数据库时，或将数据文件正常离线，只读时，都会触发检查点进程，从而在控制文件里记录每个数据文件上的结束时的

SCN号。

3.select file#,checkpoint_change# from v$datafile_header;--查看数据文件头部检查点SCN
正常关闭数据库，每个数据文件的结束SCN都是一致的(只读，离线的除外)，在每个数据文件的头部，也记录了检查点SCN，该检查点

SCN与控制文件中记录的数据文件的检查点SCN是一致的，也就是说，全局范围内和数据文件级别的检查点，不仅会将检查点记录在控

制文件中，还会记录在数据文件的头部。

在数据库正常关闭时，会触发一个完全检查点，并用该检查点结束时的SCN号更新以上4个检查点SCN(除了离线和只读的),系统检查点

SCN,数据文件检查点起始SCN，数据文件检查点结束SCN，以及文件头部的SCN，如果他们不一致就需要实例恢复或者介质恢复给。
if 我们将被备份的控制文件覆盖当前的控制文件，这时控制文件比较旧，而数据文件是比较新的数据文件，因此数据库会发现控制文

件里面的SCN小于数据文件头部的SCN，要恢复。
if 备份的数据文件覆盖当前的数据文件，则数据库会发现记录在控制文件里面的数据文件检查点SCN号与备份中还原的数据文件的头

部的检查点SCN不一致，控制文件SCN比较新，备份中还原的数据文件头部的SCN比较旧，控制文件的SCN大于数据文件头部的SCN，数据

库不能打开，要求对还原的数据文件进行恢复，应用重做记录，从而将该数据文件头部的SCN提升到控制文件记录的SCN号。