要求归档模式
SQL> archive log list; Database log mode Archive Mode Automatic archival Enabled Archive destination USE_DB_RECOVERY_FILE_DEST Oldest online log sequence 14 Next log sequence to archive 16 Current log sequence 16 |
先看用户管理的热备份
看看下面这个关键的操作,将备份的内容置于backup模式,用户管理的联机热备份必需的操作,
不然copy备份的数据文件不能用来恢复,即使用某些放时恢复了也会丢数据
SQL> alter tablespace users begin backup; Tablespace altered. SQL> list 1 select d.file_name filename,d.tablespace_name ts_name,b.status 2 from dba_data_files d,v$backup b 3* where d.file_id=b.file# SQL> / FILENAME TS_NAME STATUS ---------------------------------------- ---------- ------------------ /u02/oradata/sales/system01.dbf SYSTEM NOT ACTIVE /u02/oradata/sales/undotbs01.dbf UNDOTBS1 NOT ACTIVE /u02/oradata/sales/sysaux01.dbf SYSAUX NOT ACTIVE /u02/oradata/sales/users01.dbf USERS ACTIVE /u02/oradata/sales/example01.dbf EXAMPLE NOT ACTIVE /u02/oradata/sales/perfstat.dbf PERFSTAT NOT ACTIVE |
USERS表空间现在处于backup模式,究竟这时候怎么了?
在我们alter tablespace users begin backup 的时候是
锁定了users表空间对应的数据文件头的change scn.
首先考虑一下数据库怎么用日志文件做恢复:查找不一致的数据文件(根据文件头中旧的scn)
如果锁定了文件头,这个文件头中的scn就不会改变(当然了数据块还是会变化的,还可以做读写)。
然后就会应用这个scn到现在的日志。那我锁定了scn,不管你后边怎么修改,
总之做恢复的时候是应用锁定的时候的scn一直到现在的日志(完全恢复的话)
举个例子:
a,b两个数据文件,把a置于备份模式,b正常
这时候两个change scn都是100,然后开始备份
这期间有数据库的修改,备份完成的时候,Scn变成了200.但是由于a的备份模式,
所以a的文件头中记录的scn还是100,b是200.
某个时间,假设scn 500
这时候a丢失
copy回a的备份,然后recover,完全恢复的话数据库就应用100—500这段的日志,自然也就不会丢失数据了。
因为不管在我copy备份的过程中你做什么操作,总之都在锁定的时change scn之后,
所以应用的日志就不会有遗漏了。这时候应该能理解为什么要数据库处于archived模式了
看看数据文件头的change scn
SQL>select NAME,TABLESPACE_NAME,STATUS,CHECKPOINT_CHANGE# from |
6 rows selected.

