Networker

Re: [Networker] Oracle RMAN backup questions

2006-11-30 18:27:34
Subject: Re: [Networker] Oracle RMAN backup questions
From: Albert Eddie Contractor AFRPA CIO/IT <Eddie.Albert AT AFRPA.PENTAGON.AF DOT MIL>
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Date: Thu, 30 Nov 2006 18:21:25 -0500
That depends...

If our data streams are sent to more drives (4 data streams to /Tape1 +
4 data streams to /Tape0) among other things you have more tapes to
track and to restore FROM more tape changes mean slower restore times as
well.

We have been fairly lucky on the RESTORE front. Backups are
daily/nightly/weekly. Restores here are a few times a month.

Once the proper tape is in the machine, restore time NO MATTER THE SIZE
has been between seconds to a few minutes! Granted we have never had
catastrophic failure requiring a complete exchange server/Database
restore...yet.

But our Disaster Recovery Drills have been flawless with Server restores
(AFTER OS install) has been no more than 2 hours. 

<Insert YOUR discussion here> /ALE

> -----Original Message-----
> From: EMC NetWorker discussion 
> [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU] On Behalf Of George Sinclair
> Sent: Thursday, November 30, 2006 5:14 PM
> To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
> Subject: Re: [Networker] Oracle RMAN backup questions
> 
> My bust. What I think I meant was that increasing the 
> channels will increase the number of save sets that are 
> *simultaneously* written to tape, but not the total number. 
> The total number will not change, only the filesperset will 
> change this. BUT, increasing the number of simultaneous save 
> sets being written to tape would increase recover time, right?
> 
> Guess I'm trying to understand how filesperset would affect 
> recover time.
> 
> George
> 
> Doug Brown wrote:
> 
> >George
> >
> >Your statement
> >
> >Clearly, the more channels you set, the more save sets you 
> end up with 
> >and thus the more save sets will be interleaved to the tape and the 
> >longer recovers will take, so there's a trade off between increased 
> >write speeds versus recovers. BUT, the more save sets you break the 
> >Oracle backups into the smaller those save sets, and that could be a 
> >good thing, but the more filesperset, the larger those 
> savesets, too. 
> >Hmm ... OK, all fine and well, but:
> >
> >is incorrect.
> >
> >The less files allocated per channel will result in more 
> savesets.   By 
> >default Oracle will try to divide the number of files into 
> the number 
> >of channels allocated as from the oracle whitepaper tuning recover 
> >manager ( RMAN )
> >
> >Backup Multiplexing
> >One channel can simultaneously read more than one file. The level of 
> >multiplexing is the number of files read simultaneously on a single 
> >channel and then written to the same backup piece. The degree of 
> >multiplexing depends on the FILESPERSET parameter of the 
> BACKUP command 
> >as well as the MAXOPENFILES parameter of the CONFIGURE CHANNEL or 
> >ALLOCATE CHANNEL commands.
> >The number of files in each backup set is the lesser of 
> FILESPERSET and 
> >the number of files read by each channel. The level of 
> multiplexing is 
> >the lesser of MAXOPENFILES and the number of files in each 
> backup set. 
> >For example, assume that you back up two datafiles with one channel. 
> >You set FILESPERSET to 3 and set MAXOPENFILES to 8. In this 
> case, the 
> >number of files in each backup set is 2 (the lesser of 
> FILESPERSET and 
> >the files read by each channel), and so the level of 
> multiplexing is 2 
> >(the lesser of MAXOPENFILES and the number of files in each backup 
> >set).
> >Assume a different case in which each channel reads fifteen 
> datafiles, 
> >FILESPERSET=10, and MAXOPENFILES=8. You can calculate the level of 
> >multiplexing as follows:
> >min(min(15, 10), 8) = 8
> >The default values are 16 for MAXOPENFILES and 64 for FILESPERSET.
> >
> >
> >
> >
> >
> >George Sinclair <George.Sinclair AT NOAA DOT GOV> Sent by: EMC NetWorker 
> >discussion <NETWORKER AT LISTSERV.TEMPLE DOT EDU>
> >11/30/2006 01:09 PM
> >Please respond to
> >EMC NetWorker discussion <NETWORKER AT LISTSERV.TEMPLE DOT EDU>; Please 
> >respond to George Sinclair <George.Sinclair AT NOAA DOT GOV>
> >
> >
> >To
> >NETWORKER AT LISTSERV.TEMPLE DOT EDU
> >cc
> >
> >Subject
> >[Networker] Oracle RMAN backup questions
> >
> >
> >
> >
> >
> >
> >Hi,
> >
> >Several questions here on RMAN Oracle backups via NMO. We're running 
> >Oracle 10g, with NW 7.2.2.
> >Our drive target sessions are set to 5. These are SDLT 600 drives.
> >
> >Some of these questions may be moot since there's so many variables 
> >that will determine what settings work best for your shop but really 
> >just wanted to get an idea of what others are doing and 
> what, if any, 
> >bad experiences, pit falls or suggestions you could offer.
> >
> >In testing Oracle backups and recovers, we've been playing with a 
> >rather small test database. We've tried multiple channels, 
> and multiple 
> >filesperset, and we don't really notice any major performance 
> >difference, but obviously, the more channels, the more concurrent 
> >streams we can send to the device, so it's more efficient 
> and doesn't 
> >have to continually stop and then back up another like it 
> would if we 
> >had channels set to 1 where it would go one at a time.
> >Also, increasing filesperset helps in this area , too.
> >
> >Clearly, the more channels you set, the more save sets you 
> end up with 
> >and thus the more save sets will be interleaved to the tape and the 
> >longer recovers will take, so there's a trade off between increased 
> >write speeds versus recovers. BUT, the more save sets you break the 
> >Oracle backups into the smaller those save sets, and that could be a 
> >good thing, but the more filesperset, the larger those 
> savesets, too. 
> >Hmm ... OK, all fine and well, but:
> >
> >1.  Does more filesperset also affect recover time in the 
> same way that 
> >more save sets (channels) to the same tape does?
> >
> >2.  During normal (non-Oracle) backups, how many files does 
> NetWorker 
> >send in a single saveset?
> >
> >3.  Let's say you had a database of 100 files, maybe 70 GB total. If 
> >you set filesperset 1, and had 1 channel then you'd end up with 100 
> >save sets on a full which sounds kinda dumb. On the other 
> hand setting 
> >filesperset 100 with 1 channel sounds ridiculous as well. 
> So, how about 
> >2 channels with filesperset 5.
> >That would take 20 save sets on a full, maybe only 5-6 save 
> sets on an 
> >incremental. Does that sound reasonable or would it be 
> better to crank 
> >it up to 5 channels? Our devices are set to handle 5, so 
> it's not gonna 
> >need another drive.
> >
> >We have the Oracle client's parallelism set to default 4 
> (NetWorker), 
> >so I imagine we can't increase the channels beyond 4 unless 
> we change 
> >that value. This machine has 8 cpus, plenty of memory, so 
> maybe we can 
> >increase that. Since our test database is so small, though, 
> we really 
> >don't have a good feel for what will and won't work so well, 
> but I was 
> >thinking that if we're seeing decent write speeds, and 
> decent recover 
> >times at say 2 channels with filesperset 5 then maybe just 
> leave it at 
> >that?
> >
> >4.  Should the channels be set to 1 when recovering?
> >
> >5.  Should we use regular differential backups (like level 1 every 
> >night until the next full) or a cumulative backup?
> >
> >Thanks for any horror stories or suggestions.
> >
> >george
> >
> >  
> >
> 
> 
> --
> George Sinclair - NOAA/NESDIS/National Oceanographic Data Center
> SSMC3 4th Floor Rm 4145       | Voice: (301) 713-3284 x210
> 1315 East West Highway        | Fax:   (301) 713-3301
> Silver Spring, MD 20910-3282  | Web Site:  http://www.nodc.noaa.gov/
> - Any opinions expressed in this message are NOT those of the 
> US Govt. - 
> 
> To sign off this list, send email to 
> listserv AT listserv.temple DOT edu and type "signoff networker" in 
> the body of the email. Please write to 
> networker-request AT listserv.temple DOT edu if you have any 
> problems with this list. You can access the archives at 
> http://listserv.temple.edu/archives/networker.html or via RSS 
> at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
> 

To sign off this list, send email to listserv AT listserv.temple DOT edu and 
type "signoff networker" in the body of the email. Please write to 
networker-request AT listserv.temple DOT edu if you have any problems with this 
list. You can access the archives at 
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

<Prev in Thread] Current Thread [Next in Thread>