| Subject | Re: [firebird-support] Re: Corrupted primary key |
|---|---|
| Author | Ann W. Harrison |
| Post date | 2010-07-26T21:33:21Z |
Alec Swan wrote:
convey much information. You seem to be using "primary key" as
shorthand for "primary key index". Which is OK, but you don't say
how you decided the index was corrupt. I'm guessing that there were
missing entries, but without more of a hint, I can't go much further.
Do you still have a copy of the database with the misbehaving index?
If so, could you run gstat and report on the population of the table
and the index? Losing values in an index is very bad and may be the
symptom of a bug we should understand. Or it may be something very
nasty in your environment - like a disk controller that lies about
writing.
Firebird on Linux (which version did you say you have?) and you've
had system crashes, Firebird will flush all pages dirtied by a
transaction on commit.
So, without more information, there's not much to say.
Good luck,
Ann
p.s. Nobody, nobody, nobody at all (except MySQL) designs databases
so they lose data in indexes or tables. So please help us find this
problem
>IBPhoenix, among others, provides commercial support.
> I haven't received any answers to my question below in almost a week.
> Not sure if my messages don't get posted on the list or just not being
> answered.
>
> What commercial support options are available? Any contact information
> will be greatly appreciated.
>Part of the problem is that the phrase "corrupted primary key" doesn't
>>
>> We just ran into a problem (in production) where a corrupted primary key
>> caused the query to return incorrect results. We rebuilt statistics on all
>> indexes in the database, but that didn't fix the problem. We had to drop and
>> re-create the primary key to fix the problem.
convey much information. You seem to be using "primary key" as
shorthand for "primary key index". Which is OK, but you don't say
how you decided the index was corrupt. I'm guessing that there were
missing entries, but without more of a hint, I can't go much further.
Do you still have a copy of the database with the misbehaving index?
If so, could you run gstat and report on the population of the table
and the index? Losing values in an index is very bad and may be the
symptom of a bug we should understand. Or it may be something very
nasty in your environment - like a disk controller that lies about
writing.
>>In theory, unless you have fsync turned off - or an old version of
>> Our maintenance plans "set statistics" as Ann suggested in this thread
>> (http://tech.groups.yahoo.com/group/firebird-support/message/106971).
>> However, this new problem requires us to drop and recreate primary keys.
>>
>> My understanding is that the original problem reported in
>> (http://tech.groups.yahoo.com/group/firebird-support/message/106971) was
>> caused by "bad memory chip" or maybe some other hardware failure. Has there
>> been any work done in the recent Firebird releases to protect or recover
>> from this kind of problems? If not, how can we reduce the likelihood of
>> these problems occurring in the future, e.g. flush to disk more often?
Firebird on Linux (which version did you say you have?) and you've
had system crashes, Firebird will flush all pages dirtied by a
transaction on commit.
So, without more information, there's not much to say.
Good luck,
Ann
p.s. Nobody, nobody, nobody at all (except MySQL) designs databases
so they lose data in indexes or tables. So please help us find this
problem