OnBar restore dbspace 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 -- XS2Mail: Check your mail anywhere http://www.xs2mail.com/
Hi, there are some problems with archives and/or restores are done regarding the dbspace order. Though I wasn't aware of this particularly unfortunate scenario that you have. I will discuss this in our team and see what we can do ... I'll let you know. Regards, Martin -- Martin Fuerderer IBM Informix Development Munich Data Management Solutions "Malc_p " <malc_p@btinternet.com> Sent by: forum.subscriber@iiug.org 21.05.2003 13:09 To: ids@iiug.org cc: Subject: OnBar restore dbspace order [1189] 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 -- XS2Mail: Check your mail anywhere http://www.xs2mail.com/