New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Restore fails if one stored procedure is incorrect [CORE4340] #4662
Comments
Commented by: @dyemanov What do you mean by incorrect procedure? What was the gbak error message? Can you provide an example? What FB version do you use? A restored database is either consistent or not. Skipping some metadata is not a good behavior, at least by default. This is especially important when we consider interdependencies, i.e. one skipped procedure may require to skip a dozen of dependent ones. Besides that, I foresee imlementation issues in this approach. Metadata objects are restored in a single transaction for a reason and it's surely impossible to change commit into a partial rollback. Restoring metadata in many separate transactions has its own drawbacks and is likely to introduce another issues. As for complete data loss, this is impossible. When restore fails due to incorrect metadata (whatever it might mean), all tables along with all their records are already restored and can be accessed in the newly created database. Also, a sane admin should always check the resulting code of gbak to avoid backups "thought to be good". I can consider this ticket as a possible request for improvement, but not as a bug. |
Commented by: Robert Gilland (robert.gilland_basx.com.au) gbak error message invalid request BLR at offset 640 using firebird 2.5.2 latest release we got no errors during backup. ( using database workbench for backup ). so when this happens to us should we? From memory we have tried this approach and it has landed us in further hot water. |
Commented by: Sean Leyne (seanleyne) Robert, Not sure how to read your last comment, are you looking to: If (a) then I would make a notional change to the SP logic, in the source db, to force the engine to recompile it. The next backup should not have any errors. If (b) then you would need to: |
Commented by: Robert Gilland (robert.gilland_basx.com.au) well both really. 1. Fortunately I have been able to find the bad psql and resolve it then create a second good backup file. However, next time I might not be so lucky. recovering by data/copy move tools is not an option, as almost everything in our database is foreign key constrained. |
Commented by: Sean Leyne (seanleyne) Some of the copy/move tools are designed to process rows based on FK constraints or to drop the FKs and then add them in a cleanup step... But your point is well made, that restore should handle some failures better. In this case, the only solution I can think of is to restore an empty SP initially (with parameters only) and then later restore the full BLR... (much like the indexes definitions are restored but activated later in the restore). This approach is feasible but ... a little ugly. |
Submitted by: Robert Gilland (robert.gilland_basx.com.au)
Votes: 2
GBAK restore will fail if one procedure is incorrect, this means backups that were thought to be good cannot be used.
Also grave possibility of complete loss of data.
I recommend any metadata that cannot be committed be "skipped" during the restore.
Thus allowing the database to be usable after the restore.
The "skipped" metadata should be identified in the restore logs.
I just spent an entire day looking for an incorrect procedure!
The text was updated successfully, but these errors were encountered: