Oracle数据库联机热备份的原理简介
文章作者 100test 发表时间 2007:03:14 13:57:25
来源 100Test.Com百考试题网
要求归档模式
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 0select 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>0select NAME,TABLESPACE_NAME,STATUS,CHECKPOINT_CHANGE# from v$datafile_header.
NAME TABLESPACE STATUS CHECKPOINT_CHANGE#
-------------------------------- ---------- -------------- ------------------
/u02/oradata/sales/system01.dbf SYSTEM ONLINE 545926
/u02/oradata/sales/undotbs01.dbf UNDOTBS1 ONLINE 545926
/u02/oradata/sales/sysaux01.dbf SYSAUX ONLINE 545926
/u02/oradata/sales/users01.dbf USERS ONLINE 545498
/u02/oradata/sales/example01.dbf EXAMPLE ONLINE 545926
/u02/oradata/sales/perfstat.dbf PERFSTAT ONLINE 545926
6 rows 0selected. |
显然，在将users表空间置于backup状态的时候，相应的datafile的文件头的scn就不会再发生改变，
发生检查点也不会改变。
SQL> alter system checkpoint.
System altered.
SQL> 0select NAME,TABLESPACE_NAME,STATUS,CHECKPOINT_CHANGE# from v$datafile_header.
NAME TABLESPACE STATUS CHECKPOINT_CHANGE#
-------------------------------- ---------- -------------- ------------------
/u02/oradata/sales/system01.dbf SYSTEM ONLINE 546196
/u02/oradata/sales/undotbs01.dbf UNDOTBS1 ONLINE 546196
/u02/oradata/sales/sysaux01.dbf SYSAUX ONLINE 546196
/u02/oradata/sales/users01.dbf USERS ONLINE 545498
/u02/oradata/sales/example01.dbf EXAMPLE ONLINE 546196
/u02/oradata/sales/perfstat.dbf PERFSTAT ONLINE 546196
6 rows 0selected. |
下面end backup,看看scn
SQL> alter tablespace users end backup.
Tablespace altered.
SQL> alter system checkpoint.
System altered.
SQL>0select NAME,TABLESPACE_NAME,STATUS,CHECKPOINT_CHANGE# from v$datafile_header.
NAME TABLESPACE STATUS CHECKPOINT_CHANGE#
-------------------------------- ---------- -------------- ------------------
/u02/oradata/sales/system01.dbf SYSTEM ONLINE 546467
/u02/oradata/sales/undotbs01.dbf UNDOTBS1 ONLINE 546467
/u02/oradata/sales/sysaux01.dbf SYSAUX ONLINE 546467
/u02/oradata/sales/users01.dbf USERS ONLINE 546467
/u02/oradata/sales/example01.dbf EXAMPLE ONLINE 546467
/u02/oradata/sales/perfstat.dbf PERFSTAT ONLINE 546467
6 rows 0selected. |
------------------
再说说rman备份