Subject | RE: [firebird-support] FBServer goes to rail |
---|---|
Author | Bill Greenwaldt |
Post date | 2009-10-16T12:44:39Z |
All,
Follow on questions extracted.
That's too vague. What does "clean old transactions and alerts from the
database" mean, actually?
Records from two different tables. Strings.
How do you know it's a corrupt database? What symptoms do you get that
leads to that conclusion?
gfix -v -full nets the following:
Summary of validation errors
Number of index page errors : 4
Number of database page errors : 5
"gone to rail" = ?????
Thrashes, consumes all of the available processor resources
(Task Manager shows task consuming 88 to 92 % of CPU as available.)
Describe what "locking up" means here.
System runs apps employing several external hardware
components. The hardware system becomes inoperative. Trivial task on the
operating system become burdensome due to no available processor.
gfix with which switch[es] delivers what information indicating a
problem?
See also second response.
If you want help in this list with what might be going on in the
database, you'll need to provide some info that describes the symptoms
in terminology that doesn't require others to recognize the idiom of
your programming environment.
My first exposure to the forum. Sorry.
Some times the devils in the details. Bottom line is, this
is a known corrupt database that I am working backwards on, basically a
post mortem. The first indication that there is a problem is that it
behaves badly when the perl scripts executes. The perl script and it's
actions, (get a record count in one operation, fetch records in groups
of 500 and delete them individually), may or may not be the root cause
of the problem. My real desire is to get more predictable behavior out
of Firebird when it encounters this, which is a little crazy, trying to
get something predictable out of something that is known corrupt. That's
why I thought the state information and the output of the DBI showing
the actions on the database may be more meaningful to a DB guru.
Thanks,
Bill Greenwaldt
Software Engineer
Perceptics
Imaging Technology Solutions
P. (865)671-9286 F. (865)966-9330
________________________________
From: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com] On Behalf Of Helen Borrie
Sent: Thursday, October 15, 2009 11:03 PM
To: firebird-support@yahoogroups.com
Subject: Re: [firebird-support] FBServer goes to rail
At 05:41 AM 16/10/2009, you wrote:
database" mean, actually?
How do you know it's a corrupt database? What symptoms do you get that
leads to that conclusion?
Describe what "locking up" means here.
problem?
If you want help in this list with what might be going on in the
database, you'll need to provide some info that describes the symptoms
in terminology that doesn't require others to recognise the idiom of
your programming environment.
The ODBC driver isn't on the Agenda in this forum: but if you can
provide some driver-specific messages, symptoms, etc., in a
non-idiomatic fashion, there is likely to be someone in the
firebird-odbc-devel list who can help you to straighten out your ODBC
problems. There's a subscriber interface for all of the lists at
www.firebirdsql.org/index.php?op=lists
These are peer-group forums with lots of people willing to help others
out of their difficulties. Bear in mind that the majority of us don't do
Perl and that some of the folk most likely to understand your problems
do not have English as first language.
./heLen
[Non-text portions of this message have been removed]
Follow on questions extracted.
That's too vague. What does "clean old transactions and alerts from the
database" mean, actually?
Records from two different tables. Strings.
How do you know it's a corrupt database? What symptoms do you get that
leads to that conclusion?
gfix -v -full nets the following:
Summary of validation errors
Number of index page errors : 4
Number of database page errors : 5
"gone to rail" = ?????
Thrashes, consumes all of the available processor resources
(Task Manager shows task consuming 88 to 92 % of CPU as available.)
Describe what "locking up" means here.
System runs apps employing several external hardware
components. The hardware system becomes inoperative. Trivial task on the
operating system become burdensome due to no available processor.
gfix with which switch[es] delivers what information indicating a
problem?
See also second response.
If you want help in this list with what might be going on in the
database, you'll need to provide some info that describes the symptoms
in terminology that doesn't require others to recognize the idiom of
your programming environment.
My first exposure to the forum. Sorry.
Some times the devils in the details. Bottom line is, this
is a known corrupt database that I am working backwards on, basically a
post mortem. The first indication that there is a problem is that it
behaves badly when the perl scripts executes. The perl script and it's
actions, (get a record count in one operation, fetch records in groups
of 500 and delete them individually), may or may not be the root cause
of the problem. My real desire is to get more predictable behavior out
of Firebird when it encounters this, which is a little crazy, trying to
get something predictable out of something that is known corrupt. That's
why I thought the state information and the output of the DBI showing
the actions on the database may be more meaningful to a DB guru.
Thanks,
Bill Greenwaldt
Software Engineer
Perceptics
Imaging Technology Solutions
P. (865)671-9286 F. (865)966-9330
________________________________
From: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com] On Behalf Of Helen Borrie
Sent: Thursday, October 15, 2009 11:03 PM
To: firebird-support@yahoogroups.com
Subject: Re: [firebird-support] FBServer goes to rail
At 05:41 AM 16/10/2009, you wrote:
> We are having some problems with database corruption. We areThat's too vague. What does "clean old transactions and alerts from the
>running Windows XP SP2 with Firebird 2.0 and ODBC driver 2.00.00.144.
>While the database is connected and being serviced we have a clean
>script scheduled for 2:00 a.m. that uses the perl DBI to clean old
>transactions and alerts from the database.
database" mean, actually?
>When the script runs on a corrupt database the script completes anddoesn't detect any error.
How do you know it's a corrupt database? What symptoms do you get that
leads to that conclusion?
>When the script is exited the FBServer.exe task has gone to railconsuming 88
>to 92 % of the CPU and our system becomes unusable."gone to rail" = ?????
>Our system locking up is our first evidence that a problem exists.There is no evidence of the failure in Firebird.log.
Describe what "locking up" means here.
>GFix does flesh out there is a problem but this is post mortem.gfix with which switch[es] delivers what information indicating a
problem?
>I have attempted to add debug and set up the SIG ALRM features in perlemploying an eval construct but as soon as a call
>is made to fetch() or connect(). The next time the clean scripts arerun
>the call to fetch() makes the server instance go to rail and doesn't[snip lots of stuff]
>respond. Halting Firebird Server seems to flesh out that the problem:
If you want help in this list with what might be going on in the
database, you'll need to provide some info that describes the symptoms
in terminology that doesn't require others to recognise the idiom of
your programming environment.
The ODBC driver isn't on the Agenda in this forum: but if you can
provide some driver-specific messages, symptoms, etc., in a
non-idiomatic fashion, there is likely to be someone in the
firebird-odbc-devel list who can help you to straighten out your ODBC
problems. There's a subscriber interface for all of the lists at
www.firebirdsql.org/index.php?op=lists
These are peer-group forums with lots of people willing to help others
out of their difficulties. Bear in mind that the majority of us don't do
Perl and that some of the folk most likely to understand your problems
do not have English as first language.
./heLen
[Non-text portions of this message have been removed]