Hi Phil, 

Multiplexing Oracle backups does not improve backup performance and *can* 
multiply restore time, so I wouldn't use it.

RMAN assumes that the output of a channel (a backup set) is stored on different 
media and it will backup and restore those backup sets in parallel. What 
happens 
if the backup sets are multiplexed on a single tape is best explained by an 
example:

 1. RMAN requests the data for channel 1 to the media manager and waits for the 
    data to come in
 2. NBU locates and mounts the tape. It finds the tape has multiplexed backups
    and waits MPX_RESTORE_DELAY seconds (default 30) for other restore requests
    coming out of the same read pass. This timer expires and NBU starts sending 
    data.
 3. RMAN receives the data for channel 1 and requests the data for channel 2.
 4. NBU finds that the tape is busy and queues the request until channel 1 
    is finished.
    
So, MPX'ing 2 channels/sets on 1 tape doubles restore time. The scenario above 
is the sole reason why people have ridiculous long CLIENT_READ_TIMEOUT settings 
(like a hour or so) with Oracle: channel 2 must wait until 1 is finished.

To configure Oracle backups I use the following scenario:
 1. Allocate as much channels as the bottleneck in the datapath from db server
    to tape can utilize:
    100Mbit ethernet + DLT8000 w. compression: 1 channel
    Gbit ethernet + DLT8000 w. compression: 4 channels
    1Gbit SAN + w. LTO2 w. compression: 2 channels
    etc. etc.
    
 2. If necessary tune Oracle to deliver sufficient data for all channels.
    I almost always see improvement with
      set limit channel c1 maxopenfiles 1;
    in the RMAN commandfile. For composing a backup set, RMAN does a
    multiplexed read from up to (default) 16 datafiles in the hope that these 
    datafiles are on different disks. If datafiles are on the same disk this 
    multiplexing just generates a lot of head movements. If the datafiles are 
    on some form of RAID storage, the multiplexing thrashes cache and disable
    readahead algorithms. 
     
Sorry for the long post ;-)

Best regards, Joost


>NBU 4.5 FP 4, Solaris 2.6 Master, Media & Clients.  StorageTek L700 with
>DLT7000.
>
>Do people tend to multiplex Oracle RMAN backups?  I'm on a drive to improve
>throughput of our solution, looking into tuning the buffers mainly, but I
>notice we aren't multiplexing Oracle backups whereas everything else is at 4
>MPX.  I assume if multiplexed, restore performance will suffer, but to what
>degree?  I have heard some scare stories here as explanations for why we
>aren't multiplexing (1.5 hour backup taking "all day" to restore) but
>suspect something else was causing them.
>
>Any feedback would be appreciated.
>
>thanks, Phil
>
>Phil Weber
>Egg Distributed Hosts - UNIX Systems Engineer
>Phone: 01384 26 4136
>Mobile: 
>
>
>This private and confidential e-mail has been sent to you by Egg.
>The Egg group of companies includes Egg Banking plc
>(registered no. 2999842), Egg Financial Products Ltd (registered
>no. 3319027) and Egg Investments Ltd (registered no. 3403963) which
>is authorised and regulated by the Financial Services Authority. Egg
>Investments Ltd. is entered in the FSA register under number 190518. 
>
>Registered in England and Wales. Registered offices: 1 Waterhouse
>Square, 138-142 Holborn, London EC1N 2NA.
>
>If you are not the intended recipient of this e-mail and have received
>it in error, please notify the sender by replying with 'received in
>error' as the subject and then delete it from your mailbox.
>
>_______________________________________________
>Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
>http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

-- 
Long may you run.