Optimierung Datenbankzugriff Firebird

[Perlsau]

@alle: Das sind in er Tat sehr nützliche Tipps und Hinweise, die ihr da parat habt. Es wird echt Zeit, daß ich mich mit all diesen Optimierungsmöglichkeiten eingehender befasse. Immerhin hab ich heute nacht noch bis gegen 4 Uhr herumprobiert und getestet. Ich hab da eine Tabelle, die enthält 10 Felder und derzeit ca. 300.000 Datensätze. Bin noch am Einlesen, am Ende werden es knapp eine Million Datensätze sein, dazu 5 Untertabellen mit jeweils 2 bis 4 Feldern, die auch bis zu 50.000 Datensätze fassen.

Auf die meisten Tabellen werden beim Start Locate-Methoden angewandt, um die zuletzt bearbeiteten Datensätze für den Anwender sofort sichtbar zu machen. Auch das werde ich nochmal überdenken, denn eigentlich benötigt der Anwender nur zwei oder drei Tabellen, mit denen er wirklich ständig arbeitet. Das sollte auch etwas Geschindigkeit beim Start bringen.

In den Options der Tab-Kompos habe ich bereits das Property QueryRecordCount deaktiviert. Das hat die Sache schon mal ein wenig beschleunigt, denn das Durchzählen der Datensätze nimmt natürlich auch Zeit in Anspruch. Ich werde den RecordCount bei den entsprechenden Tabellen in der Anwendung verwalten.

@Holger Klemt & haentschman: Die Table-Komponente von IBdac soll ja laut Dokumentation ein direkter Abkömmling von TCustomIBCQuery sein. Aber ich probier's heute mal aus, problematische Table-Komponenten durch Queries zu ersetzen. Bei den Tabellen für Benutzereinstellungen, Benutzerrechte, Geschlecht und Anrede kann ich mir das schenken, die enthalten nur ein paar Datensätze.

@Holger Klemt: Hab leider nur die Personal-Version von IBExpert. Aber die Database-Properties kann ich mir natürlich anzeigen lassen: Unter Buffer steht Pages auf 90 und KB auf 1440. Hab jetzt mal den Wert auf 10000 kb erhöht, dabei entstehen 625 Seiten und der Sweep-Interval steht auf 20000.

Leider weiß ich nicht mehr genau, welche Firebird-Version (v2.5) ich installiert hatte, aber ich glaube mich zu erinnern, daß es er Classic-Server war. IBexpert schreibt mir das heraus, wenn ich die Servereigenschaften abfrage:
Server Version: WI-V2.5.2.26539 Firebird 2.5
Server Implementation: Firebird/x86/Windows NT
Service Version: 2

Zitat von mkinzler:

Ich vermute auch, dass es an den beim Öffnen zu ladenenden Datenmengen liegt. Ich bezweifle, dass alle 16 sofort benötigt werden und, wie haentschman schon schrieb, die bei den benötigten Tabellen nicht deren vollständigen Inhalt.

Ich glaube nicht, daß TIBCTable die gesamte Datenmenge in den Speicher lädt. Aber die Tabellen werden schon benötigt, weil sie Untertabellen für die noch fehlende Haupttabelle darstellen, die hauptsächlich aus Feldern der Untertabellen zusammengesetzt sein wird.

Zitat von mkinzler:

Zudem kannst du auch mit der embedded Dll auf einen Server zugreifen ( dann über IP)

Die Embedded.dll ist aber wesentlich größer als die "normale": 3.801.088 vs 552.960 Bytes. Das muß meiner Ansicht nach nicht sein, für den Zugriff auf den lokalen Firebird-Server die knapp 4 MB große DLL einzusetzen. Diese ist nur dafür gedacht, daß de Anwender sein Programm von einem externen Datenträger, z.B. einem Stick oder einer externen Festplatte, starten möchte. Der Anwender soll in die Lage versetzt werden, bei Bedarf Datenbank und Anwendung zu kopieren und "mitzunehmen".

@alle: Nochmal vielen Dank an euch, ich werde jetzt gleich nach dem verspäteten Frühstück darangehen, eure Vorschläge umzusetzen.

[jobo]

