Re: RMAN duplex backup. how many channels?

Thanks Allan,
 I thought that channels must be <= #tape devices? (2 in my case)  Then I thought that with duplex=2 that would write teh same block stream to both drives simultaneously reducing the effective # channels to 1.  I'm just not sure.
 Also when I did try duplex, the media manager complained about different block sizes and refused to proceed. It was midnight by this stage and the backup was 8 hrs overdue. so I ommitted the duplex and just ran two channels like we normally do. THat solves the immediate problem but I still want to consider duplexing the backup.
 We have been down for 10 days now! amongst other problems, tapes from two consecutive backups produced IO erros and were unuseable. I think it will be easier to convince management that we need to eliminate SPOFs such as redundant backup tapes.

How do other people eliminate reliance on individual tapes?  Regards
Russell
 On 7/16/05, Allen, Brandon <Brandon.Allen_at_oneneck.com> wrote:
>
> Russel, I've never actually used the duplex functionality, but from what
> I've read on it, I would recommend you continue to use 2, or maybe even 4
> channels. The benefit of filesperset > 1 is that you can multiplex several
> datafiles into one backup piece, which is seen as a single file/image by
> your media management software - so it is more consolidated, plus it allows
> Oracle to backup faster because it can read from multiple files
> simultaneously and write them all to the tape at the same time, thus keeping
> the tape streaming so it doesn't have to incur the expense of stopping,
> rewinding and restarting.
> You just have to set duplex=2, and then allocate as many channels as you
> want (2 or 4 recommended - you should test both to see what performs better
> for your system) - the one duplex setting will apply to all channels. Also,
> you have to have backup_tape_io_slaves=true in order to use duplex.
> (according to TFM)
> Regards,
> Brandon
>
> -----Original Message-----
> *From:* oracle-l-bounce_at_freelists.org [mailto:
> oracle-l-bounce_at_freelists.org]*On Behalf Of *rjsearle_at_gmail.com
> *Sent:* Friday, July 15, 2005 5:10 AM
> *To:* Oracle-L (E-mail)
> *Subject:* RMAN duplex backup. how many channels?
>
> HI,
> We have finally restored and recovered from a near death experience with
> multiple disk crashes and tape failures. Our env is Solaris (SunOS5.8) and
> ORA 8.1.7.0.0
> The recovery was incomplete-cancelled and subsequently opened with
> resetlogs. So I'm thinking it might be backup time!
> I had no experience with rman b4 this episode. I am scouring manuals to
> determin the appropriate rman command to do a duplexed cold backup
> Our backups are normally hot using rman. we have 2 tape drives attached
> directly to the box and normally allocate 2 channels, 4 files per set as
> follows:
> run {
> allocate channel t1 type 'SBT_TAPE' parms
> 'ENV=(NSR_DATA_VOLUME_POOL=GCLCDWP)';
> allocate channel t2 type 'SBT_TAPE' parms
> 'ENV=(NSR_DATA_VOLUME_POOL=GCLCDWP)';
> backup database
> filesperset 4
> include current controlfile
> archivelog all delete input
> format 'FULL_DW_%d_%u';
> release channel t1;
> release channel t2;
> }
> For this backup I want 2 copies so I have discovered 'set duplex = 2'.
> If I use this cmd in our env with only 2 drives, how many channels should I
> allocate? I can't find anything in TFM to clarify but then again I am now
> sleep deprived.
> Also, I am unclear of the benefit of setting filesperset to values >1.
> I'd love to hear your thoughts.
> Could the resident experts kindly review this run cmd and comment
> appropriately?
> reset database # this is required due to the resetlogs
> run {
> set duplex = 2;
> allocate channel t1 type 'SBT_TAPE' parms
> 'ENV=(NSR_DATA_VOLUME_POOL=GCLCDWP)';
> backup database
> filesperset 1
> include current controlfile
> format 'FULL_DW_%d_RESETLOGS_%u';
> relese channel t1;
> }
> Thanks
> Russell
>
> Privileged/Confidential Information may be contained in this message or
> attachments hereto. Please advise immediately if you or your employer do not
> consent to Internet email for messages of this kind. Opinions, conclusions
> and other information in this message that do not relate to the official
> business of this company shall be understood as neither given nor endorsed
> by it.

>

--
http://www.freelists.org/webpage/oracle-l