Laden...

Deadlocks Mehrbenutzer Datenbank

Erstellt von mosspower vor 15 Jahren Letzter Beitrag vor 15 Jahren 5.461 Views
mosspower Themenstarter:in
456 Beiträge seit 2007
vor 15 Jahren
Deadlocks Mehrbenutzer Datenbank

Hallo "Kollegen",

ich wollte einmal Fragen, ob es zu sog. Deadlocks kommen kann, wenn mehrere Programme auf die gleiche Datenbank (teilweise auf die gleichen Daten) zugreifen? Ich dachte immer, dass das DBMS Concurrent-Zugriffe nach dem FiFo-Prinzip regelt und die anderen Anfragen in eine Queue stellen. Täusche ich mich hier? Löscht Connection A einen Datensatz und zur (scheinbar) gleichen Zeit will Connection B ein Update durchführen, dann kommt eben die Meldung zurück, dass Datensatz nicht mehr vorhanden ist. Ich habe gerade in unserer Firma ein älteres Programm übernommen, welches immer wieder sog. Deadlocks-Exception wirft (VBA-Anwendung). Wie kann das denn zustande kommen? Das ist mir ein Rätsel (vielleicht wird auch der Name Deadlock in der Fehlermeldung soz. mißbraucht, denn unter einem klassischem Deadlock stelle ich mir etwas anderes vor). Hat jemand eine Idee was das sein könnte. Kommt an verschiedenen Stellen häufiger vor im Programm - ich habe keinen Blassen, was das sein könnte.

630 Beiträge seit 2007
vor 15 Jahren

Hallo,

um was für ein DBMS handelt es sich?

Gruss
tscherno

To understand recursion you must first understand recursion

http://www.ilja-neumann.com
C# Gruppe bei last.fm

X
1.177 Beiträge seit 2006
vor 15 Jahren

Huhu,

ja, es kann zu ähnlichen Sperren kommen (aber keine Deadlocks), wenn ein SQL-Statement länger eine DB sperrt als das andere Statement einen Timeout hat. Beim SQL-Server kenn ich noch eine andere Meldung (weiss nicht mehr genau wie die heisst) ala "Dein DB-Zugriff hat bei einem Konkurierenden Zugriff verloren und wurde verworfen". Das Prinzip das Du ansprichst hängt vom DBMS und etwaigen verwendeten Techniken ab (z.B: Transaction mit langer laufzeit gegen ein einziges Update Statement).

schliesse mich Tscherno an.

🙂

Xynratron

Herr, schmeiss Hirn vom Himmel - Autsch!

Die Erfahrung zeigt immer wieder, dass viele Probleme sich in Luft auslösen, wenn man sich den nötigen Abstand bzw. Schlaf gönnt.

mosspower Themenstarter:in
456 Beiträge seit 2007
vor 15 Jahren

Moin,

eine VBA-Anwendung (in Access) greift auf einen SQL-Server (Version 8 ) zu. Die Fehlermeldungen lauten immer (leider auf deutsch):

_**Laufzeitfehler '-2147467259 (80004005)'

Die Transaktion (Prozess-ID 69) befand sich auf lock Ressourcen wegen eines anderen Prozesses in einer Deadlocksituation und wurde als Deadlockopfer ausgewählt. Führen Sie die Transaktion erneut aus.**_

Es wird definitiv (auch nicht mit anderen Programmen) mit Transaktionen und / oder Threads gearbeitet. Mir ist bisher nicht bekannt, dass eine Anwendung einen ähnlichen Fehler verursacht. An was kann das denn liegen, hat jemand eine Idee? Wie kann denn so eine, hm, ich sage jetzt mal "Pseudodeadlocksituation" entsteht?

X
1.177 Beiträge seit 2006
vor 15 Jahren

huhu

