Document 1274720.1 https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-stat...

Copyright (c) 2020, Oracle. All rights reserved. Oracle Confidential.

How to estimate the size of an RMAN database backup (Doc ID 1274720.1)

In this Document

Goal
Solution
References

APPLIES TO:

Oracle Database - Enterprise Edition - Version 10.2.0.4 and later

Information in this document applies to any platform.

GOAL

How to estimate the RMAN backuppiece size for a database that has never been backed up by RMAN before.

SOLUTION

The ultimate size of an rman backupiece depends on a number of factors:

- the device type used (DISK or SBT) determines whether or not UNUSED BLOCK COMPRESSION is used
- the number of dirty blocks found during the input scan (NULL compression)
- backup compression

NOTE: The information in this article is a rough estimate and will change since block compression, undo optimization, and other factors
may change between backups.

UNUSED block compression can only be used by DISK backups or Oracle Secure Backup and uses space bitmap indexes in locally managed
tablespaces to scan only allocated extents during backup and results in a faster backup (we dont have to scan the whole database) and can
significantly reduce the size of the backup as 'dirty' blocks that are not allocated will not be scanned - see Note 563427.1: A Complete
Understanding of RMAN Compression.

NULL compression is the process of omitting blocks that have NEVER been touch - only 'dirty' blocks are included in the backuppiece.

Backup compression , if used will further compress the output by a factor of 2- 4 times.

To estimate the backupppiece size of an SBT backup (other than Oracle Secure Backup) you would need to know how many dirty blocks are
in the WHOLE database - querying db_free_space will tell you how much free space is unallocated BUT a tape backup will scan the whole
database so 'dirty' block in unallocated extents will still be included in the backuppiece. If the database contains a high percentage of 'dirty'
blocks then worse case scenario is that the backuppiece size will be the same as the database size.

Example to estimate the size of a DISK or Oracle Secure Backup backup:

SQL> select sum(bytes)/1024/1024 from v$datafile;

SUM(BYTES)/1024/1024
--------------------
990

SQL> select sum(bytes)/1024/1024 from dba_free_space;

SUM(BYTES)/1024/1024
--------------------
344.25

990-344.25=645.75 Mb

1 de 2 8/04/2020, 9:12 a. m.
Document 1274720.1 https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-stat...

So potentially the backuppiece should be no more than 645.75 Mb. But because of NULL compression the backuppiece may actually be
smaller - ultimately you need to run a backup :

Disk backup:

BS Key Type LV Size Device Type Elapsed Time Completion Time

------- ---- -- ---------- ----------- ------------ ------------------
8 Full 458.24M DISK 00:00:49 17-dec-10 09:02:11
BP Key: 8 Status: AVAILABLE Compressed: NO Tag: TAG20101217T090122

The same database backed up to tape is bigger because Unused Block Compression is NOT used:

BS Key Type LV Size Device Type Elapsed Time Completion Time

------- ---- -- ---------- ----------- ------------ ------------------
10 Full 777.25M SBT_TAPE 00:01:41 17-dec-10 09:09:14
BP Key: 10 Status: AVAILABLE Compressed: NO Tag: TAG20101217T090732

In both examples above, the backuppiece size is further reduced if backup compression is used (backup as compressed backupset
database):

Disk:

BS Key Type LV Size Device Type Elapsed Time Completion Time

------- ---- -- ---------- ----------- ------------ ------------------
12 Full 87.00M DISK 00:00:33 17-dec-10 09:12:25
BP Key: 12 Status: AVAILABLE Compressed: YES Tag: TAG20101217T091152

SBT:

BS Key Type LV Size Device Type Elapsed Time Completion Time

------- ---- -- ---------- ----------- ------------ ------------------
14 Full 181.00M SBT_TAPE 00:01:05 17-dec-10 09:15:32
BP Key: 14 Status: AVAILABLE Compressed: YES Tag: TAG20101217T091427

REFERENCES

NOTE:563427.1 - A Complete Understanding of RMAN Compression

Didn't find what you are looking for?

2 de 2 8/04/2020, 9:12 a. m.