oracle中backup模式


oracle中backup模式
 
在数据库打开的情况下备份（归档模式），把表空间或者数据库置于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/