ODBC und Journaling

[Neptun]

Der Lesezugriff ist leider verdammt lahm ... ich habe mir mal das ODBC.log angeguckt. Mir wurde ganz anders ... Ich vermute mittlerweile, dass das Journaling nicht die Quelle des Performance-Übels ist.

In meinem Testbeispiel sind ein paar hundert Sätze zu lesen, jeweils mit ca. 250 Spalten. Es werden natürlich alle Felder schön artig mit SQLBindColumn gebunden. Allerdings nicht nur einmal, sondern bei jedem (!) SQLFetch (es war klar das SQLFetchScroll [ganzen Block direkt in eine Tabelle lesen] vom Tool nicht verwendet wird, dazu müsste man die Anwendung ja auch stärker umprogrammieren; mal gnz abgesehen davon, dass das Tool dies gar nicht unterstützt, *lol*). Es gibt zwar einen START, für den man auch die WHERE-Klausel beeinflussen kann, aber dennoch wird für jeden SQLFetch wieder 250 mal SQLBindColumn gemacht. Aaaahhhh, ich brauche jetzt jemanden zum Erwürgen


Gruß
Neptun

[BenderD]

Hallo,

bevor du würgst, solltest du vielleicht mal den Database Monitor konsultieren, da siehst du was die Datenbank draus macht - möglicherweise sind da auch Probleme im Spiel, die man auf Ebene der Datenbank bessern kann (fehlende Indexe). BTW: bei Lesezugriffen ist Journaling aussen vor, Commit level könnte natürlich dennoch eine Rolle spielen (so ab Repeatable Read im Sinne von ANSI SQL)

mfg

Dieter Bender

Der Lesezugriff ist leider verdammt lahm ... ich habe mir mal das ODBC.log angeguckt. Mir wurde ganz anders ... Ich vermute mittlerweile, dass das Journaling nicht die Quelle des Performance-Übels ist.

In meinem Testbeispiel sind ein paar hundert Sätze zu lesen, jeweils mit ca. 250 Spalten. Es werden natürlich alle Felder schön artig mit SQLBindColumn gebunden. Allerdings nicht nur einmal, sondern bei jedem (!) SQLFetch (es war klar das SQLFetchScroll [ganzen Block direkt in eine Tabelle lesen] vom Tool nicht verwendet wird, dazu müsste man die Anwendung ja auch stärker umprogrammieren; mal gnz abgesehen davon, dass das Tool dies gar nicht unterstützt, *lol*). Es gibt zwar einen START, für den man auch die WHERE-Klausel beeinflussen kann, aber dennoch wird für jeden SQLFetch wieder 250 mal SQLBindColumn gemacht. Aaaahhhh, ich brauche jetzt jemanden zum Erwürgen


Gruß
Neptun

[Fuerchau]

Das könnte auch an irgendeiner fehlenden PREPARED-Einstellung liegen.
Wenn der SQL im Programm nicht statisch ist, kann kein Prepare verwendet werden und somit ist das Binden immer neu erforderlich.
Scheinbar arbeitet dein Tool nicht mit Prepared und ist somit für Massendaten nicht geeignet sondern ist wohl ausschließlich für Dialoge konzipiert.

[Neptun]

@Fuerchau
Korrekt, es wird nicht mit SQLPrepare und SQLExecute gearbeitet, sondern nur mit SQLExecDirect (so konnte ich es im sql.log erkennen). Jedes Statement wird mit SQLAllocStmt zugewiesen, dann SQLExecDirect, dann wird gebunden mit SQLBindCol, dann kommt der SQLFetch, und dann wird mit SQLFreeStmt wieder alles freigegeben.

Konnte bis jetzt noch keine Einstellung finden, um dieses Verhalten zu beeinflussen.


Gruß
Neptun

[Fuerchau]

Dann würde ich dir empfehlen, falls möglich, mit ActiveX-Komponenten wie ADO oder halt direkt selber mit CLI (Das sind dieses SQLxxx-Funktionen) zu arbeiten.