Advantage - FlushBuffers

[trifid]

Hallo,

ich habe früher bei Paradox-Anwendungen immer beim OnAfterPost ein

Delphi-Quellcode:

Check (DBISaveChanges (Table.Handle));

aufgeführt um sicher zu gehen, dass auch die Daten in der Datei stehen.
(wegen pessimistische und optimistische File-Lock)
Dies war einer mehrerer Punkte weshalb ich nie Probleme mit Paradox hatte :-D

Nun stelle ich gerade eine Anwendung auf den lokalen Advantage Dataset (oder wie es auch
immer heißt) um. Dabei habe ich eine Methode mit gleichen Verhalten gefunden.

Delphi-Quellcode:

TAdsTable.FlushBuffers

Ist diese Methode beim Table.OnAfterPost zu empfehlen
a) wenn ich den lokalen Advantage Dataset
b) Advantage Database Server (zukünftig geplant)
verwende ?
Ist die lokale Engine so robust das das nicht mehr benötigt wird und wie sieht es mit der Performance aus ?
Hat hier jemand schon Erfahrung sammeln können ?
Muss ich auch das optimistische filelocking berücksichtigen und in der Registry die Einträge nachziehen (Workstation, Server)?

[Bernhard Geyer]

Also ich verwende ADS (lokal Betrieb) ohne irgendwelche Buffer zu Flushen und habe bisher keine Probleme.

Performance ist sehr gut. Haben auch Datenbanken mit > 1GB im einsatz. Das einzige was Du machen solltest, ist darauf zu achten das deine Indizes günstig definiert sind. Sonst wird es langsam.

[trifid]

Hallo Bernhard,

danke für die Antwort

Zitat:

Also ich verwende ADS (lokal Betrieb) ohne irgendwelche Buffer zu Flushen und habe bisher keine Probleme.

na, das ist doch schon mal ein PLUS-Punkt

Zitat:

Performance ist sehr gut. Haben auch Datenbanken mit > 1GB im einsatz. Das einzige was Du machen solltest, ist darauf zu achten das deine Indizes günstig definiert sind. Sonst wird es langsam.

So gross sind die Daten bei mir nicht, aber die Indizes habe ich von Paradox einfach so übernommen.
Gibt es da Tricks oder Erfahrungswerte wie man beim ADS die "Indizes günstig definiert" ?
Empfiehlt es sich beim ADS einen PrimaryKey als ID-Spalte zu verwenden ?
oder kann der PrimaryKey ein zusammengesetzter Key aus mehreren Felder mit unterschiedlichen Typen sein ?

[Bernhard Geyer]

Zitat:

Zitat von trifid

So gross sind die Daten bei mir nicht, aber die Indizes habe ich von Paradox einfach so übernommen.
Gibt es da Tricks oder Erfahrungswerte wie man beim ADS die "Indizes günstig definiert" ?
Empfiehlt es sich beim ADS einen PrimaryKey als ID-Spalte zu verwenden ?
oder kann der PrimaryKey ein zusammengesetzter Key aus mehreren Felder mit unterschiedlichen Typen sein ?

Ein Index bringt dann etwas, wenn deine Abfragen so gestaltet sind, das der Query-Analyser diese auch verwenden kann.
Wenn Du sehr oft nach SpalteX suchst, so ist natürlich ein Index auf die SpalteX sinnvoll.
Ein Index/Der Primärschlüssel kann sehr wohl mehrere Spalten beinhalten. Diese dürfen bis zu 200 Zeichen (Bei Strings) beinhalten.

[Union]

Der ADS kann keine zusammengesetzten Indexausdrück im Sinne des Query-Optimizing analysieren. Zusammengesetzte Indizes sind nur wichtig, wenn man auf die Tabellen mittels Table-Objekten zugreift und dem Benutzer eine bestimmte Sortierung anzeigen möchte. Der Query-Optimizer geht auf die einzelnen Felder. Logische Konsequenz: Alle Felder, die jemals in where, order by, group by, having, join etc. verwendet werden, sollten einzeln indexiert werden. Ich habe dadurch mehrfach eine bis zu 1000-fache Performancesteigerung erlebt.

[Robert_G]

Zitat:

Zitat von Union

Der ADS kann keine zusammengesetzten Indexausdrück im Sinne des Query-Optimizing analysieren. Zusammengesetzte Indizes sind nur wichtig, wenn man auf die Tabellen mittels Table-Objekten zugreift und dem Benutzer eine bestimmte Sortierung anzeigen möchte. Der Query-Optimizer geht auf die einzelnen Felder. Logische Konsequenz: Alle Felder, die jemals in where, order by, group by, having, join etc. verwendet werden, sollten einzeln indexiert werden. Ich habe dadurch mehrfach eine bis zu 1000-fache Performancesteigerung erlebt.

1000-fach :?: :shock:
Das Beste was ich je erreicht hatte, war eine View von 0,5 Sekunden auf 15 Millisekunden zu bringen. Dafür waren aber mehrere hundert Zeilen DDL nötig und eine Tabelle in der fast nur REFs abgelegt wurden. Da das alleine noch nicht reicht musste der SQL Code so mit Optimizer hints angereichert werden, dass kein Query plan erstellt werden musste.

Ich halte beim ALS Optimierungen mit dem Faktor 100 für realistisch, aber 1000? :gruebel:

Edit: Um Missverständnisse zu verhindern: Ich habe den ALS weder benutzt noch gesehen, ich habe noch nichtmal jemandem die Hand geben, der ihn benutzt, gesehen oder sich in seiner Nähe aufgehalten hat. :mrgreen:

Die Optimierungen von oben wurden in Oracle gemacht :zwinker:

[trifid]

@union,

Zitat:

Der ADS kann keine zusammengesetzten Indexausdrück im Sinne des Query-Optimizing analysieren.

Ich würde hier zwischen zwischen den Server und den "lokalen" Betrieb unterscheiden.
Ich davon aus, dass ADSlokal das nicht kann - somal das die BDE für dBase und Paradox auch nicht konnte

Zitat:

Zusammengesetzte Indizes sind nur wichtig, wenn man auf die Tabellen mittels Table-Objekten zugreift und dem Benutzer eine bestimmte Sortierung anzeigen möchte

Zusammengesetzte Indizes sind auch dann wichtig, wenn die Dateninhalte mehrerer Felder nur einmal in der Tabelle auftreten dürfen. Dafür muss der Index dann auch unique gesetzt werden.

Zitat:

Da das alleine noch nicht reicht musste der SQL Code so mit Optimizer hints angereichert werden, dass kein Query plan erstellt werden musste.

beim optimieren heisst es, "probieren geht über studieren" - sehr mühsames geschäft

[Union]

@trifid

Zitat:

Ich würde hier zwischen zwischen den Server und den "lokalen" Betrieb unterscheiden.
Ich davon aus, dass ADSlokal das nicht kann - somal das die BDE für dBase und Paradox auch nicht konnte

Laut Dokumentation ist der einzige Unterschied zwischen ALS und Remote Server die fehlende Transaktionsverarbeitung und die Begrenzung auf maximal 5 Connections. Natürlich ist der Remote Server im Mehruser-Betrieb wesentlich performanter, weil die Wahrscheinlichkeit dass zu lesende Daten sich im Cache befinden ja größer ist.

@all
Wer ADS einsetzt, sollte sich unbedingt die neue Version 7.1 holen, die am Wochenende raus gekommen ist.

[adrian4321]

Hi!

Ist zwar ein alter Thread, ich habe aber glaube ich doch noch etwas wichtiges hinzuzufuegen, auch eine Frage....

Zunaechst habe ich in der Doku vom ADS 7.1 unter "Known differences between TAdsTable and TTable" gelesen dass FlushBuffes NICHT unterstuetzt wird. Stattdessen gibt es AdsFlushFileBuffers.

Wenn ich jetzt

Delphi-Quellcode:

AdsTable.AdsFlushFileBuffers

unter Delphi 2005 Win32 schreibe, wird AdsFlushFileBuffers rot unterringelt und der Fehler lautet "TAdsTable enthält kein Element namens 'FlushBuffers' in Zeile ...."

Allerdings ist es kein undefinierter Bezeichner, und die Anwendung laesst sich auch starten (ich vermute aber dass AdsFlushFileBuffers nicht funktionieren wird). Fehlt etwas in der uses-Liste oder wo liegt das Problem?!

Selbes Verhalten mit

Delphi-Quellcode:

AdsTable.FlushBuffers

wobei ich sowieso davon ausgehe dass FlushBuffers laut Doku einfach ignoriert wird.

ciao,
adrian

[Union]

Zitat:

Zitat von adrian4321

Hi!
Zunaechst habe ich in der Doku vom ADS 7.1 unter "Known differences between TAdsTable and TTable" gelesen dass FlushBuffes NICHT unterstuetzt wird. Stattdessen gibt es AdsFlushFileBuffers.

Das scheint ein Fehler in der Doku zu sein. Dort sind noch einige Einträge wohl nicht überarbeitet worden. Mit 7.1. kann ich durchaus TAdsDataSet.FlushBuffers aufrufen. Dies ruft wieder ACE.AdsFkushFileBuffers auf. Um auf TAdsDataSet-Methoden zugreifen zu können, muss adsdata in Deiner uses stehen.