Hi,
today I was optimizing queries running in stored procedures.
I added some PLAN statements to the select's which resulted in much faster queries.
After all work was done I backedup the database and tried to restore it on another server.
The restore stopped issuing an error that index [name] does not exist, where [name] is the name of the index used in the plan statement.
Taking a look at the order in which gbak writes the backup I found out that the indices are backed-up/restored after the store procedures.
Is there any chance to either change the order in which the backup is generated or to ignore this kind of error during the restore?
Thanks for any hint.
Christian
today I was optimizing queries running in stored procedures.
I added some PLAN statements to the select's which resulted in much faster queries.
After all work was done I backedup the database and tried to restore it on another server.
The restore stopped issuing an error that index [name] does not exist, where [name] is the name of the index used in the plan statement.
Taking a look at the order in which gbak writes the backup I found out that the indices are backed-up/restored after the store procedures.
Is there any chance to either change the order in which the backup is generated or to ignore this kind of error during the restore?
Thanks for any hint.
Christian