You didn't mention what O/S or Progress version? I don't know that it makes a difference though.
Now, the 837 error is interesting. In the Knowledge base, it is associated with corruption in the Before Image and\or After Image files.
In your case, it seems to be a problem with the BI file or worse, the DB itself. Hope you have a good backup.
Here's the KB entry:
**************************************
SYSTEM ERROR: Physical redo, BKUPDCTR=n, note updctr=n. (873)
If a customer attempts to start a broker or a single user session
and sees error 873 when Progress tries to go through crash recovery,
before concluding that there is bi file corruption, you can try to
restart the session with the -G startup parameter. The -G startup
parameter specifies the number of seconds before Progress reuses a
BI cluster.
The format is:
-G seconds
Example:
proserve demo -G 180
** The -G startup parameter is supported in versions 6.3F, 7.3A and
later releases of Progress. **
The -G startup parameter should only be used if the second number
reported in the error message "note updctr" is larger than the first
number "BKUPDCTR". The first number reported is the update counter
found in the database block. The second number is the update counter
of the block recorded in the bi note when the block was changed.
When the block update counter is less than that of the note it means
that changes that should have been applied to the block during the
REDO phase of crash recovery were not.
This can occur because the REDO phase of crash recovery started with
a cluster that was not old enough. The -G parameter can be used to
cause crash recovery to start with an older bi cluster. -G 1800
means start with the bi cluster that closed at least 30 minutes
before the crash. Normally, specifying -G 1800 will cause crash
recovery to start with the oldest cluster in the bi file.
This may cause the bi file to increase more than normally in size
during crash recovery. When using -G 180 for example, advises the
Progress DBMS not to re-use space in a bi cluster unless it has been
closed for at least 180 seconds, or 3 minutes. The default is 60
seconds. When we flush modified blocks from the buffer pool the
setting of 180 means we allow for the OS to take as long as 180
seconds to actually get the modified blocks on disk; otherwise we
expect that the OS will accomplish this within 60 seconds. Thus -G
can be used to adjust how much a bi cluster should age before we
re-use the space.
If setting the -G parameter results in crash recovery failing in the
same way, then this means that a cluster was re-used during forward
processing that was needed to recover the database in the event of a
crash and the database cannot be recovered. The only options at this
point are to restore from backup and apply the appropriate ai file,
or if a backup is not available, force access to the database
immediately followed by a dump and load of its contents.
NOTES: The -G startup parameter is documented here as a means by which
to complete crash recovery. The examples shown should not be added to
your broker startups for normal use, unless otherwise determined by
your system administrator.
Our documentation for Version 7.3A indicates that the -G startup
parameter is only useful for Data General systems. This could more
appropriately be worded that this is useful for all UNIX systems,
and it is particularly useful for DG systems. This is because the
default time for the unix buffer flush on DG is greater than 60
seconds, indicated by the MAXBUFAGE kernel parameter. The default
for -G is 60 seconds and this must be at least 30 seconds greater
than the MAXBUFAGE kernel parameter. If MAXBUFAGE is greater than 30
which it is by default, then -G must be set to be 30 seconds greater
than this parameter, OR MAXBUFAGE should be lowered to 30 seconds.
This way the default of 60 for -G leaves the 30 second margin between
the two. It would be safer still to set -G to be at least 60 seconds
greater than MAXBUFAGE.
NOTE: If this does not resolve the issue, you must either restore a
backup of the database or force in with pro dbname -F and dump and
reload the data. This is the only recovery from this error. A mock
index rebuild after a forced access does not resolve any potential
corruption.
*****************************************
This is interesting because I've seen 873 myself on our test DB, but didn't think to look it up in the KB, because I was distracted by other messages in the log.
Hope this helps you out, I know it did me!
regards,
bill
