OnBar restore order? 
Author Message
 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



Sun, 06 Nov 2005 19:08:30 GMT
 OnBar restore order?

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 ;)

Quote:

> 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



Sun, 06 Nov 2005 21:44:55 GMT
 
 [ 2 post ] 

 Relevant Pages 

1. Onbar Restore Error - Can't Restore Reserved Pages

2. attempt to restore, said db was dumped under diff sort order, how to restore it

3. Clarification of Onbar RESTARTABLE RESTORE issue....

4. Repost: ONBAR restore from disk - Objects not found

5. Oops - ONBAR restore from disk - Objects not found

6. ONBAR restore from disk - Objects not found

7. cold restore with onbar

8. Onbar restore to different machine.

9. Onbar Linked List operation failed on imported restore

10. Using Onbar to do a system restore

11. onbar restore to alternate client from a parallel backup failed

12. Informix onbar backup/restore with Veritas NetBackup


 
Powered by phpBB® Forum Software