在數據庫打開的情況下備份(歸檔模式),把表空間或者數據庫置於backup 模式下,
如:
SQL> alter database begin backup;
Database altered.
那麼當把表空間或者數據庫置於backup模式下,會發生什麼?
1.表空間會發生checkpoint,j將內存中的dirty data全部寫進數據文件中;
2.在數據文件頭的SCN號會被凍結住;
3.在backup模式下,一個數據塊發生了改變,那麼整個數據塊都會被寫進重做數據流中。
所以在backup模式下,是允許用戶向數據庫中寫數據的。
做個試驗證明一下,表空間置於backup模式下,用戶任然可以修改數據。
沒有表空間置於backup 模式下:
打開第一個會話,用sys用戶登錄,創建一個用戶p1,
SQL> create user p1 identified by p1_12345 default tablespace users;
User created.
SQL> grant connect,resource to p1;
Grant succeeded.
打開第二個會話,用p1用戶登錄,創建表fruit,
SQL> insert into fruit values('apple');
1 row created.
SQL> commit;
Commit complete.
在第一個會話中,
SQL> alter system checkpoint;
System altered.
使數據寫到磁盤上;
回到第二個會話中,
SQL> select dbms_rowid.rowid_block_number(rowid) blk,name from fruit;
BLK NAME
---------- --------------------------------
814 apple
這是oracle提供的包,由rowid可以看到這個數據文件在哪個數據塊上。
通過show parameter db_block_size可以看到它的大小是8192k,
在操作系統中找到users01.dbf(我默認的表空間是users),
[oracle@oracle11g wilson]$ ll /u01/oradata/wilson/users01.dbf
-rw-r----- 1 oracle oinstall 30154752 Aug 23 00:47 /u01/oradata/wilson/users01.dbf
[oracle@oracle11g wilson]$ dd if=users01.dbf ibs=8192 skip=814 count=1 | strings
1+0 records in
16+0 records out
8192 bytes (8.2 kB) copied, 0.000406787 seconds, 20.1 MB/s
U7^M
SUBMIT_COLL_CREDENTIAL_DATA
apple
可以看到apple 被成功的寫進了數據文件中。
將users表空間置於backup模式下
SQL> alter tablespace users begin backup;
Tablespace altered.
看是否可以修改其數據,
在第二個會話中(p1用戶),
SQL> update fruit set name='two apple' ;
1 row updated.
SQL> commit;
Commit complete
在第一個會話中(sys用戶)中:
SQL> alter system checkpoint;
System altered.
使數據寫到磁盤上;
回到第二個會話中,
SQL> select dbms_rowid.rowid_block_number(rowid) blk,name from fruit;
BLK NAME
---------- -------------------------------
814 two apple
與上面同樣的,在在操作系統中找到users01.dbf,然後
[oracle@oracle11g wilson]$ dd if=users01.dbf ibs=8192 skip=814 count=1 | strings
1+0 records in
16+0 records out
8192 bytes (8.2 kB) copied, 0.000335085 seconds, 24.4 MB/s
U7^M
a}]R
SUBMIT_COLL_CREDENTIAL_DATA
two apple,
apple
可以看到在users表空間在backup模式下,用戶任然可以向其中修改數據。(有一點不明白,爲什麼apple這個數據還在文件中,望高手解答一個)
最後介紹個動態性能視圖v$backup,
SQL> select * from v$backup;
FILE# STATUS CHANGE# TIME
---------- ------------------ ---------- ---------
1 NOT ACTIVE 2794785 23-AUG-13
2 NOT ACTIVE 2794785 23-AUG-13
3 NOT ACTIVE 2794785 23-AUG-13
4 ACTIVE 2798071 23-AUG-13
5 NOT ACTIVE 2794785 23-AUG-13
6 NOT ACTIVE 2794785 23-AUG-13
7 NOT ACTIVE 2794785 23-AUG-13
8 NOT ACTIVE 2794785 23-AUG-13
9 NOT ACTIVE 2794785 23-AUG-13
10 NOT ACTIVE 2794785 23-AUG-13
11 NOT ACTIVE 2794785 23-AUG-13
11 rows selected.
可以看到文件4是active,說明它是處於backup模式下的,但是還是不知道是哪個文件和表空間處於backup模式下。
SQL> select file_id,file_name,tablespace_name from dba_data_files order by file_id;
FILE_ID FILE_NAME TABLESPACE_NAME
---------- ----------------------------------- ------------------------------
1 /u01/oradata/wilson/system01.dbf SYSTEM
2 /u01/oradata/wilson/sysaux01.dbf SYSAUX
3 /u01/oradata/wilson/undotbs01.dbf UNDOTBS1
4 /u01/oradata/wilson/users01.dbf USERS
5 /u01/oradata/wilson/example01.dbf EXAMPLE
6 /u01/oradata/wilson/paul01.dbf PAUL
7 /u01/oradata/wilson/sun01.dbf SUN
8 /u01/oradata/wilson/smallundo1.dbf SMALLUNDO
9 /u01/oradata/wilson/assm_1.dbf ASSM
10 /u01/oradata/wilson/mssm_1dbf MSSM
11 /u01/oradata/wilson/paul02.dbf PAUL
11 rows selected.
可以看到是users 表空間( /u01/oradata/wilson/users01.dbf)置於backup模式下,這和我們上面做實驗時把users表空間置於backup模式下是一致的。
關閉users表空間的backup模式,
SQL> alter tablespace users end backup;
Tablespace altered.
備註:在backup模式下,可能導致redo log file中的信息量大增(有用戶寫數據等),影響性能,所以備份完後,快速的end backup,也不推薦使用alter database begin backup命令。