RMAN 10.2 "unused" block compression

Has anyone tested for the unused block compression. I realize the docs say it is the case now in 10.2 that rman only backs up currently used blocks, and not blocks that belonged to dropped or truncated tables. I can't proove it on my own system.
I tried...
1) creating a tbsp 100mb, with an 80mb table. Backed it up as a backupset
2) Dropped the 80mb table and purged it from the recyclebin. Backed it up as a backupset.
Both backupsets were the exact same size, indicating only that rman doesn't back up "never" used blocks.
I did the same test AS COMPRESSED BACKUPSET and got the same result, both were compressed but were of equal size.
Thanks,
A

Okay, no luck. I've tried every which way to backup...
1.4GB db with a 720MB table...
BACKUP INCREMENTAL LEVEL 0 AS COMPRESSED BACKUPSET DATABASE results in a 230.6MB backupset file.
DROP TABLE <720mb table> PURGE;
Same backup commands. Same backup size 230.6MB.
Doesn't work as far as I can tell.
A

Similar Messages

OSB Unused block compression and Undo backup compression

Dear all.
I know that osb backup software is faster than other vendor software especially oracle database backup area.
There are two special method (Unused block compression and Undo backup compression)
But, normally in case of comparable product using same RMAN API(Veritas/Legato etc...), they only backup used block and skip unused block, right?
I'm confused, what is different from used block only backup and unused block compression.
Please explain detail about unused block compression and Undo backup compression.
Sorry about my poor knowledge.
Thanks.

This is explained in detail in the OSB technical white paper:
http://www.oracle.com/technetwork/products/secure-backup/learnmore/osb-103-twp-166804.pdf
Let me know if you have any questions
Donna

RMAN logical backup containing unused blocks

Dear Experts
When i taking logical backup of datafile from RMAN utility i notify that it will also backed up all unused blocks from datafile, so what i need to do, how to avoid that unused block from being backed up while taking logical backup of datafiles.
System details as follows
HP Itanium server
OS - Redhet Linux 5
DB - Oracle10g
Suggest me urgent.

