个人总结

rman备份时,为什么通道是disk的比通道是sbt的备份快.文中说明了一个原因,就rman的输入文件来说,通道是disk的本地管理表空间,rman只扫描allocate的extents.对于在freelist上的extent不于理采.通道是sbt,rman会扫描输入文件的所有部分.这里包含了已分配的extents,未分配的extents和dirty extent.

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
  Goal
  Solution

---

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.

Applies to:

Oracle Server - Enterprise Edition - Version: 10.2.0.4 to 11.2.0.2 - Release: 10.2 to 11.2
Information in this document applies to any platform.

Goal

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:


If 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 are allocated.

Solution

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 backup.
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: