Abfrage in DB A sperrt Tabellen in DB B

A

achris

Benutzer
Beiträge
6
Hallo Zusammen,

Ausgangssituation: verwendet wird MySQL 5.0.x mit myISAM Tabellen

Es gibt die Datenbank "live" und die Datenbank "Entwicklung", wobei "Entwicklung" eine Kopie der "live" Datenbank ist, mit relativ aktuellen Daten und exakt gleicher Tabellenstruktur. Auf der "live"-Datenbank tummeln sich viele Kunden.

Daher habe ich für eine performancelastige Abfrage einfach die Entwicklungsdatenverwendet. Die Abfrage war von der Art der Art "Alle Kunden die im Frühjahr 2014 einen Artikel der Gruppe X gekauft haben, danach aber nie wieder etwas der Art Y .... und außerdem nicht an Aktion Z teilgenommen usw... "

Die Abfrage braucht erwartungsgemäß (trotz der üblichen Optimierungen) etwas länger, würgt mit aber zeitglich die "live" Datenbank ab, die ich ja verschonen wollte.

Klar gibt es CPU und RAM Restriktionen auf einer gemeinsam genutzten Hardware. Allerdings zeigt "SHOW PROCESSLIST", dass die Abfrage in Datenbank "Entwicklung" dafür sorgt, dass in der Datenbank "live" praktisch alle Abfragen den Status "LOCKED" haben. Alles staut sich hinter der einen fiesen Abfrage auf der Datenbank "Entwicklung". Es gibt doch logisch keinen Grund für das DBMS, die vielen kleinen Abfragen auf der "live" DB warten zu lassen.

Ja. ich habe auch bei Joins darauf geachtet, auch tatsächlich in meiner Entwichlungsdatenbank zu bleiben. Es wird sogar ein anderer Datenbankuser verwendet.

Mir ist schon mehrfach aufgefallen, dass Aktionen in der Entwicklungs-Datenbank wie "Spalten konvertieren" oder "Index einfügen" bei großen Tabellen, auch (sperrende) Auswirkungen auf die live Datenbank haben, die über CPU und Speicherengpässe hinausgehen. Warum ist das so? Gibt es da einen Workaround?
Hat jemand eine Idee oder ähnliche Erfahrungen?
 
Werbung:
Kopie wurde mit mysqldump erstellt.

Ganz dunkle Ahnung. Es gibt noch eine 3. und 4. Datenbank, in der statistische Daten gespeichert werden "live_stats" und "Entwicklung_stats". Da gibt es einen Trigger der eine Fallunterscheidung trifft, je nachdem ob er gerade im Test oder im Live System ist, etwa in der Art:

IF((SELECT DATABASE())='live_stats') THEN
UPDATE live.a SET...
ELSE
UPDATE entwicklung.a SET...

Kann es sein, dass mysql daraus eine Verbindung / Abhängigkeit von live.a und entwicklung.a ableitet?

Grundsätzlich entnehme ich der Rückfrage, dass das beobachtete Verhalten tatsächlich ungewöhnlich ist? Danke schon mal für diese erste Erkenntnis.
 
achris schrieb:
Ganz dunkle Ahnung. Es gibt noch eine 3. und 4. Datenbank, in der statistische Daten gespeichert werden "live_stats" und "Entwicklung_stats". Da gibt es einen Trigger der eine Fallunterscheidung trifft, je nachdem ob er gerade im Test oder im Live System ist, etwa in der Art:

IF((SELECT DATABASE())='live_stats') THEN
UPDATE live.a SET...
ELSE
UPDATE entwicklung.a SET...

Kann es sein, dass mysql daraus eine Verbindung / Abhängigkeit von live.a und entwicklung.a ableitet?
Zum Vergrößern anklicken....
Wahrscheinlich.

Grundsätzlich entnehme ich der Rückfrage, dass das beobachtete Verhalten tatsächlich ungewöhnlich ist? Danke schon mal für diese erste Erkenntnis.
Zum Vergrößern anklicken....

Grundsätzlich hat MySQL immer ein ungewöhnliches Verhalten. Zumindest für Leute, die andere Systeme kennen.
 
Du kannst die verdächtigen Trigger auf deiner Test-DB ja mal auskommentieren an den Stellen, wo sie in andere DBs schreiben. Dann sollte sich herausstellen ob es daran liegt.

Grundsätzlich ist MyISAM immer sehr gut wenns darum geht Tabellen zu sperren.
 
Hmmm, aus sämtlichen Triggern der Entwicklungsdatenbanken habe ich nun die Verweise auf die live-Datenbanken herausgenommen (und die Trigger natürlich neu gesetzt). Allerdings scheint das nicht die Ursache gewesen zu sein. Die Abfrage (oder Varianten davon) in der Entwicklungsumgebung führen immer noch zu einem LOCK in den live Tabellen. Habe die Abfragen inzwischen auch im 6-Augen Prinzip prüfen lassen. Es gibt keine Beziehung zu den Tabellen in der live-DB. Dafür spricht ja auch, dass Spaltenkonvertierungen oder das Einfügen eines Index auf große Tabellen in der Entwicklungs DB zu LOCKs in der live-DB führen.
Auch SHOW PROCESSLIST zeigt mir an, dass ich mit dem Entwicklungsuser in der Entwicklungs-DB unterwegs bin.
 
akretschmer schrieb:
Grundsätzlich hat MySQL immer ein ungewöhnliches Verhalten. Zumindest für Leute, die andere Systeme kennen.
Zum Vergrößern anklicken....
Ich habe in den letzten 20 Jahren mit Oracle, Informix, MS-SQL-Server, PostgreSQL und mySQL gearbeitet. Jedes der Systeme zeigte bisher ein ungewöhnliches Verhalten, insbesondere wenn sie mit großen Datenmengen oder großer Last konfrontiert werden. Das Herumhacken auf einzelnen Systemen bringt nix. Oft ist die Systemwahl durch externe Rahmenbedingungen gesetzt. Wer Systeme nur aus ideologischer Überzeugung heraus wählt, gefährdet ggf. Unternehmen... davon könnte ich auch Geschichten erzählen, aber das würde zu weit führen. ;-)
 
Nein, keine Views... das mit den Beziehungen bezog sich auf die einzelnen SQL-Abfragen (über JOINs etc.) Irgendeine Beziehung (auf welcher Ebene auch immer) muss es ja geben. Dass es allein die gleichen Tabellennamen sind, möchte ich an dieser Stelle einfach (noch nicht) glauben...
 
Werbung:
Gleiche Tabellennamen ließen sich ja auch recht einfach ausschließen in dem man einfach eine Testtabelle (mit anderem Namen) in der Test-DB anlagt und ein bischen mit Datenmüll voll schreibt (irgendeine Schleife erzeugt INSERTs).
 
Zurück
Oben