| Subject | Re: Locking a database to cause a backup to fail |
|---|---|
| Author | Adam |
| Post date | 2006-04-30T03:56:46Z |
--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...> wrote:
process from completing, it will create a backup file that is
unrestorable, so it really depends on what in particular he is trying
to test. My backup process includes a test restore, so to me it makes
no difference.
I do have a real corrupt database that I use for this sort of test,
but as it contains customer data I can not release it. (the corruption
only directly affects a single record in a single table although also
indirectly through some FK relationships other tables may be
affected). It was too severe for gfix to handle and at the time the
last working backup was only a few hours old so we restored that and
manually entered the lost data which was only about a half hours work.
I was successful in datapumping the rest of the database.
What happens under Superserver is the engine is the engine panics and
closes down before being restarted by guardian whenever the particular
record is read. Obviously gbak reads the record, so every time you run
it, Firebird disconnects every connection and restarts. This
unfortunately affects other databases as well even if they have no
corruption. If it is running under classic, then only the gbak process
fails.
So my guess is that you will have bigger problems then your gbak not
running if you encounter corruption.
Adam
>trying to
>
> >--- In firebird-support@yahoogroups.com, "Steve Harp" <steve@> wrote:
> > >
> > > Hi Guys,
> > >
> > > Is there a way to lock a database to force a backup will fail?
> > >
> > > Why would anyone want to do this you ask? Well, my boss is
> > > test an application and wants to see the response when a backupfails.
> > >I misread the question. My suggestion would not prevent the gbak -b
> > > Thanks,
> > > Steve
> > >
>
> At 11:03 AM 30/04/2006, Adam wrote:
>
>
> >Lots of ways.
>
> Umm, no.
>
>
> >Add a not null field to a table with existing data and do not fill the
> >pre-existing records with values is the easiest guaranteed method I
> >have seen.
>
> That will break a restore, but not a backup.
process from completing, it will create a backup file that is
unrestorable, so it really depends on what in particular he is trying
to test. My backup process includes a test restore, so to me it makes
no difference.
I do have a real corrupt database that I use for this sort of test,
but as it contains customer data I can not release it. (the corruption
only directly affects a single record in a single table although also
indirectly through some FK relationships other tables may be
affected). It was too severe for gfix to handle and at the time the
last working backup was only a few hours old so we restored that and
manually entered the lost data which was only about a half hours work.
I was successful in datapumping the rest of the database.
What happens under Superserver is the engine is the engine panics and
closes down before being restarted by guardian whenever the particular
record is read. Obviously gbak reads the record, so every time you run
it, Firebird disconnects every connection and restarts. This
unfortunately affects other databases as well even if they have no
corruption. If it is running under classic, then only the gbak process
fails.
So my guess is that you will have bigger problems then your gbak not
running if you encounter corruption.
Adam