Performance-Unterschied

[MPirnstill]

Hallo Leute!

Ich weiß nicht, ob ihr es wußtet, aber ich könnte in diesem Forum falsch sein. Aber ich versuch es eben einmal.

Ich habe da ein etwas "älteres" Problem. Älter, da es sich um eine Delhpi 2 Enterprise Anwendung handelt mit der ich auf einen
MS-SQL-Server 6.5 zugreife. Jetzt wurde der SQL-Server gegen einen MS-SQL-Server 2000 ausgetauscht, was auch mit kleinen Problemchen ganz gut klappte. Im Rahmen dieser Umstellung soll die Anwendung jetzt über ODBC statt BDE - SQLLinks zugreifen. Heutzutage ist ODBC ja auch schneller als die BDE.

Mein Problem dabei ist folgendes:
Auf meinem Entwickulungssystem (Pentium 4, 3 Ghz, 500 MB Ram) funktioniert das wunder-schnuffig. Alles blitzschnell. Eine Sekunde um einen Erfassungsdialog zu öffnen. Auf dem Rechner des Anwenders (gleiches System wie mein Entwicklungsrechner) benötigt die gleiche EXE 17 Sekunden um einen Erfassungsdialog zu öffnen. Beim Start der MDI-Anwendung wäre dies nicht so wild (passiert ja nur zu beginn), aber beim Öffnen eines Erfassungsdialogs ist das schon sehr lästig, vor allem wenn die Anwender vorher schnelleres gewöhnt sind. Da es die gleiche EXE ist, vermute ich das ich da noch etwas mitinstallieren muß, weiß aber nicht was.
Die Installation habe ich mit InstallShield 3.5 SP 4 (von der Delphi 7 Version) erstellt. Bei den Merge-Modulen habe die BDE-ENT, BDERTL, BaseRTL sowie DatabaseRTL angekreuzt. Dementsprechnd ist die BDE 5.1 mitinstalliert. Ach ja, irgendwie will die Anwendung immer noch die BDE initialisieren, obwohl ich beim TDatabase-Objekt den Zugriff auf ODBC umgeleitet habe.

Bin für jegliche Hinweise sehr dankbar.

Micha

[Bernhard Geyer]

Du hast einen großen Fehler bei der Umstellung gemacht: Du gehst über ODBC mittels TDatabase/TTable/TQuery. Und damit bist du die BDE nicht los, da TDatabase/TTable/TQuery-BDE-Basierend sind.

Wieso hast Du dein Programm nicht gleich auf ADO(Express) umgestellt. Ist ab D5 (Enterprise) bzw. D6 Pro dabei (D8 schaut es schlecht aus, aber D2005 ist es wieder dabei).

Damit wärst Du die BDE und auch gleich die ODBC-Schnittstelle auch los. Alles was Du benötigst ist eine halbwegs aktuelle ADO-Installation (sollte praktisch auf fast jeden halbwegs modernen Rechner der Falls sein). Ab 2000 ist es sowieso gleich in einer passenden Version dabei. Und ebenfalls setzt du ziemlich direkt auf die native Schnittstelle des MS SQL-Servers 7/2000 auf.

[shmia]

Ich würde erst mal die Datenbankstruktur unter die Lupe nehmen.
Nur wenn die Datenbank sauber aufgebaut ist, kann die Performance stimmen.

• Haben alle Tabellen einem Primärschlüssel ?
• Haben alle Tabellen einen gruppierten index (Clustered Index) ?
• Sind alle Fremdschlüsselfelder indiziert ?

Zu den beiden ersten Punkten gibt es 2 nützliche Views:

SQL-Code:

CREATE VIEW dbo.vwNoPrimaryKeys
AS
SELECT name
FROM sysobjects
WHERE id NOT IN
        (SELECT b.id
      FROM sysconstraints b, sysobjects c
      WHERE c.type = 'K' AND c.id = b.constid) AND type = 'U'

SQL-Code:

CREATE VIEW dbo.vwNoClusteredIndex
AS
SELECT   name
FROM         dbo.sysobjects so
WHERE     (NOT EXISTS
                          (SELECT     si.id
                            FROM          sysindexes si
                            WHERE      indid = 1 AND si.id = so.id)) AND (type = 'U')
ORDER BY name

[Bernhard Geyer]