Here i am gonna show you the backup statistics for only those problematic datafiles
DFNAME                                    DATAFILE_BLCKS     BLOCKS          DIFF
/san_index/oradata/orcl/rajemitra_index1.dbf     1695744     9818          1685926
/san_index/oradata/orcl/rajemitra_index2.dbf     1716224          8527          1707697
/san_index/oradata/orcl/rajemitra_index3.dbf     1622016          9727          1612289
/san_index/oradata/orcl/rajemitra_index4.dbf     1622016          9808          1612208
/san_index/oradata/orcl/rajemitra_index1.dbf     1695744          24823          1670921
/san_index/oradata/orcl/rajemitra_index2.dbf     1716224          19891          1696333
/san_index/oradata/orcl/rajemitra_index3.dbf     1622016          20591          1601425
/san_index/oradata/orcl/rajemitra_index4.dbf     1622016          17026          1604990
/san_index/oradata/orcl/rajemitra_index1.dbf     1695744          21239          1674505
/san_index/oradata/orcl/rajemitra_index2.dbf     1716224          17843          1698381
/san_index/oradata/orcl/rajemitra_index3.dbf     1622016          19820          1602196
/san_index/oradata/orcl/rajemitra_index4.dbf     1622016          14429          1607587
/san_index/oradata/orcl/rajemitra_index1.dbf     1695744          33885          1661859
/san_index/oradata/orcl/rajemitra_index2.dbf     1716224          41480          1674744
/san_index/oradata/orcl/rajemitra_index3.dbf     1622016          32338          1589678
/san_index/oradata/orcl/rajemitra_index4.dbf     1622016          26288          1595728
/san_index/oradata/orcl/rajemitra_index1.dbf     1695744          10504          1685240
/san_index/oradata/orcl/rajemitra_index2.dbf     1716224          18169          1698055
/san_index/oradata/orcl/rajemitra_index3.dbf     1622016          16195          1605821
/san_index/oradata/orcl/rajemitra_index4.dbf     1622016          11974          1610042
/san_index/oradata/orcl/rajemitra_index1.dbf     1695744          16938          1678806
/san_index/oradata/orcl/rajemitra_index2.dbf     1716224          25688          1690536
/san_index/oradata/orcl/rajemitra_index3.dbf     1622016          30653          1591363
/san_index/oradata/orcl/rajemitra_index4.dbf     1622016          20611          1601405
/san_index/oradata/orcl/rajemitra_index1.dbf     1695744          965385          730359
/san_index/oradata/orcl/rajemitra_index2.dbf     1716224          1010354          705870
/san_index/oradata/orcl/rajemitra_index4.dbf     1622016          1004034          617982
/san_index/oradata/orcl/rajemitra_index1.dbf     1695744          1695397          347
/san_index/oradata/orcl/rajemitra_index2.dbf     1716224          1713435          2789
/san_index/oradata/orcl/rajemitra_index3.dbf     1622016          1621255          761
/san_index/oradata/orcl/rajemitra_index4.dbf     1622016          1620287          1729
/san_index/oradata/orcl/rajemitra_index1.dbf     1695744          1695397          347
/san_index/oradata/orcl/rajemitra_index5.dbf     1171456          1170831          625
/san_index/oradata/orcl/rajemitra_index1.dbf     1695744          1695397          347
/san_index/oradata/orcl/rajemitra_index2.dbf     1716224          1713470          2754
/san_index/oradata/orcl/rajemitra_index3.dbf     1622016          1621261          755
/san_index/oradata/orcl/rajemitra_index4.dbf     1622016          1620364          1652
/san_index/oradata/orcl/rajemitra_index5.dbf     1171456          48547          1122909
/san_index/oradata/orcl/rajemitra_index1.dbf     1695744          47875          1647869
/san_index/oradata/orcl/rajemitra_index2.dbf     1716224          19725          1696499
/san_index/oradata/orcl/rajemitra_index3.dbf     1622016          26205          1595811
/san_index/oradata/orcl/rajemitra_index4.dbf     1622016          56040          1565976
/san_index/oradata/orcl/rajemitra_index5.dbf     1171456          31859          1139597
/san_index/oradata/orcl/rajemitra_index1.dbf     1695744          29509          1666235
/san_index/oradata/orcl/rajemitra_index2.dbf     1716224          20767          1695457
/san_index/oradata/orcl/rajemitra_index3.dbf     1622016          13210          1608806
/san_index/oradata/orcl/rajemitra_index4.dbf     1622016          31411          1590605

RMAN 10g new incremental features compression issue

Hi,
I'm testing block change tracking and fast incremental but, come to an issue with compressed level 0 backupsets and uncompressed level 1.
I've run:
connect target;
backup as compressed backupset INCREMENTAL LEVEL 0 TAG = WEEKLY DATABASE;
exit;
on 500GB database ,and the backupset was about 90GB.
But now I'm trying :
RMAN> BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG WEEKLY DATABASE;
Starting backup at 2008-02-20 22:27:34
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=367 devtype=DISK
no parent backup or copy of datafile 7 found
no parent backup or copy of datafile 29 found
no parent backup or copy of datafile 42 found
no parent backup or copy of datafile 56 found
no parent backup or copy of datafile 19 found
no parent backup or copy of datafile 61 found
no parent backup or copy of datafile 83 found
no parent backup or copy of datafile 77 found
no parent backup or copy of datafile 92 found
no parent backup or copy of datafile 105 found
and don't know how oracle manage to 'merge' level 0 compressed backup and level 1 uncompressed backup. For me it looks like the level 1 is equal to level 0 .
BTW that database was not used at all so I was expecting to almost 0 size incrementals.
The next step should be :
RECOVER COPY OF DATABASE
WITH TAG WEEKLY;
but I've give up as totaly confused :).
Any explanation would be great.
There is a lot of myth about new features behaviour.
Best Regards.
Grzegorz

