What to do when your BI and DB files are no longer in sync
What to do when your BI and DB files are no longer in sync
- Thread starter Chris Kelleher
- Start date
<FONT face="Courier New">
FAQ - What Happened - My BI and DB dates don't match
====================================================
From: ciwyse!thomas@cintegrity.com (Thomas Mercer Hursh)
Subject: BI & DB dates don't match
Date: Thu, 27 Apr 95 13:35:42 PDT
X-Mailing-List: <progress-list@peg.happmis.com> archive/latest/740
To: progress-list@margaret.peg.happmis.com
Status: RO
Apropos of the recent thread on this topic, one of my users just discovered
a way to create this condition without anyone doing anything "wrong".
Start with a crashed database (pick your method or reason.
Start a single user session on the database. This starts the crash recovery.
Before this crash recovery is complete, start a server. This starts a
second instance of crash recovery!
While your log will show both crash recovery instances going to completion,
the world then starts to fall apart with shared memory error messages from
the watchdog and APWs. The user gets killed in this process, although under
a different user name than the one the single user session was started
from! The result of all of this is that you end up with a server process
and the APWs, BIW, and watchdog, but all proutil and pro functions think
there is no server, apparently because the single user session, now gone,
owns the shared memory! Needless to say, this results in another crashed
database.
When you attempt to bring this database back up, the database will have the
date-time stamp of the single user session start and the bi file will
have the date-time stamp of the server start!
===============================================================================
Thomas Mercer Hursh, Ph.D. email: thomas@cintegrity.com
Computing Integrity, Inc. sales: 510-525-6001
700 Gilman Street - The Tannery support: 510-525-6081
Berkeley, CA 94710 fax: 510-525-0906
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
From: tom@bass.lkw.com (Tom Bascom)
Subject: Re: BI & DB dates don't match
Date: Thu, 27 Apr 1995 17:46:36 -0400 (EDT)
X-Mailing-List: <progress-list@peg.happmis.com> archive/latest/741
To: progress-list@margaret.peg.happmis.com
Status: RO
> Apropos of the recent thread on this topic, one of my users just discovered
> a way to create this condition without anyone doing anything "wrong".
>
> Start with a crashed database (pick your method or reason.
> Start a single user session on the database. This starts the crash recovery.
> Before this crash recovery is complete, start a server. This starts a
> second instance of crash recovery!
What happened to the lock file? Shouldn't it's existence have prevented
the server from starting?
-----------------------------------------------------------------
| Tom Bascom You've just got to be persistent. |
| EDS |
| tom@lkw.com |
-----------------------------------------------------------------
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
From: r.roos.mdn0402@oasis.icl.co.uk
Message-Id: <9504281231.AA03216@getafix.oasis.icl.co.uk>
Date: Fri, 28 Apr 95 13:31:07 BST
Subject: Re: BI & DB out of step
X-Mailing-List: <progress-list@peg.happmis.com> archive/latest/18
To: progress-list@margaret.peg.happmis.com
Status: RO
Dave MacLurg:
> One of my users has managed to get his .BI and .DB files out of step -
> different times. How can I get them back in step?
Eric LaRose:
> Force entry into the database using the -F parameter, then exit then database
> and run proutil {database} -C idxbuild. Select some indexes and when it prompts
> for the first index name, enter !.
Tom Bascom:
> That will get you back in. You will have lost data that was in the .bi file
> but I don't think there's anyway to avoid that. Hopefully there wasn't
> much.
This is fine if the database was not being written to at the time of the crash.
However, not only will you loose data that was in the bi file, but is it not
possible that your database's refferential integrity may be compromised ? If
there is a chance of this then you must do a dump & reload, so that schema
triggers can re-enforce refferenntial integrity.
...or have I got the wrong idea completely...?
Kind regards, Robin.
------------------------------------------------------------------
Robin M. Roos Email: R.Roos.Mdn0402@oasis.icl.co.uk
(Progress Contract A/P) Tel: +44-374-850041
Relational Management Systems Limited London, United Kingdom
------------------------------------------------------------------
"Progress 7 developers have Vision"
------------------------------------------------------------------
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
From: tom@bass.lkw.com (Tom Bascom)
Message-Id: <9505011657.AA27195@bass.lkw.com>
Subject: Re: BI & DB out of step
Date: Mon, 1 May 1995 12:57:50 -0400 (EDT)
X-Mailing-List: <progress-list@peg.happmis.com> archive/latest/21
To: progress-list@margaret.peg.happmis.com
Status: RO
Dave MacLurg:
> > One of my users has managed to get his .BI and .DB files out of step -
> > different times. How can I get them back in step?
Eric LaRose:
> > Force entry into the database using the -F parameter, then exit then database
> > and run proutil {database} -C idxbuild. Select some indexes and when it prompts
> > for the first index name, enter !.
Tom Bascom:
> > That will get you back in. You will have lost data that was in the .bi file
> > but I don't think there's anyway to avoid that. Hopefully there wasn't
> > much.
Robin M. Roos:
> This is fine if the database was not being written to at the time of the crash.
> However, not only will you loose data that was in the bi file, but is it not
> possible that your database's refferential integrity may be compromised ? If
> there is a chance of this then you must do a dump & reload, so that schema
> triggers can re-enforce refferenntial integrity.
>
> ...or have I got the wrong idea completely...?
Nope, it's a good point. That's one of the big problems when you lose
data and you don't know what data you lost (then again if you knew what
data you lost...). With v7 the dump & load could be used to enforce
referential integrity (if you took the time to write the triggers in the
first place...). With v6 you get to do it by hand. In either case it
might be handy to have already created the programs to verify integrity
ahead of time.
-----------------------------------------------------------------
| Tom Bascom You've just got to be persistent. |
| EDS |
| tom@lkw.com |
-----------------------------------------------------------------
</FONT f>
FAQ - What Happened - My BI and DB dates don't match
====================================================
From: ciwyse!thomas@cintegrity.com (Thomas Mercer Hursh)
Subject: BI & DB dates don't match
Date: Thu, 27 Apr 95 13:35:42 PDT
X-Mailing-List: <progress-list@peg.happmis.com> archive/latest/740
To: progress-list@margaret.peg.happmis.com
Status: RO
Apropos of the recent thread on this topic, one of my users just discovered
a way to create this condition without anyone doing anything "wrong".
Start with a crashed database (pick your method or reason.
Start a single user session on the database. This starts the crash recovery.
Before this crash recovery is complete, start a server. This starts a
second instance of crash recovery!
While your log will show both crash recovery instances going to completion,
the world then starts to fall apart with shared memory error messages from
the watchdog and APWs. The user gets killed in this process, although under
a different user name than the one the single user session was started
from! The result of all of this is that you end up with a server process
and the APWs, BIW, and watchdog, but all proutil and pro functions think
there is no server, apparently because the single user session, now gone,
owns the shared memory! Needless to say, this results in another crashed
database.
When you attempt to bring this database back up, the database will have the
date-time stamp of the single user session start and the bi file will
have the date-time stamp of the server start!
===============================================================================
Thomas Mercer Hursh, Ph.D. email: thomas@cintegrity.com
Computing Integrity, Inc. sales: 510-525-6001
700 Gilman Street - The Tannery support: 510-525-6081
Berkeley, CA 94710 fax: 510-525-0906
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
From: tom@bass.lkw.com (Tom Bascom)
Subject: Re: BI & DB dates don't match
Date: Thu, 27 Apr 1995 17:46:36 -0400 (EDT)
X-Mailing-List: <progress-list@peg.happmis.com> archive/latest/741
To: progress-list@margaret.peg.happmis.com
Status: RO
> Apropos of the recent thread on this topic, one of my users just discovered
> a way to create this condition without anyone doing anything "wrong".
>
> Start with a crashed database (pick your method or reason.
> Start a single user session on the database. This starts the crash recovery.
> Before this crash recovery is complete, start a server. This starts a
> second instance of crash recovery!
What happened to the lock file? Shouldn't it's existence have prevented
the server from starting?
-----------------------------------------------------------------
| Tom Bascom You've just got to be persistent. |
| EDS |
| tom@lkw.com |
-----------------------------------------------------------------
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
From: r.roos.mdn0402@oasis.icl.co.uk
Message-Id: <9504281231.AA03216@getafix.oasis.icl.co.uk>
Date: Fri, 28 Apr 95 13:31:07 BST
Subject: Re: BI & DB out of step
X-Mailing-List: <progress-list@peg.happmis.com> archive/latest/18
To: progress-list@margaret.peg.happmis.com
Status: RO
Dave MacLurg:
> One of my users has managed to get his .BI and .DB files out of step -
> different times. How can I get them back in step?
Eric LaRose:
> Force entry into the database using the -F parameter, then exit then database
> and run proutil {database} -C idxbuild. Select some indexes and when it prompts
> for the first index name, enter !.
Tom Bascom:
> That will get you back in. You will have lost data that was in the .bi file
> but I don't think there's anyway to avoid that. Hopefully there wasn't
> much.
This is fine if the database was not being written to at the time of the crash.
However, not only will you loose data that was in the bi file, but is it not
possible that your database's refferential integrity may be compromised ? If
there is a chance of this then you must do a dump & reload, so that schema
triggers can re-enforce refferenntial integrity.
...or have I got the wrong idea completely...?
Kind regards, Robin.
------------------------------------------------------------------
Robin M. Roos Email: R.Roos.Mdn0402@oasis.icl.co.uk
(Progress Contract A/P) Tel: +44-374-850041
Relational Management Systems Limited London, United Kingdom
------------------------------------------------------------------
"Progress 7 developers have Vision"
------------------------------------------------------------------
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
From: tom@bass.lkw.com (Tom Bascom)
Message-Id: <9505011657.AA27195@bass.lkw.com>
Subject: Re: BI & DB out of step
Date: Mon, 1 May 1995 12:57:50 -0400 (EDT)
X-Mailing-List: <progress-list@peg.happmis.com> archive/latest/21
To: progress-list@margaret.peg.happmis.com
Status: RO
Dave MacLurg:
> > One of my users has managed to get his .BI and .DB files out of step -
> > different times. How can I get them back in step?
Eric LaRose:
> > Force entry into the database using the -F parameter, then exit then database
> > and run proutil {database} -C idxbuild. Select some indexes and when it prompts
> > for the first index name, enter !.
Tom Bascom:
> > That will get you back in. You will have lost data that was in the .bi file
> > but I don't think there's anyway to avoid that. Hopefully there wasn't
> > much.
Robin M. Roos:
> This is fine if the database was not being written to at the time of the crash.
> However, not only will you loose data that was in the bi file, but is it not
> possible that your database's refferential integrity may be compromised ? If
> there is a chance of this then you must do a dump & reload, so that schema
> triggers can re-enforce refferenntial integrity.
>
> ...or have I got the wrong idea completely...?
Nope, it's a good point. That's one of the big problems when you lose
data and you don't know what data you lost (then again if you knew what
data you lost...). With v7 the dump & load could be used to enforce
referential integrity (if you took the time to write the triggers in the
first place...). With v6 you get to do it by hand. In either case it
might be handy to have already created the programs to verify integrity
ahead of time.
-----------------------------------------------------------------
| Tom Bascom You've just got to be persistent. |
| EDS |
| tom@lkw.com |
-----------------------------------------------------------------
</FONT f>
Similar threads
- Locked
- John Iwuozor
- Progress Blog