Microsoft OLE DB Provider for SQL Server (0x80004005)
Your transaction (process ID #<spid>) was deadlocked with another process and has been chosen as the deadlock victim. Rerun your transaction.

laufen die Transaktionen/SQL-Statements sehr lange bzw. bearbeiten diese viele Datensätze auf einmal? Ich kenne dieses Verhalten wie gesagt nur, wenn eine Transaktion z.B. alle Datensätze in einer Tabelle bearbeitet (dadurch alles sperrt) und ein anderer Batch darauf zugreifen will und praktisch sein Timeout abläuft.

Du kannst den SQL-Server Profiler mitlaufen lassen um mal die SQL-Statements zu analysieren (oder passiert der Fehler immer an denselben Stellen?). Werden explizit irgendwelche locks gesetzt?

🙂

Xynratron

Herr, schmeiss Hirn vom Himmel - Autsch!

Die Erfahrung zeigt immer wieder, dass viele Probleme sich in Luft auslösen, wenn man sich den nötigen Abstand bzw. Schlaf gönnt.

3.825 Beiträge seit 2006
vor 15 Jahren

Meinstest Du "definitiv NICHT" ?

Der SQL Server (und andere) bettet jedes Update und Insert Kommando in eine Transaktion.

Dead Locks (nicht mit der Frisur zu verwechseln, bei der man sich nie die Haare waschen muss) enstehen, wenn Prozess A auf die Beendigung von B wartet und B auf die Beendigung von A.

Einige DBMS erkennen Deadlocks und lösen diese nach einer gewissen Zeit auf, indem eine Transaktion rückgängig gemacht wird (das Opfer). Dies muss eigentlich in der Transaktion aufgefangen werden und die Transaktion muss erneut durchgeführt werden.

Man kann Dead Locks vermeiden, indem man Resourcen immer in der gleichen Reihenfolge sperrt.

Grüße Bernd

Workshop : Datenbanken mit ADO.NET
Xamarin Mobile App : Finderwille Einsatz App
Unternehmenssoftware : Quasar-3

130 Beiträge seit 2005
vor 15 Jahren

Arbeitet deine Anwendung vielleicht mit Rowlocks?

mosspower Themenstarter:in
456 Beiträge seit 2007
vor 15 Jahren

Ich habe jetzt mal nachgefragt, leider sind fast keine Leute mehr in meiner jetzigen Firma, die überhaupt wissen, was läuft. Ich habe jetzt in Erfahrung gebracht, dass es genauso sein kann, wie tscherno beschrieben, dass ein anderer Prozess ziemlich lang braucht um irgendswelche Positionen abzuarbeiten und dann fällt dieser "Pseudodeadlock". Ich muss da mal tiefer reinschauen (leider VBA 😦) ... und natürlich auch kein Exceptionhandling drinnen. Also, danke erst mal für die Antworten - ich werde in Zukunft, wenn ich es gelöst habe, dann nochmal einen Post hier reinstellen. Also, danke erst mal.

mosspower Themenstarter:in
456 Beiträge seit 2007
vor 15 Jahren

Meinstest Du "definitiv NICHT" ?

Der SQL Server (und andere) bettet jedes Update und Insert Kommando in eine Transaktion.

Dead Locks (nicht mit der Frisur zu verwechseln, bei der man sich nie die Haare waschen muss) enstehen, wenn Prozess A auf die Beendigung von B wartet und B auf die Beendigung von A.

Einige DBMS erkennen Deadlocks und lösen diese nach einer gewissen Zeit auf, indem eine Transaktion rückgängig gemacht wird (das Opfer). Dies muss eigentlich in der Transaktion aufgefangen werden und die Transaktion muss erneut durchgeführt werden.

Man kann Dead Locks vermeiden, indem man Resourcen immer in der gleichen Reihenfolge sperrt.

Grüße Bernd

Sorry, ich meinte natürlich definitiv nicht 😁 ... ja, es ist halt in dem Uraltprogramm (das übrigens jetzt auch nicht ein "Starcoder" gemacht hat) keinerlei Exceptionhandling + Modularisierung + Transaktionen usw. drinnen. Ich hatte halt mal nachgefragt, da ich jetzt (noch) nicht so fit in VBA bin und ich dem Coder seine Logik noch nicht "durchstiegen" habe.

4.931 Beiträge seit 2008
vor 15 Jahren

Hallo BerndFfm,

Dead Locks (nicht mit der Frisur zu verwechseln, bei der man sich nie die Haare waschen muss) enstehen, wenn Prozess A auf die Beendigung von B wartet und B auf die Beendigung von A.

du meintest wohl "Dread Locks" Dread Locks -)