You are mixing 2 independent features , compression and incrementally updated backups. Talking about incrementally updated backups,this is a working script:
run {
recover copy of database with tag 'incr_update'';
backup incremental level 1 for recover of copy with tag 'incr_update' database;
You don't start the process with 'backup database ..'. How it works:
In the first run 'recover copy...' does anything,because there's no backup to recover.
'backup incremental...' creates image copies (not a backupset) of all datafiles,image copies are never compressed.
In the second run 'recover copy...' still does nothing,because we still have no backup. 'backup incremental...' now creates an incremental backup , that may be compressed or not compressed. I've set 'compressed' as permanent parameter,so it's not included in the command.
In the third (and all following) run 'recover copy...' now applies the incremental backups taken in the previous run to the image copies. 'backup incremental...' creates a new incremental backup, again this can be compressed or not.
Werner

Rman backup with corrupted block

Hello,
Firstly - I have problem on non-production database 11.2.0.1.0, so I am not deeply worried about data. But I need to understand what happened with database backups and how to prevent such things in future.
So - I have EM scheduled weekly full backup and daily incremental backups. Later there was problem with hardware and some corrupted blocks in database were found. The weekly backup ran without error and obsolete backups were deleted. Now it is not possible to "recover corruption list" because no backup without corruption exists (RMAN-06023: no backup or copy of datafile 6 found to restore). I am not worried about the lost data, but I need to find out how come the backup contains corrupted block.
I have checked the data file using dbv utility
DBVERIFY - Verification starting : FILE = /opt/oracle/oradata/orcl/users03.dbf
DBV-00200: Block, DBA 27525766, already marked corrupt
csc(0x0001.7b01729f) higher than block scn(0x0000.00000000)
Page 2359942 failed with check code 6054
DBVERIFY - Verification complete
Total Pages Examined         : 3840000
Total Pages Processed (Data) : 453896
Total Pages Failing   (Data) : 1
Total Pages Processed (Index): 2959104
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 424025
Total Pages Processed (Seg) : 0
Total Pages Failing   (Seg) : 0
Total Pages Empty            : 2975
Total Pages Marked Corrupt   : 1
Total Pages Influx           : 0
Total Pages Encrypted        : 0
Highest block SCN            : 2156227446 (1.2156227446)As you can see the datafile 6 - user03.dbf has errors. Also backups now contain errors.
1) So how is it possible that the EM scheduled backup ran without problems and the backup now contains corrupted blocks. How to prevent this in future ? I know there is setting MAXCORRUPT. How can I check its current value ? How can I configure it using EM scheduled backups ?
2) Secondly, meanwhile I studied the RMAN commands. So I have suspended EM backup jobs, and executed follwing command. And backup ran without error again. How is this possible, if data file users06.dbf has corrupted block ?
Thanks !
RMAN> run {
set MAXCORRUPT for datafile 6 to 0;
backup as compressed backupset datafile 6;
2> 3> 4>
executing command: SET MAX CORRUPT
Starting backup at 07-NOV-12
using channel ORA_DISK_1
using channel ORA_DISK_2
using channel ORA_DISK_3
using channel ORA_DISK_4
using channel ORA_DISK_5
channel ORA_DISK_1: starting compressed full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00006 name=/opt/oracle/oradata/orcl/users03.dbf
channel ORA_DISK_1: starting piece 1 at 07-NOV-12
channel ORA_DISK_1: finished piece 1 at 07-NOV-12
piece handle=/opt/oraBackup/rman/nrnpo0sg_1_1 tag=TAG20121107T200120 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 01:13:05
Finished backup at 07-NOV-12
Starting Control File and SPFILE Autobackup at 07-NOV-12
piece handle=/opt/oraBackup/rman/c-1253245572-20121107-03 comment=NONE
Finished Control File and SPFILE Autobackup at 07-NOV-12

I have updated database to 11.2.0.3
However, the problem still persists. rman backup went ok on broken file
oracle@orcl-cluster:~> sqlplus
SQL*Plus: Release 11.2.0.3.0 Production on Tue Nov 20 09:24:11 2012
Copyright (c) 1982, 2011, Oracle. All rights reserved.
Enter user-name: system
Enter password:
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> select * from V$DATABASE_BLOCK_CORRUPTION;
     FILE#     BLOCK#     BLOCKS CORRUPTION_CHANGE# CORRUPTIO
         6    2359942          1                  0 FRACTURED
        25    1855622          1                  0 FRACTURED
oracle@orcl-cluster:~> rman target /
Recovery Manager: Release 11.2.0.3.0 - Production on Tue Nov 20 08:04:57 2012
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
connected to target database: ORCL (DBID=1253245572)
RMAN> backup as compressed backupset datafile 6;
Starting backup at 20-NOV-12
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=1596 device type=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: SID=1568 device type=DISK
allocated channel: ORA_DISK_3
channel ORA_DISK_3: SID=2357 device type=DISK
allocated channel: ORA_DISK_4
channel ORA_DISK_4: SID=2341 device type=DISK
allocated channel: ORA_DISK_5
channel ORA_DISK_5: SID=86 device type=DISK
channel ORA_DISK_1: starting compressed full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00006 name=/opt/oracle/oradata/orcl/users03.dbf
channel ORA_DISK_1: starting piece 1 at 20-NOV-12
channel ORA_DISK_1: finished piece 1 at 20-NOV-12
piece handle=/opt/oraBackup/rman/2rnqovpp_1_1 tag=TAG20121120T080513 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 01:10:35
Finished backup at 20-NOV-12
Starting Control File and SPFILE Autobackup at 20-NOV-12
piece handle=/opt/oraBackup/rman/c-1253245572-20121120-00 comment=NONE
Finished Control File and SPFILE Autobackup at 20-NOV-12
RMAN> backup validate datafile 6;
Starting backup at 20-NOV-12
using channel ORA_DISK_1
using channel ORA_DISK_2
using channel ORA_DISK_3
using channel ORA_DISK_4
using channel ORA_DISK_5
channel ORA_DISK_1: starting compressed full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00006 name=/opt/oracle/oradata/orcl/users03.dbf
channel ORA_DISK_1: backup set complete, elapsed time: 00:03:05
List of Datafiles
=================
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
6    OK     1              2975         3840000         6489027926
File Name: /opt/oracle/oradata/orcl/users03.dbf
Block Type Blocks Failing Blocks Processed
Data       0              453912
Index      0              2959091
Other      0              424022
Finished backup at 20-NOV-12Edited by: kamilp on Nov 20, 2012 12:23 AM

Logical block corruption in an unused block which is a part of index

Hi All,
During RMAN backup level 0 I am getting a corrupted block my DB:
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of backup command on t20 channel at 07/22/2009 21:30:49
ORA-19566: exceeded limit of 0 corrupt blocks for file /oracle/oradata/DB2/plind05_02.dbf
SQL> select * from v$database_block_corruption;
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
2950 1879477 1 1.0124E+13 LOGICAL
SQL> SELECT tablespace_name, partition_name,segment_type, owner, segment_name FROM dba_extents WHERE file_id = 2950 and 1879477 between block_id AND block_id + blocks - 1;
no rows selected
So this block does not belong to any object.
SQL > select * from dba_free_space where file_id= 2950 and 1879477 between block_id and block_id blocks -1;+
TABLESPACE_NAME FILE_ID BLOCK_ID BYTES BLOCKS RELATIVE_FNO
USAGIDX_200907 2950 1879433 1048576 128 909
But it exists in dba_free_space so it belongs to file space usage bitmap.
DB Verify shows:
myserver:/oracle/rman/DB2:DBINST1> dbv file=/oracle/oradata/DB2/plind05_02.dbf BLOCKSIZE=8192
DBVERIFY: Release 10.2.0.4.0 - Production on Wed Jul 29 13:47:38 2009
Copyright (c) 1982, 2007, Oracle. All rights reserved.
DBVERIFY - Verification starting : FILE = /oracle/oradata/DB2/plind05_02.dbf
Block Checking: DBA = -480465494, Block Type = KTB-managed data block
**** row 2: key out of order
---- end index block validation
Page 1879477 failed with check code 6401
DBVERIFY - Verification complete
Total Pages Examined : 4194176
Total Pages Processed (Data) : 0
Total Pages Failing (Data) : 0
Total Pages Processed (Index): 3404935
Total Pages Failing (Index): 1
Total Pages Processed (Other): 569
Total Pages Processed (Seg) : 0
Total Pages Failing (Seg) : 0
Total Pages Empty : 788672
Total Pages Marked Corrupt : 0
Total Pages Influx : 0
Highest block SCN : 1795222745 (2360.1795222745)
Now, I have identified that this block belongs to an index subpartition so I have rebuild it with alter index ... rebuild subpartition... However, the RMAN backup still fails and DBV still reports an error.
I know that we could simply recreate the index but the problem is that its quite big (>6GB and table is >7TB).
My strong feeling is that the cause of this is that corrupted blocks will still be reported by RMAN and DBV until they are reused and reformatted.
My question is:
How can I reuse or reformat a block which does not belong to any object?

Hi,
Yes you're right, you need to reformat that block.
For that you need to allocate that block to a table, and fill that table with data until high water mark goes higher than block 1879477.
This isthe way I've done it once:
1) check the free space size below that block:
select sum(bytes)/1024/1024 before from dba_free_space where file_id=1879477 and block_id <= 1503738;
Let's say it is 6000 MB
2) create a dummy table, allocate enough extents to fill the size returned from the previous query
This does not format blocks, but the advantage of allocate extents is that you can specify size and datafile:
alter table allocate extents size 6000M datafile '/oracle/oradata/DB2/plind05_02.dbf';
you can check dba_extents to see if it covers block 1879477. If not, try to add a little more extents.
3) fill the table with data to fill those extents.
One idea is to insert one rows into the table, then use 'alter table test minimize records_per_block;' so that each block will have 2 rows maximum.
check the number of blocks (from dba_segments). Say you have 768000 blocks. Then you need to insert 768000/2 rows:
insert into ... select ... from dual connect by level < (768000/2)
4) check the high water mark has reach the end of all extents (compare dba_tables.blocks and dba_segemnts.blocks)
5) if not enough, try to add a little more rows.
Be careful that you don't go too far (especially if you have extensible datafile). Unfortunately, maxextents is ignored on LMT :(
6) now, your block should be reformatted. Just drop the dummy table.
Regards,
Franck.

