On 2012-12-07 15:09, Matthew Huff wrote:
George,
Since the dawn of Networker, multiplexed savesets major issues has been restore
speed. Other than that, I have had no issues using the NMO with multiple
channels with over 15 years. I have had to do a few disaster recoveries
(unfortunately) and have had no issues. I've also used the rman backups to
clone to a test instances and to verify the backups. Again, I've never had any
issues relating to multiple channels. Here is our current RMAN script:
Thanks, Matthew. Perhaps we're fine then.
I did test increasing the channels from 4 to 6 (non-production database)
before I posted my question. As expected, this created six save sets
instead of four, but I noticed that the completion times for the
incremental were several minutes slower than I've seen on average, and
the amount of data being backed up was certainly no bigger. After that,
I ran one full, and that took just about the same time as before, so no
appreciable difference in completion times, thus I'm inclined to think
that the drive wasn't writing any faster than normal. Of course, we've
only run those two backups since increasing the channels, but I suspect
there will be no improvement, and we would be best served to change it
back to four again so we can at least have faster restore times.
Out of curiosity, when you say:
"I've also used the rman backups to clone to a test instances and to
verify the backups"
how did you verify those backups? Did you consider the success of the
cloning operation as a verification of the original, or did you actually
restore from those clones? If so, did you restore to a test database?
When we were first setting things up, we created a small, test database
(not enough space to hold the real database and another test copy of it)
and tested recovering from both the originals and clones. But in that
case, we were restoring from the test database backups, not the real
ones, but otherwise the mechanics were the same.
Our RMAN script looks similar, but no lines for "filesperset", "parms
'ENV=" or "delete all input". Maybe there's default values for these,
and/or environment variables outside the script. We have three scripts.
One backs up the catalog database. The second runs a level 0 on the
actual database and the third runs a level 1 - all depending on the
NetWorker schedule. Each of those two has two lines like:
backup as backupset incremental level 0 cumulative format
'name_%d_df_level0_%u_%s.%p' database;
backup current controlfile format 'name_%d_cf_%u_%s.%p';
The other is the same but uses 'level 1 cumulative format ...'
Should we be looking at adding a specific line for filesperset?
Otherwise, I guess it must be using some default value?
Without getting into a long discussion concerning Oracle fine tuning,
I'm wondering if we might be able to increase backup performance
(completion times) by adding some RMAN Oracle variables/switches to the
script, e.g. filesperset, maxopenfiles, etc. but still keep the channels
set to 4. Otherwise, from I could find, the default number of files per
channel is 8, so that would be 8*4=32, and we have maybe 50-60 database
files.
George
connect target sys/xxxxxx@SECPROD
connect rcvcat rman/xxxxxx@RMAN
run {
set command id to 'SECPROD';
allocate channel t1 type 'SBT_TAPE'
parms 'ENV=(NSR_DATA_VOLUME_POOL=OTAFull)';
allocate channel t2 type 'SBT_TAPE'
parms 'ENV=(NSR_DATA_VOLUME_POOL=OTAFull)';
allocate channel t3 type 'SBT_TAPE'
parms 'ENV=(NSR_DATA_VOLUME_POOL=OTAFull)';
allocate channel t4 type 'SBT_TAPE'
parms 'ENV=(NSR_DATA_VOLUME_POOL=OTAFull)';
backup database filesperset 4 force format='/%d_DATA_%U/'
plus archivelog filesperset 16 force format='/%d_ARCH_%U/'
delete all input;
release channel t1;
release channel t2;
release channel t3;
release channel t4;
}
-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU] On
Behalf Of George Sinclair - NOAA Federal
Sent: Friday, December 07, 2012 2:58 PM
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Subject: [Networker] Need help with Oracle backup channels
Hi,
Looking around on Google, I've found a number of Oracle documents that
advise/warn against using media manager multiplexing for Oracle RMAN
backups. They suggest that only RMAN should be doing any multiplexing.
If I understand this correctly, they're saying that we should *not* be
using more than one channel for the RMAN backup script when sending the
data to a sequential device, i.e. tape. I suppose one exception would be
if we had multiple nodes, each writing to a different tape drive, or
maybe we were duplicating it to other tape drives, but that's not the
case. I could find no information in the EMC NMO document regarding
this, and perhaps that's not surprising since that's not an Oracle document.
We have several tape drives in a single tape library and one Oracle
backup pool and one clone pool. We use the NMO to do the backups. Our
full backups are not that big, so we can ride on a single tape for quite
a while. We do clone the backups. Nothing else writes to this pool other
than the Oracle backups. When we originally set this up, the RMAN script
used four channels. As a result, the backups always consist of four save
sets, followed by the control file. We have successfully tested
recovery. The parallelism for the drives can easily handle the number of
channels we're currently using. As a result, the backups always write to
a single tape, so it's not like we have the channels set so high that it
exceeds the parallelism on the drive and forces another tape to be
loaded in a second drive. A full currently takes about 3 hours.
Incrementals are very fast, however.
I'm wondering if we should change the RMAN script to use a single
channel instead. In this case, I guess we'd end up with a single save
set. That would make it easier to query (mminfo), but I'm concerned that
this might slow the drive speed way down, and the fulls might take a lot
longer. They also point out that while multiplexing the data on the
media manager's end may speed up backup times, it's not recommended.
Instead, RMAN should be set to do the multiplexing.
1. What is the main concern that Oracle raises? Is it the fact that
multiple channels creates two or more save sets, which then interleaves
the data on the tape thus making it take longer to recover it?
This was the only thing that seemed obvious but I could find nothing
specific.
2. What are others doing? Should we change the RMAN script to use only
one channel to SBT_TAPE?
In other words, keep it to the fewest number of channels that we can
possibly live with in terms of drive speed.
3. I don't understand how multiplexing is done in RMAN versus whatever
the default would be. I've read through a bunch of stuff, and it's very
confusing and nebulous.
The idea of multiple save sets being interleaved to a single tape when
running normal NetWorker backups makes sense to me. But if you have a
single channel, is RMAN wrapping multiple files together when it uses
that channel? With standard NetWorker flat file backups, are multiple
files being woven together when a single save set is running? Just not
sure how to correlate these two (RMAN's definition of multiplexing
versus NetWorker's), and what setting or variables we need to set on the
Oracle side to do this. I can work closely with the DBA to make any
necessary changes. That's not an issue.
Thanks.
George
--
George Sinclair
Voice: (301) 713-3284 x210
- The preceding message is personal and does not reflect any official or
unofficial position of the United States Department of Commerce -
- Any opinions expressed in this message are NOT those of the US Govt. -
|
