Increasing the number of streams definitely makes the backups run faster, and is true for restores to some extent.
The ideal setup is restore=backup speed which is hard to achieve when your gauge is backup to disk and restores from tapes. Restoring from a sequential media is really slow. Random devices are really fast.
You can have restore speeds run faster if you keep the backup on disk for some time that you think is needed for restores. As an example, if you do restores once a week, you can setup the disk NOT to empty out when data is moved to tape for a week. Just be aware that you will need a HUGE disk to hold this cached data.
Hey moon-buddy.
I think you are wrong on some points here. If we were talking about restore of a directory or server, you'd be spot on. This is the restore of a database direct from tape. The data was saved sequentially and will be restored sequentially and the tape drives should be able to restore at near their max speed if the network and oracle database disk doesn't hold it up. Restoring off tape will be far quicker than disk. They managed to back it up at 1.6TB per hour.
Remember also that this is TDP not the BA client so it will behave a little different.
Benoit16:
Looking our our init<sid>.utl file, we have the following parameters.
MAX_SESSIONS 4 - This equates to the number of I/O sessions in DB13 is SAP. Essentially in DB13, you set how many tape drives you want to use although this cannot be higher than the max_sessions in the init<sid>.utl file or the maxnummp setting for the node.
SESSIONS 34 - This is the number of tablespaces backed up at the same time and relates to the parallelism setting in DB13.
Restoring the database, you will want to use similar setting to the ones used to back it up and I think this is likely to be why you are getting a poor result. Do you use backom to do the restore? I would be comparing the backup settings with the restore settings and looking for differences there.
My experience with the TDP is with DB2 so the config may be different for Oracle.