RMAN Skips the corrupted Block

Hi,
We are using Oracle 10.2.0.4 rman utility for backup, In SYSAUX tablespace, datafile 3, one block has been corrupted.
I have try to export the tablespace , i found warning message of "corrupted block and table name". But RMAN, while try to backup datafile 3, or validate the backup, it doesn't popu any error message and went through with out any problem.
==>I have set maxcorrupt 0 in run block
==> Check logical i have used
==> V$database_block_corruption pops the result but MAXCORRUPT 0.
==> But Analyis the table show the corrupted block error.
===> Try to select * from corrupted table. it throws the error message.
Please advice
Regards
Krish

Steve,
Thank you for the doc, But i have already mentioned,
--> i have tried from check logical
--> Also MaxCorrupt parameter
Am able to view the corrutped block information in database_block_corruption
but while backing with rman using
RMAN> run
2> {
3> set MAXCORRUPT for datafile 3 to 0;
4> backup datafile 3;
5> }
executing command: SET MAX CORRUPT
using target database control file instead of recovery catalog
Starting backup at 27-APR-09
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=12 instance=TEST devtype=DISK
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00003 name=+DBFILE_GRP1/TEST/datafile/sysaux.499.667900479
channel ORA_DISK_1: starting piece 1 at 27-APR-09
channel ORA_DISK_1: finished piece 1 at 27-APR-09
piece handle=/usr/oradata/BKUP/TEST/backup/database/BIRTEF1_4229_1_1_45kdh7uj tag=TAG
comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:15
Finished backup at 27-APR-09
Starting Control File and SPFILE Autobackup at 27-APR-09
Finished Control File and SPFILE Autobackup at 27-APR-09
SQL> select * from v$database_block_corruption;
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
3 23260 1 0 CORRUPT
3 123228 1 0 CORRUPT
ITs backing up with no issues. Thats the confusion here.
REgards
KRishnan

