|Why an SBT backup MAY take longer and create larger backuppieces than a DISK backup. [ID 1349492.1]
||Modified 17-AUG-2011 Type HOWTO Status MODERATED
In this Document
|This document is being delivered to
you via Oracle Support's Rapid Visibility (RaV) process and therefore
has not been subject to an independent technical review.
Oracle Server - Enterprise Edition - Version: 10.2.0.4 to 188.8.131.52 - Release: 10.2 to 11.2
Information in this document applies to any platform.
There are many different reasons why a tape backup may take longer than
disk. This note is only relevant when comparing the time spent scanning
the input files during backup:
allocate channel d1 type disk;
backup validate database; }
allocate channel t1 type sbt;
backup validate database; }
a backup validate to tape is very fast compared to the usual tape
backup runtime then the scan of the input files is not an issue and
there is a problem with the writes to the media manager - this is not
covered by this document. This document explains the difference in how
we scan the input files depending on whether or not disk or sbt channels
There is a fundamental difference in the way we scan the input files between DISK and any 3rd party media manager SBT backup.
From 10G, a disk backup uses unused block compression which means, for a
locally managed tablespace, only allocated extents are scanned during
During the lifetime of the database, objects can be dropped, shrunk,
truncated, rebuilt and these actions can result in extents being
deallocated back to the free list.
A database with volatile data may have a large percentage of dirty unallocated extents.
A disk backup is quicker as it scans only the allocated extents and
smaller, as only the dirty blocks within those allocated extents are
written to the backuppiece.
A tape backup takes longer as it will always scan a file 100% and ALL
dirty blocks , even if unallocated are written. The exception is where
Oracle Secure Backup is used as this also uses unused block
compression, similar to disk.
Over a period of time, if all
blocks are allocated there will be no difference in the VALIDATE
runtimes for DISK or SBT . The view v$backup_datafile will show how
many blocks are read and written during backup:
SQL>alter session set nls_date_format='dd-mon-rr hh24:mi:ss';
SQL>set lines 800
SQL>set pages 100
file#, to_char(creation_change#), incremental_level,
to_char(incremental_change#) inc#,to_char(checkpoint_change#) ckp#,
datafile_blocks BLKS, block_size blksz,
round((blocks_read/datafile_blocks) * 100,2) "%READ",
blocks WRTN, round((blocks/datafile_blocks)*100,2) "%WRTN"
from v$backup_datafile where completion_time > 'date' ;
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/11780477/viewspace-705358/，如需转载，请注明出处，否则将追究法律责任。