在数据库打开的情况下备份(归档模式),把表空间或者数据库置于backup 模式下,在backup模式下,可能导致redo log file中的信息
在数据库打开的情况下备份(归档模式),把表空间或者数据库置于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 ;
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命令。
推荐阅读:
Oracle基础教程之通过RMAN复制数据库
RMAN备份策略制定参考内容
RMAN备份学习笔记
Oracle数据库备份加密 RMAN加密
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至253000106@qq.com举报,一经查实,本站将立刻删除。
发布者:PHP中文网,转转请注明出处:https://www.chuangxiangniao.com/p/1884566.html