RMAN Restore result in defragmentation or not??

Hi All,
I have read on various Oracle support sites that Oracle 10g RMAN backup uses unused block compression technique for database backup.
What I understand from unused block compression is : It will backup only currently used data blocks and leave free blocks i.e used_MB marked in the query:
select file_name,t.file_id,t.tablespace_name, total-free used_MB from
(select file_name,file_id,tablespace_name,bytes/1024/1024 total from dba_data_files) t ,
(select file_id,tablespace_name,sum(bytes/1024/1024) free from dba_free_space
group by file_id,tablespace_name) f where t.file_id=f.file_id;
If so,whether restoring database from such a backupset will result in a database with reduced datafile frgmentation like exp/imp.
Please help DBA Gurus.
Regards,
Saket Bansal

saket bansal wrote:
other than exp/imp and rebuilding its objects..Hi Saket,
you will need to create another tablespace and move all objects from the tablespace with the fragmented datafile/s into the newly created tablespace.

Related to Unused compression in RMAN backup for 10.2.0.4 database

Hi
I recently read through one of the document related to Unused compression in RMAN backup for 10.2.0.4 database. According to this
Unused Block Compression is done, if all of the following conditions apply:
+ The COMPATIBLE initialization parameter is set to 10.2
+ There are currently no guaranteed restore points defined for the database
+ The datafile is locally managed
+ The datafile is being backed up to a backup set as part of a full backup or a level 0 incremental backup
+ The backup set is being created on disk.
I have two queries
1) What is meant by "uaranteed restore points defined for the database"
2) If backup is being directly taken to tape, this feature would not be used
Rgds
Harvinder

