WelcomeDAVID

(//docs.oracle.com/en/)

Home(https://docs.oracle.com/)/Database(https://docs.oracle.com/en/database/)/OracleDatabaseOnlineDocumentation11gRelease1(11.1)(../../index.htm)/
DatabaseAdministration(../../nav/portal_4.htm)

DatabaseBackupandRecoveryUser'sGuide
()

()

21()TuningRMANPerformance
Thischaptercontainsthefollowingsections:

PurposeofRMANPerformanceTuning
BasicConceptsofRMANPerformanceTuning
UsingV$ViewstoDiagnoseRMANPerformanceProblems
TuningRMANBackupPerformance

()

()PurposeofRMANPerformanceTuning

AnRMANbackuporrestorejobcanbedividedintoseparatephasesorcomponents.Theslowestofthese
phasesinanyRMANjobiscalledthebottleneck.ThepurposeofRMANtuningistoidentifythe
bottlenecksforagivenjobanduseRMANcommands,initializationparameters,oradjustmentstophysical
mediatoimproveperformance.
()

()BasicConceptsofRMANPerformanceTuning
TuningRMANperformancerequiresadetailedunderstandingofhowRMANcreatesabackup.As
explainedin"RMANChannels"(rcmarchi.htm#i1012864),theworkofabackupisperformedbyoneormore
channels.Achannel(glossary.htm#i432240)representsastreamofbytestoastoragedevice.
Forthepurposesofillustration,youcanthinkofthebytestreamaspassingfromtheinputbuffersin
memorythroughtheCPUtotheoutputbuffers,andfromtheretothestoragedevice.Todirectabackupto
twotapedevices,youallocatetwotapechannelssothateachbytestreamgoestoadifferentdevice.
Theworkofeachchannel,whetheroftypediskorSBT,issubdividedintothefollowingdistinctphases:

ReadPhase
AchannelreadsblocksfromdiskintoinputI/Obuffers.
CopyPhase
Achannelcopiesblocksfrominputbufferstooutputbuffersandperformsadditionalprocessingon
theblocks.
WritePhase
Achannelwritestheblocksfromoutputbufferstostoragemedia.Thewritephasecantakeeitherof
thefollowingmutuallyexclusiveforms,dependingonthetypeofbackupmedia:

WritePhaseforSBT

2. WritePhaseforDisk

Figure211depictstwochannelsbackingupdatastoredonthreedisks.Eachchannelreadsthedatainto
theinputbuffers,processesthedatawhilecopyingitfromtheinputtotheoutputbuffers,andthewrites
thedatafromtheoutputbufferstodisk.
()Figure211PhasesofaMultichannelBackuptoDisk

Descriptionof"Figure211PhasesofaMultichannelBackuptoDisk"(img_text/bradv042.htm)

Figure212alsodepictstwochannelsbackingupdatastoredonthreedisks,butoneofthedisksis
mountedremotelyoverthenetwork.Eachchannelreadsthedataintotheinputbuffers,processesthe
datawhilecopyingitfromtheinputtotheoutputbuffers,andthewritesthedatafromtheoutputbuffersto

tape.Channel1writesthedatatoalocallyattachedtapedrive,whereaschannel2sendsthedataover
thenetworktoaremotemediaserver.
()Figure212PhasesofaMultichannelBackuptoTape

Descriptionof"Figure212PhasesofaMultichannelBackuptoTape"(img_text/bradv041.htm)

Whenrestoringdata,achannelperformsthesestepsinreverseorderandreversesthereadingand
writingoperations.ThefollowingsectionsexplainRMANtuningconceptsintermsofabackup.
()

()ReadPhase
ThissectionexplainsfactorsthataffectperformancewhenanRMANchannelisreadingdatafromdisk:

AllocationofInputDiskBuffers
SynchronousandAsynchronousDiskI/O
DiskI/OSlaves
RATEChannelParameter

()

()AllocationofInputDiskBuffers
Duringabackup,anRMANchannelreadstheblocksfromtheinputfilesintoI/Odiskbuffers.The
databasefilesonthedisksubsystemcanbemanagedbyeitherAutomaticStorageManagement(ASM)
(glossary.htm#CHDBDJIJ)oranalternativevolumemanagerorfilesystem.Theconsiderationsforbackup
tuningchangedependingonwhetheryoumanagedatabasefileswithASM.
Theallocationoftheinputbuffersdependsonhowthefilesaremultiplexed.()()Backupmultiplexing
(glossary.htm#i999499)isRMAN'sabilitytoreadanumberoffilesinabackupsimultaneouslyfromdifferent
sourcesandthenwritethemtoasinglebackuppiece.Thelevelofmultiplexing(glossary.htm#CHDFBDDG),
whichisthenumberofinputfilessimultaneouslyreadandthenwrittenintothesamebackuppiece
(glossary.htm#i432114),isdeterminedbythealgorithmdescribedin"MultiplexedBackupSets"
(rcmcncpt.htm#i1015964).Reviewthissectionbeforeproceeding.
WhenanRMANchannelbacksupfilesfromdisk,itusestherulesdescribedinthefollowingtableto
determinehowlargetomaketheinputdiskbuffers.
()()Table211DatafileReadBufferSizingAlgorithm

Levelof
Multiplexing

InputDiskBufferSize

Lessthanorequalto
4

TheRMANchannelallocates16buffersofsize1MBsothatthetotalbuffer
sizeforalltheinputfilesis16MB.

Greaterthan4but
lessthanorequalto
8

TheRMANchannelallocatesavariablenumberofdiskbuffersofsize512KB
sothatthetotalbuffersizeforalltheinputfilesislessthan16MB.

Greaterthan8

TheRMANchannelallocates4diskbuffersof128KBforeachfile,sothatthe
totalbuffersizeforeachinputfileis512KB.

IntheexampleshowninFigure213,onechannelisbackingupfourdatafiles. MAXOPENFILES issetto4

and FILESPERSET issetto4.Thus,thelevelofmultiplexingis4.So,thetotalsizeofthebuffersforeach
datafileis4MB.Thecombinedsizeofallthebuffersis16MB.
()Figure213DiskBufferAllocation

Descriptionof"Figure213DiskBufferAllocation"(img_text/bradv011.htm)

IfachannelisbackingupfilesstoredinASM,thenthenumberofinputdiskbuffersequalsthenumberof
physicaldisksintheASMdiskgroup.Forexample,ifadatafileisstoredinanASMdiskgroupthat
contains16physicaldisks,thenthechannelallocates16inputbuffersforthedatafilebackup.
Ifachannelisrestoringabackupfromdisk,then4buffersareallocated.Thesizeofthebuffersis
dependentontheoperatingsystem.
()

()()SynchronousandAsynchronousDiskI/O
Whenachannelreadsfromorwritestodisk,theI/OiseithersynchronousI/O(glossary.htm#CHDDCBGC)or
asynchronousI/O(glossary.htm#CHDIIJAC).WhenthediskI/Oissynchronous,aserverprocesscanperform
onlyonetaskatatime.WhenthediskI/Oisasynchronous,aserverprocesscanbeginanI/Oandthen
performotherworkwhilewaitingfortheI/Otocomplete.RMANcanalsobeginmultipleI/Ooperations
beforewaitingforthefirsttocomplete.

WhenreadingfromanASMdiskgroup(glossary.htm#CHDHIIBA),youshoulduseasynchronousdiskI/Oif
possible.Also,ifachannelreadsfromarawdevice(glossary.htm#CHDHBJAG)managedwithavolume
manager,thenasynchronousdiskI/Oalsoworkswell.Someoperatingsystemssupportnative
asynchronousdiskI/O.Thedatabasetakesadvantageofthisfeatureifitisavailable.
()

()()DiskI/OSlaves
OnoperatingsystemsthatdonotsupportnativeasynchronousI/O,thedatabasecansimulateitwith
specialI/Oslaveprocesses.TheseprocessesarededicatedtoperformingI/Oonbehalfofanother
process.
YoucancontroldiskI/Oslavesbysettingthe DBWR_IO_SLAVES initializationparameter,whichisnot
dynamic.TheparameterspecifiesthenumberofI/Oserverprocessesusedbythedatabasewriter
process(DBWR).Bydefault,thevalueis0andI/Oserverprocessesarenotused.IfasynchronousI/Ois
disabled,thenRMANallocatesfourbackupdiskI/Oslavesforanynonzerovalueof DBWR_IO_SLAVES .
WhenattemptingtogetsharedbuffersforI/Oslaves,thedatabasedoesthefollowing:

If LARGE_POOL_SIZE isset,andifthe DBWR_IO_SLAVES parameterissettoanonzerovalue,thenthe

databaseattemptstogetmemoryfromthelargepool.Ifthisvalueisnotlargeenough,thenanerroris
recordedinthealertlog,thedatabasedoesnottrytogetbuffersfromthesharedpool,and
asynchronousI/Oisnotused.
If LARGE_POOL_SIZE isnotsetorissettozero,thenthedatabaseattemptstogetmemoryfromthe
sharedpool.
Ifthedatabasecannotgetenoughmemory,thenitobtainsI/ObuffermemoryfromthePGAandwritesa
messagetothe alert . log fileindicatingthatsynchronousI/Oisusedforthisbackup.

Thememoryfromthelargepoolisusedformanyfeatures,includingthesharedserver,parallelquery,and
RMANI/Oslavebuffers.ConfiguringthelargepoolpreventsRMANfromcompetingwithothersubsystems
forthesamememory.

Requestsforcontiguousmemoryallocationsfromthesharedpoolareusuallysmall(under5KB)insize.
However,itispossiblethatarequestforalargecontiguousmemoryallocationcaneitherfailorrequire
significantmemoryhousekeepingtoreleasetherequiredamountofcontiguousmemory.Althoughthe
sharedpoolmaybeunabletosatisfythismemoryrequest,thelargepoolisabletodoso.Thelargepool
doesnothavealeastrecentlyused(LRU)listthedatabasedoesnotattempttoagememoryoutofthe
largepool.
()

()RATEChannelParameter
Inthe ALLOCATE or CONFIGURECHANNEL commands,the RATE parameterspecifiesthebytes/second
thatarereadonachannel.YoucanusethisparametertosetanupperlimitforbytesreadsothatRMAN
doesnotconsumeexcessivediskbandwidthanddegradeonlineperformance.Essentially, RATE serves
asabackupthrottle.Forexample,ifyouset RATE1500K ,andifeachdiskdrivedelivers3MB/second,
thenthechannelleavessomediskbandwidthavailabletotheonlinesystem.
()

()CopyPhase
Inthisphase,achannelcopiesblocksfromtheinputtotheoutputbuffersandperformsadditional
processing.Forexample,ifachannelreadsdatafromdiskandbacksuptotape,thenthechannelcopies
thedatafromthediskbufferstotheoutputtapebuffers.
Thecopyphaseinvolvesthefollowingtypesofprocessing:

Validation
Compression
Encryption

Whenperformingvalidation(glossary.htm#i433696)oftheblocks,RMANchecksthemforcorruption.
ValidationisexplainedinChapter15,"ValidatingDatabaseFilesandBackups"(rcmvalid.htm#CHDBFAIF).
Typically,thisprocessingisnotCPUintensive.

Whenperformingbinarycompression(glossary.htm#CHDEEEDG),RMANappliesacompressionalgorithmto
thedatainbackupsets.BinarycompressioncanbeCPUintensive.Youcanchoosewhichcompression
algorithmthatRMANusesforbackups.Bydefault,RMANuses BZIP2 ,whichhasaverygood
compressionratio. ZLIB compression,whichrequiresa COMPATIBLE settingof11.0.0orhigher,isvery
fastbuthasalowercompressionratiothanotheralgorithms.Binarycompressionisexplainedin"Making
CompressedBackups"(rcmbckba.htm#i1034440).
Whenperformingbackupencryption(glossary.htm#CHDJDIEJ),RMANencryptsbackupsetsbyusingoneof
thealgorithmslisted()in V$RMAN_ENCRYPTION_ALGORITHMS .RMANoffersthreemodesofencryption:
transparent,passwordprotected,anddualmode.Backupencryptionisexplainedin"EncryptingRMAN
Backups"(rcmbckad.htm#CEGEJABH).BackupencryptioncanbeCPUintensive.
()

()WritePhaseforSBT
WhenbackinguptoSBT,RMANgivesthemediamanager(glossary.htm#i432922)astreamofbytesand
associatesauniquenamewiththisstream.Alldetailsofhowandwherethatstreamisstoredarehandled
entirelybythemediamanager.Thus,abackuptotapeinvolvestheinteractionofbothRMANandthe
mediamanager.
()

()RMANComponentofWritePhaseforSBT
TheRMANspecificfactorsaffectingtheSBTwritephaseareanalogoustothefactorsaffectingdiskreads.
Inbothcases,thebufferallocation,slaveprocesses,andsynchronousorasynchronousI/Oaffect
performance.
()

()()AllocationofTapeBuffers

IfyoubackuptoorrestorefromanSBT(glossary.htm#CHDCCBFI)device,thenbydefaultthedatabase
allocatesfourbuffersforeachchannelforthetapewriters(orreadsifrestoringdata).Thesizeofthetape
I/Obuffersisplatformdependent.Youcanchangethisvaluewiththe PARMS and BLKSIZE parametersof
the ALLOCATECHANNEL or CONFIGURECHANNEL command.
()Figure214AllocationofTapeBuffers

Descriptionof"Figure214AllocationofTapeBuffers"(img_text/bradv013.htm)

()

()TapeI/OSlaves

RMANallocatesthetapebuffersintheSGAorthePGA,dependingonwhetherI/Oslavesareused.Ifyou
settheinitializationparameter BACKUP_TAPE_IO_SLAVES=true ,thenRMANallocatestapebuffersfrom
theSGA.Tapedevicescanonlybeaccessedbyoneprocessatatime,soRMANstartsasmanyslaves
asnecessaryforthenumberoftapedevices.Ifthe LARGE_POOL_SIZE initializationparameterisalsoset,
thenRMANallocatesbuffersfromthelargepool.Ifyouset BACKUP_TAPE_IO_SLAVES=false ,then
RMANallocatesthebuffersfromthePGA.
IfyouuseI/Oslaves,thensetthe LARGE_POOL_SIZE initializationparametertodedicateSGAmemoryto
holdingtheselargememoryallocations.ThisparameterpreventsRMANI/Obuffersfromcompetingwith
thelibrarycacheforSGAmemory.IfI/OslavesfortapeI/Owererequestedbutthereisnotenoughspace
intheSGAforthem,slavesarenotused,andamessageappearsinthealertlog.
Notethat BACKUP_TAPE_IO_SLAVES specifieswhetherRMANusesslaveprocesses,notthenumberof
slaveprocesses.Tapedevicescanonlybeaccessedbyoneprocessatatime,andRMANusesthe
numberofslavesnecessaryforthenumberoftapedevices.
()

()()SynchronousandAsynchronousI/O

WhenanSBTchannelreadsorwritesdatatotape,theI/Oisalwayssynchronous.FortapeI/O,each
channelallocated(whethermanuallyorautomatically)correspondstoaserverprocess,calledherea
channelprocess.

ThefollowingfigureshowssynchronousI/Oinabackuptotape.
()Figure215SynchronousTapeI/O

Descriptionof"Figure215SynchronousTapeI/O"(img_text/bradv015.htm)

Thefollowingstepsoccur:
Thechannelprocesscomposesatapebuffer.
Thechannelprocessexecutesmediamanagercodethatprocessesthetapebufferandinternalizes
itforfurtherprocessingandstoragebythemediamanager.
Themediamanagercodereturnsamessagetotheserverprocessstatingthatithascompleted
writing.
Thechannelprocesscaninitiateanewtask.

ThefollowingfigureshowsasynchronousI/Oinatapebackup.AsynchronousI/Ototapeissimulatedby
usingtapeslaves.Inthiscase,eachallocatedchannelcorrespondstoaserverprocess,whichinthe
explanationwhichfollowsisidentifiedasachannelprocess.Foreachchannelprocess,onetapeslaveis
started(ormorethanone,inthecaseofmultiplecopies).
()Figure216AsynchronousTapeI/O

Descriptionof"Figure216AsynchronousTapeI/O"(img_text/bradv012.htm)

Thefollowingstepsoccur:
Achannelprocesswritesblockstoatapebuffer.
Thechannelprocesssendsamessagetothetapeslaveprocesstoprocessthetapebuffer.The
tapeslaveprocessexecutesmediamanagercodethatprocessesthetapebufferandinternalizesit
sothatthemediamanagercanprocessit.
Whilethetapeslaveprocessiswriting,thechannelprocessisfreetoreaddatafromthedatafiles
andpreparemoreoutputbuffers.
Afterthetapeslavechannelreturnsfromthemediamanagercode,itrequestsanewtapebuffer,
whichusuallyisready.Thuswaitingtimeforthechannelprocessisreduced,andthebackupis
completedfaster.

()

()MediaManagerComponentofWritePhaseforSBT
Thefollowingfactorsaffectthespeedofthebackuptotape:

NetworkThroughput
NativeTransferRate
TapeCompression
TapeStreaming
PhysicalTapeBlockSize

()

()NetworkThroughput

Ifthetapedeviceisremote,thenthemediamanagerneedstotransferdataoverthenetwork.For
example,anadministrativedomaininOracleSecureBackupcancontainmultiplenetworkedclienthosts,
mediaservers,andtapedevices.Ifthedatabaseisononehost,buttheoutputtapedriveisattachedtoa
differenthost,thenOracleSecureBackupmanagesthedatatransferoverthenetwork.Thenetwork
throughputistheupperlimitforbackupperformance.
()

()NativeTransferRate

Thetapenativetransferrate(glossary.htm#CHDDDBEG)isthespeedofwritingtoatapewithout
compression.Thisspeedrepresentstheupperlimitofthebackuprate.Theupperlimitofyourbackup
performanceshouldbetheaggregatetransferrateofallofyourtapedrives.Ifyourbackupisalready
performingatthatrate,andifitisnotusinganexcessiveamountofCPU,thenRMANperformancetuning
willnothelp.
()

()TapeCompression

Theleveloftapecompressionisveryimportantforbackupperformance.Ifthetapehasgood
compression,thenthesustainedbackuprateisfaster.Forexample,ifthecompressionratiois2:1and
nativetransferrateofthetapedriveis6MB/s,thentheresultingbackupspeedis12MB/s.Inthiscase,
RMANmustbeabletoreaddiskswithathroughputofmorethan12MB/sorthediskbecomesthe
bottleneckforthebackup.

Note:
Youshouldnotusebothtapecompressionprovidedbythemediamanagerandbinary
compressionprovidedbyRMAN.Ifthemediamanagercompressionisefficient,thenitis
usuallythebetterchoice.UsingRMANcompressedbackupsetscanbeaneffectivealternative
toreducebandwidthusedtomoveuncompressedbackupsetsoveranetworktothemedia
manager,iftheCPUoverheadrequiredtocompressthedatainRMANisacceptable.

()

()TapeStreaming

Tapestreamingduringwriteoperationshasamajorimpactontapebackupperformance.Almostalltape
drivescurrentlyonthemarketarefixedspeed,streamingtapedrives.Becausesuchdrivescanonlywrite
dataatonespeed,whentheyrunoutofdatatowritetotape,thetapemustslowdownandstop.Typically,
whenthedrive'sbufferempties,thetapeismovingsoquicklythatitactuallyovershootstocontinue
writing,thedrivemustrewindthetapetolocatethepointwhereitstoppedwriting.
()

()PhysicalTapeBlockSize

Thephysicaltapeblocksizecanaffectbackupperformance.Theblocksizeistheamountofdatawritten
bymediamanagementsoftwaretoatapeinonewriteoperation.Ingeneral,thelargerthetapeblocksize,
thefasterthebackup.NotethatphysicaltapeblocksizeisnotcontrolledbyRMANortheOracledatabase
server,butbymediamanagementsoftware.Seeyourmediamanagementsoftware'sdocumentationfor
details.
()

()WritePhaseforDisk
Theprincipalfactoraffectingthewritephasefordiskisthebuffersize.Whentheoutputofthebackup
residesondisk,eachchannelallocates4outputbuffersof1MBeach.Thediskchannelwritestheblocks
tothedisksubsystem.Notethatthereadphasewhenrestoringfilesisjustlikethewritephasewhen
backingupfiles,excepttheblocksmoveintheoppositedirection.

IfRMANreadsfromadiskasynchronously,thenitwritestothediskasynchronously.Whenwritingtodisk,
youcanmakeuseofdiskI/Oslavesjustaswhenreading.
IfRMANisbackingupfilestoadiskbasedoutputdestinationstripedovermultipledisks,thenyoucan
allocatemultiplechannels.Thenumberofchannelsislimitedonlytothenumberofdisksoverwhichthe
destinationisstriped.ASMisoneexampleadestinationstripedovermultipledisks.
()

()UsingV$ViewstoDiagnoseRMAN

PerformanceProblems
Typically,youbeginthetuningprocessbyusing V$ viewstodeterminewhereRMANbackupandrestore
operationsareencounteringproblems.
()

()MonitoringRMANJobProgresswith

V$SESSION_LONGOPS
()()You()canmonitortheprogressofbackupsandrestorejobsbyqueryingtheview

V$SESSION_LONGOPS .RMANusestwotypesofrows()in V$SESSION_LONGOPS :detailandaggregate

rows.
Detailrowsdescribethefilesbeingprocessedbyonejobstep,whileaggregaterowsdescribethefiles
processedbyalljobstepsinanRMANcommand.Ajobstepisthecreationorrestoreofonebackupsetor
datafilecopy.Detailrowsareupdatedwitheverybufferthatisreadorwrittenduringthebackupstep,so
theirgranularityofupdateissmall.Aggregaterowsareupdatedwheneachjobstepcompletes,sotheir
granularityofupdateislarge.
Table212describesthecolumnsin V$SESSION_LONGOPS thataremostrelevantforRMAN.Typically,you
willviewthedetailrowsratherthantheaggregaterowstodeterminetheprogressofeachbackupset.
()()Table212ColumnsofV$SESSION_LONGOPSRelevantforRMAN

Column

DescriptionforDetailRows

SID

TheserversessionIDcorrespondingtoanRMANchannel.

SERIAL#

Theserversessionserialnumber.Thisvaluechangeseachtimeaserversessionis
reused.

OPNAME

Atextdescriptionoftherow.Examplesofdetailsrowsinclude RMAN: datafile copy ,

RMAN: full datafile backup ,and RMAN: full datafile restore .
Note: RMAN: aggregate input and RMAN: aggregate output aretheonly
aggregaterows.

CONTEXT

Forbackupoutputrows,thisvalueis 2 .Forallotherrowsexceptproxycopy(which
doesnotupdatethiscolumn),thevalueis 1 .

SOFAR

Themeaningofthiscolumndependsonthetypeofoperationdescribedbythisrow:

Forimagecopies,thenumberofblocksthathavebeenread.
Forbackupinputrows,thenumberofblocksthathavebeenreadfromthefilesbeing
backedup.
Forbackupoutputrows,thenumberofblocksthathavebeenwrittentothebackup
piece.
Forrestores,thenumberofblocksthathavebeenprocessedtothefilesthatare
beingrestoredinthisonejobstep.
Forproxycopies,thenumberoffilesthathavebeencopied.

TOTALWORK

Themeaningofthiscolumndependsonthetypeofoperationdescribedbythisrow:

Forimagecopies,thetotalnumberofblocksinthefile.
Forbackupinputrows,thetotalnumberofblockstobereadfromallfilesprocessed
inthisjobstep.
Forbackupoutputrows,thevalueis 0 becauseRMANdoesnotknowhowmany
blocksthatitwillwriteintoanybackuppiece.
Forrestores,thetotalnumberofblocksinallfilesrestoredinthisjobstep.
Forproxycopies,thetotalnumberoffilestobecopiedinthisjobstep.

Eachserversessionperformingabackuporrestorejobreportsitsprogresscomparedtothetotalwork
requiredforajobstep.Forexample,ifyourestorethedatabasewithtwochannels,andeachchannelhas
twobackupsetstorestore(atotaloffoursets),theneachserversessionreportsitsprogressthrougha
singlebackupset.Whenasetiscompletelyrestored,RMANbeginsreportingprogressonthenextsetto
restore.
()TomonitorRMANjobprogress:

BeforestartingtheRMANjob,createascriptfile(called,forthisexample, longops )containingthe

followingSQLstatement:

SELECTSID,SERIAL#,CONTEXT,SOFAR,TOTALWORK,
ROUND(SOFAR/TOTALWORK*100,2)"%_COMPLETE"
FROMV$SESSION_LONGOPS
WHEREOPNAMELIKE'RMAN%'
ANDOPNAMENOTLIKE'%aggregate%'
ANDTOTALWORK!=0
ANDSOFAR<>TOTALWORK

StartRMANandconnecttothetargetdatabaseandrecoverycatalog(ifused).
StartanRMANjob.Forexample,enter:
RMAN>RESTOREDATABASE

WhiletheRMANjobisrunning,startSQL*Plusandconnecttothetargetdatabase,andexecute
the longops scripttochecktheprogressoftheRMANjob.IfyourepeatthequerywhiletheRMAN
jobprogresses,thenyouseeoutputsuchasthefollowing:

SQL>@longops
SIDSERIAL#CONTEXTSOFARTOTALWORK%_COMPLETE

8191103773661728.34
SQL>@longops
SIDSERIAL#CONTEXTSOFARTOTALWORK%COMPLETE

8191215133661758.75
SQL>@longops
SIDSERIAL#CONTEXTSOFARTOTALWORK%COMPLETE

8191296413661780.95
SQL>@longops
SIDSERIAL#CONTEXTSOFARTOTALWORK%COMPLETE

8191358493661797.9
SQL>@longops
norowsselected

Ifyourunthe longops scriptatintervalsoftwominutesormoreandthe % _ COMPLETE column

doesnotincrease,thenRMANisencounteringaproblem.Referto"MonitoringRMANInteraction
withtheMediaManager"(rcmtroub.htm#i1008347)toobtainmoreinformation.

Ifyoufrequentlymonitortheexecutionoflongrunningtasks,thenyoucouldcreateashellscriptorbatch
fileunderyourhostoperatingsystemthatrunsSQL*Plustoexecutethisqueryrepeatedly.
()

()IdentifyingBottleneckswithV$BACKUP_SYNC_IOand

V$BACKUP_ASYNC_IO

Youcanuse()the V$BACKUP_SYNC_IO ()and V$BACKUP_ASYNC_IO viewstodeterminethesourceof

backuporrestorebottlenecksandtoseedetailedprogressofbackupjobs.
V$BACKUP_SYNC_IO containsrowswhentheI/Oissynchronoustotheprocess(orthreadonsome

platforms)performingthebackup. V$BACKUP_ASYNC_IO containsrowswhentheI/Oisasynchronous.

AsynchronousI/OisobtainedeitherwithI/Oprocessesorbecauseitissupportedbytheunderlying
operatingsystem.
Theresultsofabackuporrestorejobremaininmemoryuntilthedatabaseinstanceshutsdown.Thus,
youcanquerytheviewsafterthejobcompletes.
()TodeterminewhetherthetapeisstreamingwhentheI/Oissynchronous:

StartSQL*Plusandconnecttothetargetdatabase.
Querythe EFFECTIVE_BYTES_PER_SECOND columninthe V$BACKUP_SYNC_IO or
V$BACKUP_ASYNC_IO view.

If EFFECTIVE_BYTES_PER_SECOND islessthantherawcapacityofthehardware,thenthetapeis
notstreaming.If EFFECTIVE_BYTES_PER_SECOND isgreaterthantherawcapacityofthehardware,
thetapemayormaynotbestreaming.Compressionmaycausethe
EFFECTIVE_BYTES_PER_SECOND tobegreaterthanthespeedofrealI/O.

SeeAlso:
OracleDatabaseReference(../../server.111/b28320/toc.htm)formoreinformationabouttheseviews

()

()IdentifyingBottleneckswithSynchronousI/O

WithsynchronousI/O,itisdifficulttoidentifyspecificbottlenecksbecauseallsynchronousI/Oisa
bottlenecktotheprocess.TheonlywaytotunesynchronousI/Oistocomparetherate(inbytes/second)
withthedevice'smaximumthroughputrate.Iftherateislowerthantheratethatthedevicespecifies,then
considertuningthisaspectofthebackupandrestoreprocess.
()TodeterminetherateofsynchronousI/O:

StartSQL*Plusandconnecttothetargetdatabase.
Querythe DISCRETE_BYTES_PER_SECOND columninthe V$BACKUP_SYNC_IO viewtodisplaythe
I/Orate.
Ifyouseedatain V$BACKUP_SYNC_IO ,thentheproblemisthatyouhavenotenabled
asynchronousI/OoryouarenotusingdiskI/Oslaves.

()

()IdentifyingBottleneckswithAsynchronousI/O
()()Longwaitsarethenumberoftimesthebackuporrestoreprocesstoldtheoperatingsystemtowait

untilanI/Owascomplete.()()Shortwaitsarethenumberoftimesthebackuporrestoreprocessmade
anoperatingsystemcalltopollforI/Ocompletioninanonblockingmode.Readyindicatesthenumberof

timeswhenI/Owasalreadyreadyforuse,sotherewasnoneedtomakeanoperatingsystemcalltopoll
forI/Ocompletion.
TableofContents
(toc.htm) OracleDatabaseBackupandRecoveryUser'sGuide (toc.htm)

Preface(preface.htm#sthref2)

()TodeterminetherateofasynchronousI/O:

What'sNewinBackupandRecovery?(wnbradv.htm#BRADV021)
IntroductiontoBackupandRecovery(rcmintro.htm#BRADV8001)
StartSQL*Plusandconnecttothetargetdatabase.
GettingStartedwithRMAN(rcmquick.htm#BRADV89346)

RecoveryManagerArchitecture(rcmarchi.htm#BRADV001)

Querythe LONG_WAITS and IO_COUNT columnsinthe V$BACKUP_SYNC_IO viewtodisplaytheI/O

StartingandInteractingwiththeRMANClient(rcmcnctg.htm#BRADV005)

rate.

ConfiguringtheRMANEnvironment(rcmconfb.htm#BRADV8002)
ConfiguringtheRMANEnvironment:AdvancedTopics
(rcmconfa.htm#BRADV006)

RMANBackupConcepts(rcmcncpt.htm#BRADV002)

Thesimplestwaytoidentifythebottleneckistofindthedatafilethathasthelargestratiofor
LONG_WAITS dividedby IO_COUNT .Forexample,youcanusethefollowingquery:

BackingUptheDatabase(rcmbckba.htm#BRADV8003)

BackingUptheDatabase(rcmbckba.htm#BRADV8003)

SELECTLONG_WAITS/IO_COUNT,FILENAME
BackingUptheDatabase:AdvancedTopics(rcmbckad.htm#BRADV007)
FROMV$BACKUP_ASYNC_IO
ReportingonRMANOperations(rcmreprt.htm#BRADV8004)
WHERELONG_WAITS/IO_COUNT>0
MaintainingRMANBackupsandRepositoryRecords
ORDERBYLONG_WAITS/IO_COUNTDESC

(rcmmaint.htm#BRADV8007)

ManagingaRecoveryCatalog(rcmcatdb.htm#BRADV8015)
RMANDataRepairConcepts(rcmrvcon.htm#BRADV89703)
DiagnosingandRepairingFailureswithDataRecoveryAdvisor
(rcmrepai.htm#BRADV246)

Note:

ValidatingDatabaseFilesandBackups(rcmvalid.htm#BRADV90063)

IfyouhavesynchronousI/Obutyouhaveset BACKUP_DISK_IO_SLAVES ,thentheI/Owillbe

PerformingFlashbackandDatabasePointinTimeRecovery
displayedin V$BACKUP_ASYNC_IO .

(rcmflash.htm#BRADV80055)

PerformingCompleteDatabaseRecovery(rcmcomre.htm#BRADV8005)
PerformingBlockMediaRecovery(rcmblock.htm#BRADV89781)
PerformingRMANRecovery:AdvancedScenarios(rcmadvre.htm#BRADV008)
PerformingRMANTablespacePointinTimeRecovery(TSPITR)

SeeAlso:

(rcmtspit.htm#BRADV009)

TuningRMANPerformance(rcmtunin.htm#BRADV011)OracleDatabaseReference(../../server.111/b28320/dynviews_part.htm#REFRN003)fordescriptionsofthe
TroubleshootingRMANOperations(rcmtroub.htm#BRADV012)
V$BACKUP_SYNC_IO and V$BACKUP_ASYNC_IO views
DuplicatingaDatabase(rcmdupdb.htm#BRADV010)
CreatingTransportableTablespaceSets(rcmttbsb.htm#BRADV05141)
TransportingDataAcrossPlatforms(rcmxplat.htm#BRADV89976)
()
PerformingASMDataMigration(rcmasmmi.htm#BRADV12000)

MakingUserManagedDatabaseBackups(osbackup.htm#BRADV016)

()TuningRMANBackupPerformance()

PerformingUserManagedDatabaseFlashbackandRecovery
(osrecvry.htm#BRADV017)

PerformingUserManagedRecovery:AdvancedScenarios
Manyfactorscanaffectbackupperformance.Often,findingthesolutiontoaslowbackupisaprocessof
(osadvsce.htm#BRADV018)

trialanderror.Toobtainthebestperformanceforabackup,followthestepsinthissectioninsequential
order.

Glossary(glossary.htm#i433934)

Download

Thissectioncontainsthefollowingsteps:

Categories
Home(../../index.htm)
BookList(../../nav/portal_booklist.htm)

Step1:RemovetheRATEParameterfromChannelSettings
Step2:IfYouUseSynchronousDiskI/O,SetDBWR_IO_SLAVES
Step3:IfYouFailtoAllocateSharedMemory,SetLARGE_POOL_SIZE

Step4:TunetheRead,Write,andCopyPhases

()

()Step1:RemovetheRATEParameterfromChannel

Settings
Asexplainedin"RATEChannelParameter",the RATE parameteronachannelisintendedtoreduce,
ratherthanincrease,backupthroughputsothatmorediskbandwidthisavailableforotherdatabase
operations.Ifthebackupisnotstreamingtotape,thenmakesurethatthe RATE parameterisnotset.

()ToremovetheRATEparameter:

Examineyourbackupscript.
Dooneofthefollowing:

Ifthebackupisina RUN command,thenremovethe RATE parameter,ifitisspecified,fromthe

ALLOCATE command.Skiptheremainingsteps.

2. Ifthebackupisnotina RUN command,thenstartRMAN,connecttothetargetdatabase,andproceed

tothenextstep.
Executethe SHOWALL commandtoshowthecurrentlyconfiguredsettings.
Removethe RATE parameter,ifitisset,fromthe CONFIGURECHANNEL command.

()

()Step2:IfYouUseSynchronousDiskI/O,Set

DBWR_IO_SLAVES
Asexplainedin"SynchronousandAsynchronousDiskI/O",someoperatingsystemssupportnative
asynchronousI/O.IfandonlyifyourdiskdoesnotsupportasynchronousI/O,thenset DBWR_IO_SLAVES .
Anynonzerovaluefor DBWR_IO_SLAVES causesafixednumberofdiskI/Oslavestobeusedforbackup
andrestore,whichsimulatesasynchronousI/O.
()ToenablediskI/Oslaves:

StartSQL*Plusandconnecttothetargetdatabase.
Shutdownthedatabase.
Set DBWR_IO_SLAVES initializationparametertoanonzerovalue.
Bysetting DBWR_IO_SLAVES ,thedatabasewriterprocesseswilluseslaves.Thus,youmayneedto
increasethevalueofthe PROCESSES initializationparameter.
Restartthedatabase.
RestarttheRMANbackup.

()

()Step3:IfYouFailtoAllocateSharedMemory,Set

LARGE_POOL_SIZE
Setthe LARGE_POOL_SIZE initializationparameterifthedatabasereportsanerrorinthealertlogstating
thatitdoesnothaveenoughmemoryandthatitwillnotstartI/Oslaves.Themessageshouldresemble
thefollowing:

ksfqxcre:failuretoallocatesharedmemorymeanssyncI/Owillbeusedwhenever
asyncI/Otofilenotsupportednatively

ThelargepoolisusedforRMANandforotherpurposes,soitstotalsizeshouldaccommodatealluses.
Thisisespeciallytrueif DBWR_IO_SLAVES hasbeensetandtheDBWRprocessneedsbuffers.

()Tosetthelargepoolsize:

StartSQL*Plusandconnecttothetargetdatabase.
Optionally,()query V$SGASTAT.POOL todeterminewhichpool(sharedpoolorlargepool)the
memoryforanobjectresides.
Setthe ()()LARGE_POOL_SIZE initializationparameterinthetargetdatabase.
Youcanexecutean ALTERSYSTEMSET statementtosettheparameterdynamically.Theformula
forsetting LARGE_POOL_SIZE isasfollows:
LARGE_POOL_SIZE=number_of_allocated_channels*
(16MB+(4*size_of_tape_buffer))

RestarttheRMANbackup.

SeeAlso:
OracleDatabaseConcepts(../../server.111/b28318/toc.htm)formoreinformationaboutthelargepool,
andOracleDatabaseReference(../../server.111/b28320/toc.htm)forcompleteinformationabout
initializationparameters

()

()Step4:TunetheRead,Write,andCopyPhases

Thereareseveraltasksyoucanperformtoidentifyandremedybottlenecksthataffectbackup
performance.
()

()UsingBackupValidationToDistinguishBetweenReadandWriteBottlenecks
OnereliablewaytodeterminewhethertheoutputdeviceorinputdiskI/Oisthebottleneckinagiven
backupjobistocomparethetimerequiredtorunbackuptaskswiththetimerequiredtorun
BACKUPVALIDATE ofthesametasks. BACKUPVALIDATE ofabackupperformsthesamediskreadsasa
realbackupbutperformsnoI/Otoanoutputdevice.
()Tocomparebackupandvalidationtimes:

MakesureyourNLSenvironmentdateformatvariableissettoshowthetime.Forexample,setthe
NLSvariablesasfollows:
setenvNLS_LANGAMERICAN_AMERICA.WE8DEC
setenvNLS_DATE_FORMAT"MM/DD/YYYYHH24:MI:SS"

Edityourbackupscripttousethe BACKUPVALIDATE commandinsteadofthe BACKUP command.

Runthebackupscript.
ExaminetheRMANoutputandcalculatethedifferencebetweenthetimesdisplayedinthe
Startingbackupat and Finishedbackupat messages.
Editthebackupscripttousethe BACKUP commandinsteadofthe BACKUPVALIDATE command.
Runthebackupscript.
ExaminetheRMANoutputandcalculatethedifferencebetweenthetimesdisplayedinthe
Startingbackupat and Finishedbackupat messages.
Comparethebackuptimesforthevalidationandrealbackup.

Ifthetimeforthe BACKUPVALIDATE totapeisaboutthesameasthetimeforarealbackupto

tape,thenreadingfromdiskisthelikelybottleneck.See"TuningtheReadPhase".
Ifthetimeforthe BACKUPVALIDATE totapeissignificantlylessthanthetimeforarealbackupto
tape,thenwritingtotheoutputdeviceisthelikelybottleneck.See"TuningtheCopyandWrite
Phases".

()

()TuningtheReadPhase
RMANmaynotbeabletosenddatablockstotheoutputdevicefastenoughtokeepitoccupied.For
example,duringanincrementalbackup(glossary.htm#i432786),RMANonlybacksupblockschangedsince
apreviousdatafilebackupaspartofthesamestrategy.Ifyoudonotturnonblockchangetracking
(glossary.htm#CHDIFJHF),thenRMANmustscanwholedatafilesforchangedblocks,andfilloutputbuffersas
itfindssuchblocks.Iffewblockschanged,andifRMANismakinganSBTbackup,thenRMANmaynotfill
outputbuffersfastenoughtokeepthetapedrivestreaming.
Youcanimprovebackupperformancebyadjustingthelevelofmultiplexing(glossary.htm#CHDFBDDG),
whichisnumberofinputfilessimultaneouslyreadandthenwrittenintothesameRMANbackuppiece.
Thelevelofmultiplexingistheminimumofthe MAXOPENFILES settingonthechannelandthenumberof
inputfilesplacedineachbackupset.Thefollowingtablemakesrecommendationsforadjustingthelevel
ofmultiplexing.
()()Table213AdjustingtheLevelofMultiplexing

ASM

StripedDisk

Recommendation

No

Yes

Increasethelevelof
multiplexing.Determinewhich
istheminimum,
MAXOPENFILES orthenumber
offilesineachbackupset,and
thenincreasethisvalue.

Inthisway,youincreasethe
rateatwhichRMANfillstape
buffers,whichmakesitmore
likelythatbuffersaresentto
themediamanagerfast
enoughtomaintainstreaming.

No

No

Increasethe MAXOPENFILES
settingonthechannel.

Yes

n/a

Setthe MAXOPENFILES
parameteronthechannelto1
or2.

SeeAlso:
"MultiplexedBackupSets"(rcmcncpt.htm#i1015964)tolearnhowthe MAXOPENFILES and
FILESPERSET settingsaffectthelevelofmultiplexing

"IncrementalBackups"(rcmcncpt.htm#i1007616)foraconceptualoverview

()

()TuningtheCopyandWritePhases
Ifthereadphaseisperformingwell,thenthecopyorwritephasesareprobablythebottleneck.In
particular,ifRMANissendingdatablockstothetapedrivefastenoughtosupportstreaming,butthetape
isnotstreaming,thentheSBTwritephaseisthebottleneck.Trytoimproveperformanceasfollows:

Ifthebackupisafullbackup(glossary.htm#i432658),thenconsiderusingincrementalbackups.
Incrementallevel1backupswriteonlythechangedblocksfromdatafilestotape,sothatanybottleneck
onwritingtotapehaslessimpactonyouroverallbackupstrategy.Inparticular,iftapedrivesarenot
locallyattachedtothenodeofthedatabasebeingbackedup,thenincrementalbackupscanbefaster.
See"MakingandUpdatingIncrementalBackups"(rcmbckba.htm#i1034163).
Ifthebackupusesthe BZIP2 compressionalgorithm,whichisthedefault,thenchangethe
compressionalgorithmfrom BZIP2 to ZLIB .
ZLIB islessCPUintensivethan BZIP2 .See"ConfiguringtheBackupCompressionAlgorithm"
(rcmconfa.htm#CHDEHCEB).

IfthedatabasehostusesmultipleCPUs,andifthebackupusesbinarycompression,thenincreasethe
numberofchannels.
Ifthebackupisencrypted,thenchangetheencryptionalgorithmto AES128 .
The AES128 algorithmistheleastCPUintensive.See"ConfiguringtheBackupEncryptionAlgorithm"
(rcmconfa.htm#CHDFAHHJ).

IfRMANisbackinguptotape,thentrythefollowingadjustments:

AdjustthesizeofthetapeI/Obuffers.
Usethe PARMS and BLKSIZE parametersofthe ALLOCATECHANNEL or CONFIGURECHANNEL
commandtosetthesize.ThesizeofthetapeI/Obuffersisplatformdependent.The BLKSIZE setting
overridesthedefault.
Adjustsettingsinthemediamanagementsoftware.
Anumberofmediamanagersettings,includingthetapeblocksize,mayaffectbackupperformance.

IfRMANisbackingupfilestoASM,thenincreasethenumberofchannels.
Forexample,ifRMANisbackingupthedatabasetoasinglediskgroupwith16physicaldisks,then
allocateorconfigureatleast4diskchannels,uptoamaximumof16.

(http://www.oracle.com/us/legal/terms/index.html)

ContactUs (http://www.oracle.com/us/corporate/contact/index.html)

YourPrivacyRights (http://www.oracle.com/us/legal/privacy/index.html)

Copyright2015,Oracleand/oritsaffiliates.Allrightsreserved.

LegalNotices (http://www.oracle.com/us/legal/index.html)

TermsofUse

AboutOracle(http://www.oracle.com/corporate/index.html)