Subject | JOIN PLAN changed after backup/restore. |
---|---|
Author | KIMURA, Meiji |
Post date | 2006-05-29T19:30:34Z |
Hi All,
The specific JOIN SQL became slow then I checked the SQL with PLAN (set plan on in isql
environment). PLAN shows the SQL using 3 indexes. After I backup/restore the database,
I run the same JOIN SQL. PLAN shows the SQL using 1 index and it become fast. In my knoledge,
backup and restore optimize *physical* data, not *logical* data. I wonder why backup/restore
affect the PLAN of JOIN SQL.
I have two question.
Q1. This situation often occurs in operation of firebird ?
Q2. How do I avoid that JOIN SQL become slow? Can I predict with some tools?
[Environment]
Firebird: CS-1.5.0.4290-0
Linux: Red Hat Enterprise Linux ES release 3(Taroon Update2)
Middleware: JayBird1.5.5
Memory: 2G-byte
Regards,
KIMURA, Meiji(FAMILY, Given)
Tokyo, JAPAN
The specific JOIN SQL became slow then I checked the SQL with PLAN (set plan on in isql
environment). PLAN shows the SQL using 3 indexes. After I backup/restore the database,
I run the same JOIN SQL. PLAN shows the SQL using 1 index and it become fast. In my knoledge,
backup and restore optimize *physical* data, not *logical* data. I wonder why backup/restore
affect the PLAN of JOIN SQL.
I have two question.
Q1. This situation often occurs in operation of firebird ?
Q2. How do I avoid that JOIN SQL become slow? Can I predict with some tools?
[Environment]
Firebird: CS-1.5.0.4290-0
Linux: Red Hat Enterprise Linux ES release 3(Taroon Update2)
Middleware: JayBird1.5.5
Memory: 2G-byte
Regards,
KIMURA, Meiji(FAMILY, Given)
Tokyo, JAPAN