1. Normal and Garanteed Restore Points
2. No

How to get the size of the backed up datafile in a backup set with rman?

Oracle 10gR2 and catalog is in place.
Since RMAN only backups the used blocks(does not take backup from NEVER USED blocks), what can be the explanation of some extra space during backups?
And also how to trace this space allocation by datafile with v$% - rc_% views or any rman command?
Thank you, best regards.
Tonguç

Before 10G R2 rman does not backup never used blocks but it backs up blocks which have been previously used. So, dropping or truncating a table does not make the backup size smaller since the blocks of that segment are not "never used" anymore.
Starting with 10G R2 a new feature named "unused block compression" comes into play. With this feature rman does not backup unused blocks (even if they have been used before). But it has some restrictions like: you need to backup to disk unless you are using Oracle Secure Backup, the datafile needs to be locally managed, etc...
http://download.oracle.com/docs/cd/B19306_01/backup.102/b14194/rcmsynta009.htm#RCMRF98765

Benefits of using RMAN

I've not used RMAN before and am still kind of new to Oracle and I have a question about using RMAN.
We currently have all our databases on SAN and NAS and everynight they are put into hot backup mode and the SAN and NAS take snapshots of them.
We also do a full export everynight.
Given this setup what if any benefits would I see in replacing either or both methods with RMAN backups ?
Thanks.

