Oracle11g 新特性:优化Rman备份UNDO表空间

Oracle11gR1的新特性,Rman备份UNDO表空间时排除已经提交的会话对应的数据,提高了Rman备份的效率。

官方文档:http://docs.oracle.com/cd/B28359_01/server.111/b28279/chapter1.htm#AREANO02323

我们知道,UNDO表空间主要用于存储前镜像数据,这些数据在回滚以及恢复过程中可能被用到。但是一个生产数据库的UNDO表空间可能会变得非常巨大,而备份完整的UNDO数据文件在恢复时一般可能用到的比例很小。

测试一下:

--数据库版本
[email protected]>select * from v$version;

BANNER
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
PL/SQL Release 11.2.0.4.0 - Production
CORE	11.2.0.4.0	Production
TNS for Linux: Version 11.2.0.4.0 - Production
NLSRTL Version 11.2.0.4.0 - Production
--创建环境
[email protected]>insert into t1 select * from dba_segments;

5887 rows created.

[email protected]>insert into t1 select * from dba_segments;

5887 rows created.

[email protected]>insert into t1 select * from dba_segments;

5887 rows created.

[email protected]>insert into t1 select * from dba_segments;

5887 rows created.

[email protected]>insert into t1 select * from dba_segments;

5887 rows created.

[email protected]>insert into t1 select * from dba_segments;

5887 rows created.

[email protected]>insert into t1 select * from dba_segments;

5887 rows created.

[email protected]>insert into t1 select * from dba_segments;

5887 rows created.

[email protected]>insert into t1 select * from dba_segments;

5887 rows created.

[email protected]>commit;

Commit complete.

[email protected]>delete from t1;

288463 rows deleted.

[email protected]>select status,sum(bytes)/1024/1024 from dba_undo_extents group by status;

STATUS			    SUM(BYTES)/1024/1024
--------------------------- --------------------
UNEXPIRED				   9.125
EXPIRED 				   .4375
ACTIVE					  89.125

[email protected]>commit;

Commit complete.

--两次备份undo表空间文件
RMAN> backup datafile 5;

Starting backup at 2016-12-22 13:09:27
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00005 name=/u02/app/oracle/oradata/orcl/undotbs2_01.dbf
channel ORA_DISK_1: starting piece 1 at 2016-12-22 13:09:27
channel ORA_DISK_1: finished piece 1 at 2016-12-22 13:09:28
piece handle=/u02/app/oracle/product/11.2.4/db1/dbs/3aro4007_1_1 tag=TAG20161222T130927 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 2016-12-22 13:09:28

Starting Control File and SPFILE Autobackup at 2016-12-22 13:09:28
piece handle=/u02/app/oracle/product/11.2.4/db1/dbs/c-1444351641-20161222-0f comment=NONE
Finished Control File and SPFILE Autobackup at 2016-12-22 13:09:31
--查看备份后的文件大小
RMAN> list backup of datafile 5;

List of Backup Sets
===================
--第一次备份文件大小99.27M
BS Key  Type LV Size       Device Type Elapsed Time Completion Time    
------- ---- -- ---------- ----------- ------------ -------------------
87      Full    99.27M     DISK        00:00:03     2016-12-22 12:11:54
        BP Key: 87   Status: AVAILABLE  Compressed: NO  Tag: TAG20161222T121151
        Piece Name: /u02/app/oracle/product/11.2.4/db1/dbs/36ro3sk7_1_1
  List of Datafiles in backup set 87
  File LV Type Ckp SCN    Ckp Time            Name
  ---- -- ---- ---------- ------------------- ----
  5       Full 9042031    2016-12-22 12:11:51 /u02/app/oracle/oradata/orcl/undotbs2_01.dbf
--第二次备份文件大小2.16M
BS Key  Type LV Size       Device Type Elapsed Time Completion Time    
------- ---- -- ---------- ----------- ------------ -------------------
89      Full    2.16M      DISK        00:00:01     2016-12-22 12:34:42
        BP Key: 89   Status: AVAILABLE  Compressed: NO  Tag: TAG20161222T123441
        Piece Name: /u02/app/oracle/product/11.2.4/db1/dbs/38ro3tv1_1_1
  List of Datafiles in backup set 89
  File LV Type Ckp SCN    Ckp Time            Name
  ---- -- ---- ---------- ------------------- ----
  5       Full 9042576    2016-12-22 12:34:41 /u02/app/oracle/oradata/orcl/undotbs2_01.dbf
--查看操作系统文件大小
[[email protected] release]$ ls -lh /u02/app/oracle/product/11.2.4/db1/dbs/36ro3sk7_1_1
-rw-r----- 1 oracle oinstall 100M Dec 22 12:11 /u02/app/oracle/product/11.2.4/db1/dbs/36ro3sk7_1_1
[[email protected] release]$ ls -lh /u02/app/oracle/product/11.2.4/db1/dbs/38ro3tv1_1_1
-rw-r----- 1 oracle oinstall 2.2M Dec 22 12:34 /u02/app/oracle/product/11.2.4/db1/dbs/38ro3tv1_1_1

这个新特性也有一些限制

- Compatible parameter must be set to 11.0 or higher 
- Backup must use a disk or OSB channel
- For ‘backup copy of <object>‘ or ‘backup datafilecopy‘ the database must be open for undo optimization to be used. 
- Not active for LEVEL 1 incremental backups, only for LEVEL 0 and FULL backups

