Subject | Index problem that need to be drop and recreated |
---|---|
Author | gwc8182 |
Post date | 2007-08-07T02:04:22Z |
Dear All,
Currently using Firebird-1.5.1.4481 Superserver on
Window 2000.
I have two database in this server.
When I perform a searching on the smaller database the
cpu usage will spike to high cpu usage for few
seconds. But on the bigger and much more data database
does not have this problem.
When copying the smaller database to another pc, it
will not have this problem.(This I cannot confirm
because it is done by the customer)
Both database design the is exactly the same.
I perform gbak on the database but did not help.
Only later when I drop and recreate back the index and
perform another gbak the database searching does not
cause a high cpu usage.
My question is what could have happened that required
dropping and recreating the database? I would suspect
the index is somehow corrupted, if that the case, any
way I could also check for that since gbak didn't pick
it up ?
If the index not optimised correctly, doesn't the gbak
restore create back the index correctly ?
Could it be the firebird version being a bit too old?
Though am planning to move to Firebird 2.0.1
A year or two ago, I did encounter the same problem
before from a different customer with different
computer setup, but the firebird version was the same.
Just Wondering.......
John
Currently using Firebird-1.5.1.4481 Superserver on
Window 2000.
I have two database in this server.
When I perform a searching on the smaller database the
cpu usage will spike to high cpu usage for few
seconds. But on the bigger and much more data database
does not have this problem.
When copying the smaller database to another pc, it
will not have this problem.(This I cannot confirm
because it is done by the customer)
Both database design the is exactly the same.
I perform gbak on the database but did not help.
Only later when I drop and recreate back the index and
perform another gbak the database searching does not
cause a high cpu usage.
My question is what could have happened that required
dropping and recreating the database? I would suspect
the index is somehow corrupted, if that the case, any
way I could also check for that since gbak didn't pick
it up ?
If the index not optimised correctly, doesn't the gbak
restore create back the index correctly ?
Could it be the firebird version being a bit too old?
Though am planning to move to Firebird 2.0.1
A year or two ago, I did encounter the same problem
before from a different customer with different
computer setup, but the firebird version was the same.
Just Wondering.......
John