OnBar restore order?

We've noticed that when we do an OnBar restore here (quite often the case so that the development team can have a play database containing live data) that the tapes shuttle in and out more than would be expected (currently our backups of live go to two, sometimes three DLT 80Gb tapes). On checking the bar_act logs we found the sequence of dbspaces restored to be different from that of the backups (there are 42 dbspaces), thus instead of getting the dbspaces off in the order they went on, the tape shuttle has to unload one tape and load up the other constantly. Checking the bar_act log closer and matching against the sysmaster:sysdbspaces table, we found that the order of backup is: rootdbs blobspaces in dbsnum order all standard dbspaces in dbsnum order (INCLUDES loglog & physlog) BUT a restore is: rootdbs loglog physlog blobspaces in ALPHABETICAL order all standard dbspaces in ALPHABETICAL order which, frankly, appears stooopid. Is there any way of altering the default behaviour? 'cos otherwise, the only way we can fix this and save about an hour on a restore due to tape shuttling would be to completely reorganise the live system, which just ain't gonna happen. Any answers/(legal and moral) suggestions gratefully accepted. Malc_p

This is "stooooooooooooooopid" as you put it ;) There is an alternave though, use a file for the dbspace backup list that details the dbspaces in the "right order for the restore to run quickly". i.e. > rootdbs > loglog > physlog => Other critical dbspaces <= > blobspaces in ALPHABETICAL order > all standard dbspaces in ALPHABETICAL order Mash it up ;) Malc P wrote: > We've noticed that when we do an OnBar restore here (quite often the > case so that the development team can have a play database containing > live data) that the tapes shuttle in and out more than would be > expected (currently our backups of live go to two, sometimes three DLT > 80Gb tapes). > On checking the bar_act logs we found the sequence of dbspaces > restored to be different from that of the backups (there are 42 > dbspaces), thus instead of getting the dbspaces off in the order they > went on, the tape shuttle has to unload one tape and load up the other > constantly. > Checking the bar_act log closer and matching against the > sysmaster:sysdbspaces table, we found that the order of backup is: > > rootdbs > blobspaces in dbsnum order > all standard dbspaces in dbsnum order (INCLUDES loglog & physlog) > > BUT a restore is: > > rootdbs > loglog > physlog > blobspaces in ALPHABETICAL order > all standard dbspaces in ALPHABETICAL order > > which, frankly, appears stooopid. > > Is there any way of altering the default behaviour? 'cos otherwise, > the only way we can fix this and save about an hour on a restore due > to tape shuttling would be to completely reorganise the live system, > which just ain't gonna happen. > > Any answers/(legal and moral) suggestions gratefully accepted. > > Malc_p