yes, but lets say legato has the resources to mount extra tape on extra tape drives. by alloocating channel rman tries to get channel of the same tape drive becuase that is the one is backed onto unless rman issues a call to getthat tape drive legato cannot mount nor read it. The only way i see to give rman a specific backup piece and then let it go after that particular tape. we can already get the tape numbers from the rman catalog . and looking at the documentation the restore command doesnt support a backuppiece restore as of 9i . on the other hand . The only possible solution i see is correlatint the datafiles to the backup pieces in the catalog and then correlating the backup pieces to the tape number and creating scripts during a restore to get the datafiles for a particular backup peice and restore them. this way i can force rman to call all the tapes at once and thus forcing legato to get all the tapes mounted Byron Pearce <pearceb@xxxxxxxxxx> wrote: Fuad: My understanding (not being an expert on the internals of either RMAN or Legato) is that RMAN would issue the call for the file that it wants and "pass" that request to Legato through an API. Legato then handles how to process the request in order to return the file. My guess is that the requests would be in queue inside Legato waiting for it to manage the restore process. So, again, my guess is that Legato would be the bottleneck. In my experience I have seen it do the same thing from command-line, GUI interface, and RMAN restores. If RMAN is requesting all of the files on a single tape each time it "passes" a file to Legato, then only a single stream would be able to be used no matter how many channels you have. Consider an example where you have 8 files (file1 - file8). Now, let's assume for the sake of simplicity that file1 - file4 are on tape1 and file5 - file8 are on tape2. When RMAN requests its files, it asks for file1 - file4. Legato has an index that tells it where all of those files are, and they are all on tape1. Therefore, he cannot use multiple streams since he is going to be fast-forwarding and rewinding the tape to get the necessary files. I admit this is conjecture on my part but is consistent based on what I have seen Legato do when I last used it (newer versions may behave differently). The only way we got it to work was to "trick" Legato into thinking that it was running completely separate restore jobs (each with all files on a completely separate tape) simultaneously. In theory, that is the way that RMAN should work for each channel but I cannot comment on that conclusively. Fuad Arshad wrote: Byron, Thanks for the response. we finally did get the backups to multiple tape drive the isue with legato is by default it does 10 streams /tape and a stream is basically a channel in rman. so we were able to bump the legato streams parameter down to get stuff working still figuring out how to restore from multiple tapes at a time if you could by any chance find the script of your that would be great. the issue is would it be an rman bottleneck or a legato bottleneck. becuase theoretically if rman issues a call for a tape and the tape drive is avialble loegato should mount that tape. but then how does rman determine what streams it wants to get and how can we forceit to use multiple tape drives(meaning more tapes than it initally backed up on at a time.) How does rman internally determine the streams it wants first . Byron Pearce <pearceb@xxxxxxxxxx> wrote: Fuad: One of the problems that I always ran into with Legato was that it would backup to multiple tapes, but that it would restore from a single tape at a time. It has been several years since I have worked with the product, so that might have changed. Having said that, we did get it to use multiple tape drives during a restore process by having a shell script that would parse the Legato database. I believe that I may have those in a tar/gzip archive somewhere on another system. It required us to get the various SSID's on the distinct tapes and build a shell script for each one. It was not a simple process, though once we had it scripted and documented it did go rather smoothly. If I can find then, then I will send them your way - maybe they will be helpful. The short answer is "yes" you can do that, but it takes som e work to set it up. Someone else might have a better idea if the newer versions of Legato have a simpler way to get around this problem. HTH Fuad Arshad wrote: > Got a Questions for all the folks using rman out there. > > We are using rman with a legato networker solution. > Now after tuning rman like stting up maxopenfiles, setting the > filesperset doingg work on the maxblocksize. > we have tuned the backup about 2Tb to run in 6-8 hours. > The backup gets 4 tapes and in total writes to 7 tapes. > the restore took us about 32 hrs which offcourse management didnt like. > one of the ideas pooped around was . > Is it possible to allocate more tape drives at restore time > e.g 4 tapes drive on backup but 7 on restore > and if we allocate enough extra channels will rman pick up the extra > 3 tapes since it did backup on a total of 7 tapes. > this could cut the rersto re time a lot and i'm trying to get some > test environment to try to test this but anyone out face this issue if > so how did they resolve/fight thru this > > > > Thanks -- ==================================================================== Byron Pearce mailto:pearceb@xxxxxxxxxx Tenure Systems, Inc. Dallas/Fort Worth, TX "It's hard to be a ninja when you wear a beeper." ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html ----------------------------------------------------------------- -- ====================================================================Byron Pearce mailto:pearceb@xxxxxxxxxxxxxxxx Systems, Inc. Dallas/Fort Worth, TX"It's hard to be a ninja when you wear a beeper."