I advice you to refer to a [documentation |http://download.oracle.com/docs/cd/B19306_01/backup.102/b14192/toc.htm] and to an excellent book " [RMAN Recipes for Oracle Database 11g : A Problem-Solution Approach|http://www.amazon.com/RMAN-Recipes-Oracle-Database-Problem-Solution/dp/1590598512] "
Here's some RMAN benefits from that book :
Here’s a brief description of the important benefits of using RMAN instead of usermanaged backup and recovery techniques:
* You can take advantage of the powerful Data Recovery Advisor feature, which enables you to easily diagnose and repair data failures and corruption (Chapter 20 discusses the Data Recovery Advisor).
* There are simpler backup and recovery commands.
* It automatically manages the backup files without DBA intervention.
* It automatically deletes unnecessary backup datafiles and archived redo log files both from disk and tape.
* It provides you with detailed reporting of backup actions.
* It provides considerable help in duplicating a database or creating a standby database.
* It lets you test whether you can recover your database, without actually restoring data.
* It lets you verify that available backups are usable for recovery.
* It lets you make incremental backups, which isn’t possible by any other means of backup.
* It lets you perform database duplication without backups by using the network-enabled database duplication feature, also known as active duplication.
* It automatically detects corrupt data blocks during backups, with the corruption relevant information recorded in the V$DATABASE_BLOCK_CORRUPTION view.
* When only a few data blocks are corrupted, you can recover at the data block level, instead of recovering an entire datafile.
* You can take advantage of the unused block compression feature, wherein RMAN skips unused data blocks during a backup.
* Only RMAN provides the ability to perform encrypted backups.
* You can use RMAN with a variety of third-party storage systems.
* You can use a powerful yet easy-to-use scripting language, which lets you write custom
backup and recovery scripts quickly
Kamran Agayev A. (10g OCP)
http://kamranagayev.wordpress.com

What are the features of RMAN

What are the features of RMAN

Then, by entering google.com, type "rman features" and you'll face tons of documents
Or refer to documentation:
Using RMAN gives you access to several data backup and recovery techniques and features not available at all with user-managed backup and recovery. The most noteworthy are:
Incremental backups, which provide more compact backups (storing only changed blocks) and faster datafile media recovery (reducing the need to apply redo during datafile media recovery)
Block media recovery, in which a datafile with only a small number of corrupt data blocks can be repaired without being taken offline or restored from backup
Unused block compression, where RMAN can in some cases skip unused datafile blocks during backups
Binary compression, which uses a compression mechanism integrated into the Oracle database server to reduce the size of backups
Encrypted backups, which uses encryption capabilities integrated into the Oracle database to store backups in an encrypted format
http://download.oracle.com/docs/cd/B19306_01/backup.102/b14192/intro005.htm#i1019200
Moreover, you can refer to [Feature Comparison of Backup Methods|http://download.oracle.com/docs/cd/B19306_01/backup.102/b14192/intro010.htm#i1005205] to find out main difference between RMAN and User managed backup and recovery
Kamran Agayev A. (10g OCP)
http://kamranagayev.wordpress.com

Will resizing datafile after shrink segment minimize the rman bkp duration

Hi ,
We have 1 TB database where in the RMAN backup runs for nearly 35 Hrs .
At database level if i shrink the segments to reclaim space and then resize datafile , will it have my RMAN backup duration time to decrease .
Kindly let me know if this can be done .

whats the database version.
As in 10g Rel 2 See "UNUSED BLOCK COMPRESSION"
Unused Block Compression Of Datafile Backups to Backup Sets
When backing up datafiles into backup sets, RMAN does not back up the contents of data blocks that have never been allocated. (In previous releases, this behavior was referred to as NULL compression.)
RMAN also skips other datafile blocks that do not currently contain data, if all of the following conditions apply:
The COMPATIBLE initialization parameter is set to 10.2
There are currently no guaranteed restore points defined for the database
The datafile is locally managed
The datafile is being backed up to a backup set as part of a full backup or a level 0 incremental backup
The backup set is being created on disk.
Skipping unused data blocks where possible enables RMAN to back up datafiles using less space, and can make I/O more efficient.
http://docs.oracle.com/cd/B19306_01/backup.102/b14194/rcmsynta009.htm

Why my Input/output size of backup increased

I have a following rman backup script
run {
backup as compressed backupset incremental level 1 cumulative device type disk tag 'Baan_bkup$LEVEL_0' data
base;
recover copy of database;
backup device type disk tag 'Baan_bkup$LEVEL_0' archivelog all not backed up;
backup archivelog until time 'sysdate-3' delete all input;
crosscheck backupset;
crosscheck archivelog all;
delete noprompt obsolete;
delete noprompt expired backup;
running once daily for almost three weeks. the first 9 days, the input/output sizes were fractional (ex 3G/88M), then it switched to ~16G/1.3G and stayed that level. Because this is test DB server, basically there is no activity on it except the mentainace activity by DB itself.　So how did it happen to cause the size change?　The real backup sets only maintain at 3 days level as the script.　My database size is 16.88G of 10g R2 on RH EL3

That is the behavior in 9i and 10g1. In 10gR2 things change.
Unused Block Compression Of Datafile Backups to Backup Sets
When backing up datafiles into backup sets, RMAN does not back up the contents of data blocks that have never been allocated. (In previous releases, this behavior was referred to as NULL compression.)
RMAN also skips other datafile blocks that do not currently contain data, if all of the following conditions apply:
The COMPATIBLE initialization parameter is set to 10.2
There are currently no guaranteed restore points defined for the database
The datafile is locally managed
The datafile is being backed up to a backup set as part of a full backup or a level 0 incremental backup
The backup set is being created on disk.
http://download-east.oracle.com/docs/cd/B19306_01/backup.102/b14194/rcmsynta009.htm#RCMRF98765

Disadvantages of taking user manged backup directly on tape

Hi,
I have oracle 10.2.0.4 database on aix 5.3 Operating system.
My all the datafiles,controlfiles,logfiles reside on /oradb filesystem.
I have shut down the database & listner, & without copying all the database files into another file system.
I have inform to backup team to take backup directly on tape by giving database file liocation /oradb.
Please let me know the disadvantages of taking backup directly on tape by using user managed backup.
Regards,

All the list points are advantage of rman and are not available in user-managed so are the disadvantage of user-managed.
==> There are simpler backup and recovery commands.
==> It automatically manages the backup files without DBA intervention.
==> It automatically deletes unnecessary backup datafiles and archived redo log files both from disk and tape.
==> It provides you with detailed reporting of backup actions.
==> It provides considerable help in duplicating a database or creating a standby database.
==> It lets you test whether you can recover your database, without actually restoring data.
==> It lets you verify that available backups are usable for recovery.
==> It lets you make incremental backups, which isn’t possible by any other means of backup.
==> It lets you perform database duplication without backups by using the network-enabled database duplication feature, also known as active duplication.
==> It automatically detects corrupt data blocks during backups, with the corruption relevant information recorded in the V$DATABASE_BLOCK_CORRUPTION view.
==> When only a few data blocks are corrupted, you can recover at the data block level, instead of recovering an entire datafile.
==> You can take advantage of the unused block compression feature, wherein RMAN skips unused data blocks during a backup.
==> Only RMAN provides the ability to perform encrypted backups.
==> You can use RMAN with a variety of third-party storage systems.
==> You can use a powerful yet easy-to-use scripting language, which lets you write custom
backup and recovery scripts quickly.
Hope this may help u ..
--neeraj

RMAN 10.2 "unused" block compression

Similar Messages

Maybe you are looking for