| Subject | How do I get my database back? |
|---|---|
| Author | Tim Ward |
| Post date | 2015-03-24T15:42:35Z |
gbak: ERROR:validation error for column BOXNUMBER, value "*** null ***"
gbak: ERROR: warning -- record could not be restored
gbak:Exiting before completion due to errors
So, at some point prior to the backup someone had added this NOT NULL
column, and hadn't gone round setting the values in the column. So yes,
I do understand what initiated the problem.
*** BUT *** this is a "you had one job" issue, isn't it?
The one and only job of a backup utility is to create a backup that can
be restored. If it doesn't do that it's failed. At its one and only job.
Soooo many other approaches could have been taken, that wouldn't have
lost my database for me, including but probably not limited to:
(1) During backup, fail if the backup file being created is one that it
won't be able to restore.
(2) During restore ... er, just restore it anyway? - in its previous
state the database was, strictly speaking, illegal[#], but it was, in
real life, working fine. If gbak took this option, with a warning, then
I'd be able to fix the data ... but as it is, I can't, because I can't
restore the database.
Yes I did discover no_validity, with which the restore did create *a*
database, but it was a completely ****ing useless database as the NOT
NULL constraints appeared to have been dropped everywhere, and who knows
what other manglings had taken place (the documentation doesn't list
them explicitly, it just says "deletes validity constraints from
restored metadata"). Which means that gbak had a third option to get it
right:
(3) Provide a restore option that warns about validity checking errors,
rather than failing them, but doesn't actually delete the checks from
the database.
So, please, how am I expected to get my database back? OK OK, so I don't
actually need the data in the one table causing the problem (there
aren't millions of foreign keys pointing at it from all over the shop),
so -o -v worked, only losing the data in the one table that I didn't
care about anyway, but that's only because I happen to be lucky with the
data structures, it won't be a solution in general.
[#] Yes, well, there's then the question about how come you're allowed
to get a database into such an illegal state in the first place, isn't
there.
--
Tim Ward
gbak: ERROR: warning -- record could not be restored
gbak:Exiting before completion due to errors
So, at some point prior to the backup someone had added this NOT NULL
column, and hadn't gone round setting the values in the column. So yes,
I do understand what initiated the problem.
*** BUT *** this is a "you had one job" issue, isn't it?
The one and only job of a backup utility is to create a backup that can
be restored. If it doesn't do that it's failed. At its one and only job.
Soooo many other approaches could have been taken, that wouldn't have
lost my database for me, including but probably not limited to:
(1) During backup, fail if the backup file being created is one that it
won't be able to restore.
(2) During restore ... er, just restore it anyway? - in its previous
state the database was, strictly speaking, illegal[#], but it was, in
real life, working fine. If gbak took this option, with a warning, then
I'd be able to fix the data ... but as it is, I can't, because I can't
restore the database.
Yes I did discover no_validity, with which the restore did create *a*
database, but it was a completely ****ing useless database as the NOT
NULL constraints appeared to have been dropped everywhere, and who knows
what other manglings had taken place (the documentation doesn't list
them explicitly, it just says "deletes validity constraints from
restored metadata"). Which means that gbak had a third option to get it
right:
(3) Provide a restore option that warns about validity checking errors,
rather than failing them, but doesn't actually delete the checks from
the database.
So, please, how am I expected to get my database back? OK OK, so I don't
actually need the data in the one table causing the problem (there
aren't millions of foreign keys pointing at it from all over the shop),
so -o -v worked, only losing the data in the one table that I didn't
care about anyway, but that's only because I happen to be lucky with the
data structures, it won't be a solution in general.
[#] Yes, well, there's then the question about how come you're allowed
to get a database into such an illegal state in the first place, isn't
there.
--
Tim Ward