Ein problem mit dem Index sollte es nicht sein, da das Programm ja auf seinem Rechner (ich denke es wird die gleiche Datenbank verwendet) läuft als auch mit BDE-Links auch keine Probleme hatte.

[nieurig]

Neben der DB-Struktur ist auch sehr wichtig,
wieviele Daten beim öffnen des Formulares von
der DB abgefragt werden.

Schlimmste Version:
Tabelle öffnen und mit locate auf einen
Datensatz gehen der angezeigt wird.

Viel besser:
Beim Öffnen des Forms nur per
Select * from Tabelle where ID = ??
den anzuzeigenden Datensatz laden. Stammen
die Daten aus mehreren Tabellen dann macht
sich die DB-Struktur und besonders die Indexes
bemerkbar.

Schönen Tag noch !
Niels

[shmia]

Zitat von Bernhard Geyer:

Ein problem mit dem Index sollte es nicht sein, da das Programm ja auf seinem Rechner (ich denke es wird die gleiche Datenbank verwendet) läuft als auch mit BDE-Links auch keine Probleme hatte.

Naja, sobald die Datenmenge etwas grösser wird ( > einige hundert Datensätze) steigt die Zugriffszeit linear bis quadratisch an, wenn nicht die richtigen Indexe angelegt wurden.

Abfragen, die auf der Testdatenbank nur 0,1 Sekunden brauchen, können dann in der Praxis beim Kunden mehrere Minuten bis zum Timeout-Fehler brauchen.

Dies trifft auch dann zu, wenn man den Fehler, den nieurig bschrieben hat, begangen hat.
In diesem Fall kann auch das Netzwerk zum Flaschenhals werden. (z.B. Zuhause 100MBit, beim Kunde nur 10 Mbit)

[Bernhard Geyer]

Zitat von shmia:

Naja, sobald die Datenmenge etwas grösser wird ( > einige hundert Datensätze) steigt die Zugriffszeit linear bis quadratisch an, wenn nicht die richtigen Indexe angelegt wurden.

Abfragen, die auf der Testdatenbank nur 0,1 Sekunden brauchen, können dann in der Praxis beim Kunden mehrere Minuten bis zum Timeout-Fehler brauchen.

Dies trifft auch dann zu, wenn man den Fehler, den nieurig bschrieben hat, begangen hat.
In diesem Fall kann auch das Netzwerk zum Flaschenhals werden. (z.B. Zuhause 100MBit, beim Kunde nur 10 Mbit)

Lassen wir Micha mal uns weitere Infos geben, bevor wir hier weiter in Spekulationen uns auslassen.
Und diese "Indexproblem" kenn ich. Hab selbst DB's im Einsatz die mit Datenmengen > 4 GB zurechtkommen müssen.

Fragen an Micha:

- Werden auf dem Entwicklungs-PC und dem Problem-PC mit der gleichen (Produktiv-)Datenbank verbunden?
- Wenn das BDE-Links-Programm auf dem Problem-PC läuft, sind die Wartezeiten ähnlich?

[MPirnstill]

Vielen Dank für die schnellen Antworten! Super!

Zitat von Bernhard Geyer:

Du hast einen großen Fehler bei der Umstellung gemacht: Du gehst über ODBC mittels TDatabase/TTable/TQuery. Und damit bist du die BDE nicht los, da TDatabase/TTable/TQuery-BDE-Basierend sind.

Wieso hast Du dein Programm nicht gleich auf ADO(Express) umgestellt. Ist ab D5 (Enterprise) bzw. D6 Pro dabei (D8 schaut es schlecht aus, aber D2005 ist es wieder dabei).

Damit wärst Du die BDE und auch gleich die ODBC-Schnittstelle auch los. Alles was Du benötigst ist eine halbwegs aktuelle ADO-Installation (sollte praktisch auf fast jeden halbwegs modernen Rechner der Falls sein). Ab 2000 ist es sowieso gleich in einer passenden Version dabei. Und ebenfalls setzt du ziemlich direkt auf die native Schnittstelle des MS SQL-Servers 7/2000 auf.

Ich vergaß zu erwähnen, das dies eine Notlösung sein soll, da ich ich die Komplettumstellung der Anwendung auf WEB nicht termingerecht fertig bekomme, wurde beschlossen vorerst die alte Anwendung mit geringem Aufwand anzupassen.
Deshalb bin ich bei Delphi 2 geblieben und habe nicht auf einer höheren Version compiliert. Außerdem hätte ich bei einer höheren Version alle Quickreports neu machen müssen, da diese ja nicht mehr kompatibel wären. Aber sonst wäre das eine gute Idee mit ADO. Wären die TTables den einfach durch die ADOTables ersetzbar?

