On Thu, 2003-07-24 at 04:28, Scott Taylor wrote:

> Paul Schmidt said:
>
> > On Wed, 2003-07-23 at 18:20, Scott Taylor wrote:
> >> At 14:09 07/23/03, you wrote:
> >> I think a database would have to be very damaged
> >> to not restore.
> >
> > Actually it's simple to do, take a field that allows NULL fields,
> > change the system tables so that it no longer allows NULL fields,
> > neglect to check that there are no NULL fields in the database.
>
> Oh, so purposely shoot yourself in the proverbial foot? That just
> silly, why would anyone do that? I like to play in fields of the
> RDB$SysTable, but even I'm not that stupid.

It's easy to do, when you THINK you set values on all of the NULLS, but
missed one, and all it takes is one.

>
> > First time you restore, when it finds a NULL it will explode faster
> > then a Ford Pinto rear-ended by a Mack sized truck.
>
> Not so, everything else is restored, only the records that have errors
> will not restore as would be with any RDBMS. Nothing has blown up,
> the RDBMS has done exactly as you asked it: do not allow records in
> this table that have field X as null.

Are you sure? Actually that could be even worse, at least when it comes
to a full stop you know there is a problem. Many tables can not drop
records without serious repercussions.

>
> > 99% of the time a restore fails this is the reason why.
>
> Therefore 99% of DB failures are do to user stupidity? That I can
> believe. =P

Actually in this case D.B.A.stupidity. I was once told by a very
paranoid co-worker, "Never do anything you can't reverse if it gets
FUBAR." Now backing up a database, and then restoring to the same file,
qualifies as something you can't reverse if it gets FUBAR.

It's a good idea with Gbak, that when you change the data structure,
add/change/delete fields or alter any record in any system table, that
you do a backup and restore to another file afterwards. It's also a
good idea to test ANY backup once in a while, say once a month or so, no
matter what kind of backup it is.

I worked one place, where another company in the same office did a
nightly backup, to tape, but no one ever checked the logs or did a test
restore to make sure the backup was working. Sometime in December, the
tape log started to show a "clean heads message". shortly thereafter the
log changed to show a message that the backup had failed due to write
errors. The following April the office opened to the wonderful sounds
of a hard-drive about to leave this mortal coil for that big computer in
the sky..... So they replaced the drive, and tried the restore of a
tape that hadn't been updated since the previous December. It cost them
a small fortune, and a lot of data entry hours to put that system back
together, and the person responsible for the backups was doing a lot of
reading, in the situations vacant section of the newspaper.

Strangely enough the tape logs had survived, and someone went through
them afterwards and found the messages. I can just see some folks
reading this message, running off to check their own tape logs.....