MOS文档:RMAN 11G : RMAN UNDO backup optimization (文档 ID 406468.1)

A Complete Understanding of RMAN Compression (文档 ID 563427.1)

时间: 2024-08-07 00:16:51

Oracle11g 新特性:优化Rman备份UNDO表空间的相关文章

Oracle 12.1新特性----使用RMAN从备份中实现recover table

在Oracle12c版本之前,使用RMAN能恢复的级别为数据库级别和表空间级别,如果只有一张表需要恢复,而在数据库级别或表空间级别做恢复,影响范围就太大了.因此12.2版本中提供了一个新特性使用RMAN在表级别做恢复,并且恢复过程中不影响数据库的正常使用.这一功能不仅可以恢复表,还可以恢复表分区. 下面在12.2版本上做表级别恢复的实验 [email protected]>select * from v$version; BANNER      CON_ID ------------------

MySQL5.7新特性——在线收缩undo表空间

1. MySQL 5.5时代的undo log 在MySQL5.5以及之前,大家会发现随着数据库上线时间越来越长,ibdata1文件(即InnoDB的共享表空间,或者系统表空间)会越来越大,这会造成2个比较明显的问题: (1)磁盘剩余空间越来越小,到后期往往要加磁盘: (2)物理备份时间越来越长,备份文件也越来越大. 这是怎么回事呢? 原因除了数据量自然增长之外,在MySQL5.5以及之前,InnoDB的undo log也是存放在ibdata1里面的.一旦出现大事务,这个大事务所使用的undo

【oracle11g,13】表空间管理2:undo表空间管理(调优) ,闪回原理

一.undo空间原理: dml操作会产生undo数据. update时,sever process 会在databuffer 中找到该记录的buffer块,没有就从datafile中找并读入data buffer.在修改之前,原始数据先放到undo段,并在数据块头记录undo段(acitve 状态)中该数据块的位置,读写这个块时会占用事务槽,会将该事务号记录在数据块的头部.然后在进行update,并将该块放到dirty list检查点队列,等待dbwr进行写操作. 二.创建新的undo表空间替换

Oracle11g新特性之动态变量窥视

1. 11g之前的绑定变量窥视 我们都知道,为了能够让SQL语句共享执行计划,oracle始终都是强调在进行应用系统的设计时,必须使用绑定变量,也就是用一个变量来代替原来出现在SQL语句里的字面值.比如,对于下面三条SQL语句来说: select col1 from t where col2 = 1; select col1 from t where col2 = 2; select col1 from t where col2 = 3; 我们可以看到,这三条SQL语句几乎一样,只有最后wher

无备份情况下回复undo表空间

UNDO表空间存储着DML操作数据块的前镜像数据,在数据回滚,一致性读,闪回操作,实例恢复的时候都可能用到UNDO表空间中的数据.如果在生产过程中丢失或破坏了UNDO表空间,可能导致某些事务无法回滚,数据库无法恢复到一致性的状态,Oracle实例可能宕机,之后实例无法正常启动:如果有多个UNDO表空间数据文件,丢失其中一个数据文件数据库实例可能不会导致实例宕机,数据库无法干净的关闭(只能SHUTDOWN ABORT),数据库实例能正常的重启,但所有未回滚的数据块依然无法处理,尝试新建UNDO表空

Oracle备份恢复之无备份情况下恢复undo表空间

UNDO表空间存储着DML操作数据块的前镜像数据,在数据回滚,一致性读,闪回操作,实例恢复的时候都可能用到UNDO表空间中的数据.如果在生产过程中丢失或破坏了UNDO表空间,可能导致某些事务无法回滚,数据库无法恢复到一致性的状态,Oracle实例可能宕机,之后实例无法正常启动:如果有多个UNDO表空间数据文件,丢失其中一个数据文件数据库实例可能不会导致实例宕机,数据库无法干净的关闭(只能SHUTDOWN ABORT),数据库实例能正常的重启,但所有未回滚的数据块依然无法处理,尝试新建UNDO表空

Oracle创建新undo表空间最佳实践(包含段检查)

在处理一则ORA-600 [4194]案例时,参考MOS文档:Step by step to resolve ORA-600 4194 4193 4197 on database crash (文档 ID 1428786.1) 1.对于ORA 600[4194]的解释 2.创建新undo表空间最佳实践(包含段检查) 1.对于ORA 600[4194]的解释: The following error is occurring in the alert.log right before the da

【undo表空间的丢失-恢复-1】

使用rman进行恢复--undo丢失 restore 把文件还原回去: recover 利用日志文件重做: 关键性的文件丢失和非关键性的文件丢失(system/undo之外的丢失) 1> 删除undo文件: [[email protected] ~]$ rm /u01/oracle/oradata/jadl10g/undotbs01.dbf [[email protected] ~]$ sqlplus / as sysdba SQL*Plus: Release 10.2.0.5.0 - Prod

记一次UNDO表空间超90%的处理

今天在为一套库扩表空间时查看到UNDOTBS1/2使用率均超过了90%,监控居然没报警,呵呵,这种花钱买监控还不如Nagios SQL> select * from v$version; BANNER -------------------------------------------------------------------------------- Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Pr