Meine Empfehlung wären ebenfalls Queries, die gezielt Teilmengen abrufen.
Mit Table Komponenten habe ich schon lange nicht mehr gearbeiet, gibt es da sowas wie max-records?
Wenn Du bei Tables bleiben musst/willst, probier doch mal Filter auf PK Felder, die garantiert eine leere Menge ergibt (oder eine garantiert kleine~1 Datensatz z.B...
Im weiteren Programmverlauf muss natürlich was sinnvolles in den Filter rein, Hauptsache, die große Tabellen werden nicht/niemals ungefiltert geöffnet und alles wird geladen.

[Perlsau]

Zitat von jobo:

Meine Empfehlung wären ebenfalls Queries, die gezielt Teilmengen abrufen.
Mit Table Komponenten habe ich schon lange nicht mehr gearbeiet, gibt es da sowas wie max-records?
Wenn Du bei Tables bleiben musst/willst, probier doch mal Filter auf PK Felder, die garantiert eine leere Menge ergibt (oder eine garantiert kleine~1 Datensatz z.B...
Im weiteren Programmverlauf muss natürlich was sinnvolles in den Filter rein, Hauptsache, die große Tabellen werden nicht/niemals ungefiltert geöffnet und alles wird geladen.

Ebenso wie TIBCTable fragt TIBCQuery nur die Anzahl an Zeilen aus der zugrundeliegenden DB-Tabelle ab, die im Property FetchRows angegeben ist, das bei mir defaultmäßig auf 25 steht. Nur bei Abfrage von RecordCount, dem Setzen des Properties FetchAll oder/und dem Setzen des Properties QueryRecCount werden alle Datensätze abgefragt, aber außer bei FetchAll nicht im Speicher behalten. Diese drei Properties stehen bei mir alle auf False.

Mit dem Umstellen von TIBCTable auf TIBCQuery habe ich das goldene Los gezogen, die Startzeit hat sich nun merklich verringert:

Code:

IF NOT DatMod.Verbinden_Datenbank THEN   124
IF NOT DatMod.Verbinden_Tabellen THEN     31
Set_Einstellungen;                      2156

[IBExpert]

Zitat von Perlsau:

Auf die meisten Tabellen werden beim Start Locate-Methoden angewandt, um die zuletzt bearbeiteten Datensätze für den Anwender sofort sichtbar zu machen. Auch das werde ich nochmal überdenken, denn eigentlich benötigt der Anwender nur zwei oder drei Tabellen, mit denen er wirklich ständig arbeitet. Das sollte auch etwas Geschindigkeit beim Start bringen.

Locate ist meistens ein blödes Verfahren, weil eben alle Records zum Client geliefert werden, bis derjenige kommt, den du haben wolltest. Das entschidet aber der Client. Ist bei Filterproperties auch oft so ähnlich. Da kannst du auch bei der Auskunft anrufen und dir das Telefonbuch komplett vorlesen lassen. Bei kleinen Datenmengen ist das egal, aber 300000 oder 1000000 Records sind keine kleine Datenmenge mehr.

Zitat von Perlsau:

Hab leider nur die Personal-Version von IBExpert. Aber die Database-Properties kann ich mir natürlich anzeigen lassen: Unter Buffer steht Pages auf 90 und KB auf 1440. Hab jetzt mal den Wert auf 10000 kb erhöht, dabei entstehen 625 Seiten und der Sweep-Interval steht auf 20000.
...

Leider weiß ich nicht mehr genau, welche Firebird-Version (v2.5) ich installiert hatte, aber ich glaube mich zu erinnern, daß es er Classic-Server war. IBexpert schreibt mir das heraus, wenn ich die Servereigenschaften abfrage:
Server Version: WI-V2.5.2.26539 Firebird 2.5
Server Implementation: Firebird/x86/Windows NT
Service Version: 2

Das sieht also nach Classic aus (oder Superclassic). Trag mal da wo jetzt 625 steht 5000 ein, dann müsste rechts 80000kb stehen (das wären 80 MB cache pro Connection, der Wert wird auch in der DB gespeichert). Wenn du keinen konkreten Grund hast, dann am besten noch mal deinstallieren und als Superserver neu installieren, das hat für jemanden, der nicht im Thema drin ist, meistens Vorteile, weil beim Superserver solange noch mindestens eine Connection geöffnet ist alle Daten im Cache bleiben und jeder Client die Abfragen wenn möglich aus dem Cache beantwortet bekommt. Je langsamer die festplatte, um so größer die Vorteile des Superservers. Beim Classic hat jede Connection immer einen eigenen Cache, das macht nur Sinn bei extrem schnellen Datenträgern, z.B. Enterprise SSDs. Beim Superserver kannst du den Cache auch auf z.B. 20000 setzen. Sweep Interval ist dafür erst mal nicht relevant.

Wenn du noch mehr Infos zu Firebird brauchst und dir mal hier und da Zeit dafür nehmen kannst, dann würde ich mal so nach und nach die Videos auf http://www.youtube.com/user/IBExpertise oder im IBExpertLive Player (http://ibexpert.net/ibe/index.php?n=Doc.IBExpertLive) anschauen, da sind auch einige deutschsprachige Schulungen von uns dabei.

[IBExpert]

Zitat von Perlsau:

Hab leider nur die Personal-Version von IBExpert

kann man ändern, gibt es für facebook likes als Sonderpreis für 99 €
https://www.facebook.com/IBExpertise...51161908249538

[tsteinmaurer]

Zitat:

Locate ist meistens ein blödes Verfahren, weil eben alle Records zum Client geliefert werden, bis derjenige kommt, den du haben wolltest

Um Mißverständnissen vorzubeugen. Das war zu Zeiten der BDE. IBObjects zum Beispiel ist da viel cleverer. IBDac eventuell auch. Ist mit der Trace API nun alles schön transparent, was da von den Zugriffskomponenten teilweise verbrochen wird. Aber das Thema Trace API wurde ja bereits erwähnt ...

[IBExpert]

Zitat von tsteinmaurer:

Zitat:

Locate ist meistens ein blödes Verfahren, weil eben alle Records zum Client geliefert werden, bis derjenige kommt, den du haben wolltest

Um Mißverständnissen vorzubeugen. Das war zu Zeiten der BDE. IBObjects zum Beispiel ist da viel cleverer. IBDac eventuell auch. Ist mit der Trace API nun alles schön transparent, was da von den Zugriffskomponenten teilweise verbrochen wird. Aber das Thema Trace API wurde ja bereits erwähnt ...

hier mal ein Ausschnit aus der aktuelle Implementation TCustomSQLDataSet.LocateRecord
in XE4 unit Data.SqlExpr, das sieht mir nicht besonders clever aus.

Der rennt sogar zwei mal durch die Datenmenge, wenn beim ersten Durchlauf keine
Übereinstimmmung gefunden wurde. Und diese Implementation ist leider nicht unüblich,
auch wenn andere Komponenten das ggf irgendwie anders lösen, da sollte man sich aber
nicht drauf verlassen.

Code:

    First;
    while not EOF do
    begin
      if CheckValues(AFields, Values, CaseInsensitive, PartialLength) then
        break;
      Next;
    end;
    { if not found, reset cursor to starting position }
    bFound := not EOF;
    if not bFound then
    begin
      First;
      while not EOF do
      begin
        if CheckValues(SaveFields, StartValues, False, False) then
          break;
        Next;
      end;
    end;
    Result := bFound;

"Das war zu Zeiten der BDE" ist da also doch nicht ganz zutreffend ...

[Perlsau]

Den Übeltäter für die langen Wartezeiten beim Starten meiner Anwendung habe ich jetzt eindeutig ausgemacht: Er heißt Sortieren. Nachdem ich alle Zuweisungen an IndexFieldNames – jenes Property der IBDac-Query-Komponenten, das für die Sortierung zuständig ist – entfernt hatte, warte ich ca 2 Sekunden darauf, daß die Anwendung zur Verfügung steht (ohne Ladezeit, da sind's dann schätzungsweise 3,5 Sekunden, also nur für den Aufbau der Anwendung im Speicher). Sobald ich jedoch sortieren lasse, ist die Geschwindigkeit dahin, ganz besonders bei meiner größten Tabelle mit derzeit um die 300.000 Einträgen und etlichen Abhängigkeiten. Eigentlich wird ja nicht die eigentliche Tabelle sortiert, sondern lediglich das View, das ich von dieser Tabelle in der DB angelegt habe. Die Sortierung des Views geht weitaus schneller als die der eigentlichen Tabelle mit ihren Lookup-Feldern. Leider war es mir bislang nicht möglich, die Sortierung des Vies zu beschleunigen, sie benötigt noch immer ca. 26 sec. Und da noch ca. 700.000 Einträge folgen werden, muß ich leider auf die Sortierung dieses speziellen Views beim Programmstart verzichten. Immerhin geht die Sortierung mittels Zuweisungen an IndexFieldNames mehr als 10 mal schneller als mittels Manipulation der Order-Klausel im Select-Befehl, die dauerte nämlich 157 Sekunden.

[Perlsau]

Wenn ich die Sortierung ganz weglasse, benötigt der Start noch immer ca. 11 Sekunden. Kommentiere ich auch noch das Lokalisieren der zuletzt angezeigten Datensätze aus (locate), bin ich bei 46 Millisekunden Startzeit. Ich werde mich also darauf beschränken, die Haupttabelle, die noch gar nicht implementiert ist, zu sortieren und lokalisieren. Das werden bei einem Durchschnittsanwender sicher nicht mehr als 10- bis 20tausend Einträge werden ...

[mkinzler]

Und wenn du eine Query nimmst und im SQL-Statement sortierst?