Performanceprobleme Firebird Datenbankanwendung

[erich.wanker]

Hallo Delphianer,

ich habe ein Performance-Problem mit meiner Software. Gehen tut´s um einen Win32 bit Anwendung die mit Delphi7 erstellt wurde die auf einem Win2008 R2 Server läuft (User arbeiten Remote).

Datenbankengine Firebird. 2.1 (Classic Server Installation)
Zugriff ZeosLib 6.6.6-stable
Verbindung ZConnection (Autocommit=true, protocol=firebird-2.0,Trans.IsolatLevel=tiReadCommitted
Selektierung ZQuerys (CachedUpdat=False, FetchRow=0, SortType=stAscending, UpdateMode=umUpdateChanged, WhereMode=wmWhereKeyOnly)
Datenbankname: Database.FDB


SQL Statement, was sehr langsam ist

SELECT FIRST 300 SKIP 0 * FROM DETAIL_DB INNER JOIN KEY_DB ON KEY_DB.INR_OWN = DETAIL_DB.INR AND KEY_DB.INR_PARENT = 92321 AND DETAIL_DB.STATUS_INFORMATION NOT CONTAINING'd1' AND KEY_DB.INR_MENU = 3 AND DETAIL_DB.ERLEDIGT = 0 AND DETAIL_DB.PERMISSION_FOR_VIEW CONTAINING'a' AND DETAIL_DB.STATUS_INFORMATION NOT CONTAINING 'z9' AND DETAIL_DB.STATUS_INFORMATION NOT CONTAINING 'x1' ORDER BY DETAIL_DB.DATE2 ASCENDING, DETAIL_DB.OBJECT_NAME

Indexdateien von Key_DB und Detail_DB:
siehe Bilder

Hat jemand einen Tipp, wie ich das ganz beschleunigen kann oder wo ich einen Fehler habe? .. ich bastle jetzt schon ewig rum, mir gehen aber die Ideen aus ... :-(

Vielen Dank für Tipps und Hinweise

LiGrü aus dem tief verschneiten Gasteinertal

erich

[Lemmy]

Hallo Erich,

was genau ist das Problem? die SQL Anweisung an sich? d.h. ist die auch in isql oder vergleichbaren Programmen langsam oder nur in Verbindung mit Zeos? In IBExpert (zumindest in der Kaufversion) gibts eine Leistungsanalyse - da siehst Du dann ganz schnell ob ggf. ein Zugriff auf eine Tabelle ohne Index abläuft, weil z.B. der Index schlecht ist.

[Perlsau]

Du könntest vielleicht aus deinem Select-Statement ein View in Firebird basteln, auf das du dann mit einem weiteren Dataset zugreifst. Ob das dann schneller geht, wird sich zeigen ...

[Lemmy]

ähm.. jetzt habe ich mir mal das SQL genauer angeschaut:

Code:

SELECT FIRST 300 SKIP 0 * 
FROM DETAIL_DB INNER JOIN KEY_DB ON KEY_DB.INR_OWN = DETAIL_DB.INR 

AND KEY_DB.INR_PARENT = 92321 
AND KEY_DB.INR_MENU = 3 AND DETAIL_DB.ERLEDIGT = 0 
AND DETAIL_DB.PERMISSION_FOR_VIEW CONTAINING'a' 

AND DETAIL_DB.STATUS_INFORMATION NOT CONTAINING'd1' 
AND DETAIL_DB.STATUS_INFORMATION NOT CONTAINING 'z9' 
AND DETAIL_DB.STATUS_INFORMATION NOT CONTAINING 'x1' 

ORDER BY DETAIL_DB.DATE2 ASCENDING, DETAIL_DB.OBJECT_NAME

ich würde den Join über eine Bedingung aufbauen - den Rest dann in eine Where schieben, weil das nix mit dem Join zu tun hat. Weiterhin gibts sage und schreibe 4 Containing. Irgend wo im Bauch sagt mir was, dass das nicht sonderlich toll ist. Was genau steht denn in Status_Information drin? nur die 2-stelligen Angaben oder mehr?

GRüße

[tsteinmaurer]

Ausführungsplan wär nicht schlecht. Würde auf jeden Fall mal probieren die JOIN-Bedingung nur auf die Schlüsselfelder zu machen und die einschränkenden Bedingungen in der WHERE-Klausel. Da kannst dann hoffen, dass die Ergebnismenge schon soweit eingeschränkt ist, dass die NOT CONTAINING nicht mehr weh tun.