Zitat von shmia:

Haben alle Tabellen einem Primärschlüssel ?

Haben alle Tabellen einen gruppierten index (Clustered Index) ?

Sind alle Fremdschlüsselfelder indiziert ?

Die Tabellen haben alle einen Primärschlüssel. Aber vielen Dank für die Views für die System-tabellen. Die finde ich gut.

Zitat von nieurig:

Schlimmste Version:
Tabelle öffnen und mit locate auf einen
Datensatz gehen der angezeigt wird.

Ich muß leider eingestehen, das es so ist, jedoch ohne locate, da einfach der erste Datensatz angezeigt wird.
Vielleicht sollte ich, da es wie gesagt eine Notlösung ist, hier ansetzen und einfach erstmal den ersten Datensatz holen um der Anwendung Zeit zu verschaffen den Rest ranzuschaffen.


Mehr gleich zu Bernhards Fragen. Will erstmal diese Antwort los werden. Habe die schon einmal verloren.

[MPirnstill]

Zitat von Bernhard Geyer:

Zitat von shmia:

Naja, sobald die Datenmenge etwas grösser wird ( > einige hundert Datensätze) steigt die Zugriffszeit linear bis quadratisch an, wenn nicht die richtigen Indexe angelegt wurden.

Abfragen, die auf der Testdatenbank nur 0,1 Sekunden brauchen, können dann in der Praxis beim Kunden mehrere Minuten bis zum Timeout-Fehler brauchen.

Dies trifft auch dann zu, wenn man den Fehler, den nieurig bschrieben hat, begangen hat.
In diesem Fall kann auch das Netzwerk zum Flaschenhals werden. (z.B. Zuhause 100MBit, beim Kunde nur 10 Mbit)

Lassen wir Micha mal uns weitere Infos geben, bevor wir hier weiter in Spekulationen uns auslassen.
Und diese "Indexproblem" kenn ich. Hab selbst DB's im Einsatz die mit Datenmengen > 4 GB zurechtkommen müssen.

Fragen an Micha:

- Werden auf dem Entwicklungs-PC und dem Problem-PC mit der gleichen (Produktiv-)Datenbank verbunden?
- Wenn das BDE-Links-Programm auf dem Problem-PC läuft, sind die Wartezeiten ähnlich?

Vom Umfang her ist die Produktiv-Datenbank mit der Test-Datenbank identisch. Allerdings habe ich eine extra SQL-Server zum testen. Auf dem neuen Produktiv-Server ist aber noch kein weiterer Anwender drauf, da ich das ja erst noch teste.
So jetzt der Knack-Punkt. Ich habe mit meinem Test-SQL-Server eine 1,0 GBit Verbindung und die Verbindung vom Test-Rechner zum Produktiv-Server ist 10 MBit glaub ich. Unser Admin sagte, daß sei in Ordnung. Liegt es jetzt doch an der Netzverbindung?

Zu BDE-Links auf dem Test-Rechner. Das muß ich mit dem neuen Produktiv-Server erst noch ausprobieren. Beim alten SQL-Server 6.5 lief es über BDE-Links auf jeden Fall schneller.

Micha

[Bernhard Geyer]

Zitat von MPirnstill:

So jetzt der Knack-Punkt. Ich habe mit meinem Test-SQL-Server eine 1,0 GBit Verbindung und die Verbindung vom Test-Rechner zum Produktiv-Server ist 10 MBit glaub ich. Unser Admin sagte, daß sei in Ordnung. Liegt es jetzt doch an der Netzverbindung?

Dann könnte es schon sein das Du dein Programm optimieren musst.

Zitat von MPirnstill:

Zu BDE-Links auf dem Test-Rechner. Das muß ich mit dem neuen Produktiv-Server erst noch ausprobieren. Beim alten SQL-Server 6.5 lief es über BDE-Links auf jeden Fall schneller.

Teilweise könnte es sein das die alten Links öfters den Vorteil von serverseitigen Cursern ausnutzen konnte wo der Zugriff über ODBC nur einen clientseitigen Curser liefert. Und da muß die gesamte Datenmenge zum Client übertragen werden bevor sie angezeigt werden kann.