Subject | RE: [firebird-support] Log Error / corrupt database - need quick help if possible |
---|---|
Author | Kevin Stanton |
Post date | 2005-02-15T19:40:49Z |
Thanks Ann, really appreciate the info.
Kevin
_____
From: Ann W. Harrison [mailto:aharrison@...]
Sent: Tuesday, February 15, 2005 11:29 AM
To: firebird-support@yahoogroups.com
Subject: Re: [firebird-support] Log Error / corrupt database - need quick
help if possible
Kevin.Stanton@...
asked for some information on these error messages...
well-hidden bugs) in the savepoint code that can cause consistency check
errors. The fixes are in 1.5x but not 1.0x, if I recall correctly.
This series of messages suggests that the original error was an update
conflict. It probably occurred in a stored procedure that had no error
handling for update conflicts. Mixing what (little) I remember from the
changes to savepoint handling, the operation included multiple updates
to the same record in different, nested procedures.
keeps the database on disk consistent at all times - assuming you're
running with forced writes on. To do so, in the case of a garbage
collecting back version on a different page from the main version, it
first clears the pointer to the back version, writes that page, then
releases the back version and writes that page. If the server crashes
between the two operations, the back version continues to occupy space,
but isn't part of any particular record any more. Hence, orphaned.
crashed.
crashed.
Regards,
Ann
[Non-text portions of this message have been removed]
Kevin
_____
From: Ann W. Harrison [mailto:aharrison@...]
Sent: Tuesday, February 15, 2005 11:29 AM
To: firebird-support@yahoogroups.com
Subject: Re: [firebird-support] Log Error / corrupt database - need quick
help if possible
Kevin.Stanton@...
asked for some information on these error messages...
> >Nickolay (and others, no doubt) have fixed several obscure problems (aka
>
> DATA01 (Server) Tue Feb 15 08:37:12 2005
> Database: E:\IBDATA~1\LUMBER\LUMBER.GDB
> deadlock
> update conflicts with concurrent update
> operation was cancelled
> internal gds software consistency check (error during savepoint
> backout (290))
well-hidden bugs) in the savepoint code that can cause consistency check
errors. The fixes are in 1.5x but not 1.0x, if I recall correctly.
This series of messages suggests that the original error was an update
conflict. It probably occurred in a stored procedure that had no error
handling for update conflicts. Mixing what (little) I remember from the
changes to savepoint handling, the operation included multiple updates
to the same record in different, nested procedures.
>Orphan back versions are benign results of server crashes. Firebird
> DATA01 (Server) Mon Feb 14 16:21:41 2005
> Database: E:\IBDATA~1\LUMBER\LUMBER_X.GDB
> Relation has 361 orphan backversions (207357 in use) in table
> CUSTOMERS (161)
keeps the database on disk consistent at all times - assuming you're
running with forced writes on. To do so, in the case of a garbage
collecting back version on a different page from the main version, it
first clears the pointer to the back version, writes that page, then
releases the back version and writes that page. If the server crashes
between the two operations, the back version continues to occupy space,
but isn't part of any particular record any more. Hence, orphaned.
>Somebody tried to use a connection to a server after than server had
>
> DATA01 (Client) Mon Feb 14 14:31:43 2005
> INET/inet_error: connect errno = 10061
crashed.
> DATA01 (Server) Mon Feb 14 13:45:51 2005Somebody tried to use a connection to a server after than server had
> INET/inet_error: select in packet_receive errno = 10038
crashed.
Regards,
Ann
[Non-text portions of this message have been removed]