Office: (Office 2013) Abfrage 2 Tabellen aus 2 SQL Datenbanken sehr langsam

Hallo liebe Community,

ich habe ein riesen Problem. Ich kombiniere in einer Abfrage (für Endlosformular) 2 Tabellen aus 2 getrennten SQL Datenbanken. Das geht auch alles (Erster Abruf auch schnell), nur beim Filtern wird es dann enorm langsam.

Wie kann ich das umgehen oder ist es einfach nicht performant umzusetzen, 2 getrennte Datenbanken in Abfragen gleichzeitig anzusprechen?

Sollte ich die Datenbanken fusionieren oder lässt sich das vermeiden?


Die Tabellen sind über ODBC verbunden.


DANKE!!!!

:)

 

Was sind bei Dir SQL Datenbanken konkret?

Filtern ist nicht gleich Filtern. Wie sieht es aus mit Indexnutzung?

 

es sind mySQL datenbanken. Beide beim selben Provider, über VPN verbunden, aber separate Datenbanken.

Indizes helfen hier nicht weiter...

Ich glaube es ist generell langsam wenn ich noch Tabellen in Access mit Abfragen verbinden muss als Datenquelle. Ich glaube das ist der Haken. Ansonsten nehme ich immer VIEWs, die ich im MySQL Backend zusammenbaue, da treten die Probleme nicht auf. Nur hier muss ich leider die Tabellen in Access Abfragen kombinieren. Also wie kann ich das lösen?! :S

 

Hallo,

das ist eine gewagte Behauptung.

 

soll ich alle Felder indizieren oder nur die, die gefiltert werden?

Falls alle, soll ich wirklich 20-30 Indizes anlegen? ich kann es mal versuchen...

 

Hallo,
nur die die gefiltert werden.

 

Nicht nebenbei:
Einen Index müsste man auch nutzen, nicht nur haben. Also spielt da auch das Abfragedesign eine Rolle.

 

könntest du mir das etwas genauer erklären bitte?

Also ich habe jetzt eine Access Abfrage auf die 2 vernüpften MySQL Tabellen mit Join, diese wiederum sind VIEWs die in phpMyAdmin angelegt sind.

Wie genau "nutze" ich jetzt die Indizes?*boah

PS: ich bin Amateur ist mir schon klar*biggrin.gif*

 

Du könntest damit beginnen, Dir den Inhalt des Links in #2 inhaltlich zu erschließen, manchmal hilft auch ein mehrmaliges Durchlesen mit einer Sauerstoffdusche dazwischen. In dem Text ist ein weiterer Link mit dann konkreteren Infpormationen ...

Für solch ein "fundiertes" Urteil kann man doch die Gründe gleich mitliefern. Dann riecht es nicht so nach Abwehr- und Schutzbehauptung.

 

meine Antwort war so gemeint, dass ich die Indizes bereits vergeben habe, aber vermutlich nutze ich sie falsch wie du in deinem artikel beschreibst, davon hatte ich keine ahnung.

ich lese mir das durch und hoffe es so gelöst zu bekommen, danke sehr *Smilie

und bitte verzeihe meine unwissenheit, es ist noch kein meister vom himmel gefallen *tongue.gif*

 

Du hast die kritischen Punkte hier sehr gut zusammengefasst.

Ein paar Denkansätze.

1.) Sind es "nur" separate Datenbanken oder liegen diese auch auf verschiedenen Servern? - Man kann durchaus Tabellen aus verschiedenen DBs (auf dem gleichen Server) in einer MySQL-View verwenden.
Selbst wenn es verschiedene Server sind, die sich aber im gleichen Rechenzentrum befinden, gibt es die Möglichkeit in MySQL Federated Tables zu verwenden, die sicherlich unter den Umständen eine wesentlich bessere Performance liefern, als die Daten in lokalen Access-Abfragen zusammenzuführen.

2.) Wenn die obigen Ansätze allesamt nicht möglich sind, würde ich versuchen, dass du deine Access Abfragen so gestaltest, dass möglichst die einzelnen Tabellen für sich gefiltert werden, und erst dann in Access der Join der Daten passiert.
D.h. erstmal je eine Abfrage auf die entsprechende Tabelle mit den dafür geltenden Kriterien und dann obendrüber die zusammenfassende Abfrage.
Schwierig ist dabei, dass du nicht einfach Filter auf oberster Ebene anwenden kannst, sondern diese auf den untergeordneten Einzelabfragen angewendet werden müssen.

Beide Ansätze sollten dazu führen, dass die Indizes sehr wohl weiterhelfen!

 

Vielen Dank *Smilie

diese Federated Tables klingen nach der perfekten Lösung, aber ich habe die DBs bei All Inkl und befürchte dass das da nicht geht, ich habe beim Support angefragt. Sie müssten auf demselben Server liegen, da sie unter derselben Vertragsnr. laufen.

Ich denke auch mein selbstgebauter Echtzeitfilter (Endlosformular) ist performance technisch eine Katastrophe (mit Like und * *boah ), auch wenn er sonst perfekt läuft und die Performance bisher ausreichend war.
Aber da nun auch noch eine Abfrage in Access davorgeschaltet ist, scheinen genau an dieser Stelle enorme Performanceprobleme zu entstehen.


Punkt 2 ist auch sehr interessant, aber recht aufwendig mein Frontend dahingehend anzupassen. Wäre aber vielleicht immernoch besser als die DBs zu fusionieren.

 

Die Umformulierung einer Abfrage ist jetzt keine Komplett-Neugestaltung eines Frontends, sondern eine punktuelle Korrektur.

 

Also ich frage mich woher du weißt, wie aufwendig diese Anpassung in meiner Datenbank wäre, ohne zu wissen wie viele Endlosformulare und Filterfunktionen ich habe, aber gut. Es ist jedenfalls weit mehr als die Änderung einer Abfrage und wäre enormer Aufwand.


Jetzt nochmal zum eigentlichen Problem, denn die genaue Filterfunktion ist gar nicht mein Problem. Ich habe folgendes festgestellt:


Access Abfrage mit JOIN auf diese 2 Tabellen geht sehr schnell (0,5 Sekunden)

Dieselbe Abfrage mit einem "where left(SPALTE,1)=1" dauert gleich 5 Sekunden, also 10x so lange, nur wegen einer winzigen Where Bedingung. Die Spalte ist indiziert.

Bedeutet: Alle "WHERE" oder "LIKE" Ansätze laufen katastrophal langsam im Vergleich zum normalen Aufrufen der JOIN-Abfrage.


Das kann doch nicht sein?! Da muss doch ein simpler Fehler vorliegen oder?

 

Hallo!

Ja, der Fehler liegt an der Deaktivierung der Index-Nutzung durch den berechneten Ausdruck.

Code:

Der Index auf SPALTE kann nicht genutzt werden, da zuerst left(..., 1) berechnet werden muss. (BTW: Left gibt einen Text zurück => Vergleichswert muss auch ein Text sein => where left(SPALTE,1)='1')

Besser:
Code:

Ansonsten:

Ist das nur die Zeit zum Öffnen der Abfrage oder die Zeit, nachdem alle Datensätze geladen sind?

mfg
Josef