Sperren auf SQL Server blockieren System
verwendetes Datenbanksystem: <Microsoft SQL Server>
Hallo,
jetzt brauche ich mal Hilfe. In meinem Programm greife ich über ADO.NET auf den SQL-Server zu. Bei den Zugriffen auf die Datenbank werden Datensätze angelegt, geändert und selten auch mal gelöscht.
Diese Vorgänge werden einzeln oder zu mehreren Befehlen in eine Transaktion verpackt. Eine Transaktion kann bis zu mehreren Sekunden dauern, wenn mehrere Tabellen und Zeilen angesprochen werden.
Bei einem einzigen Kunden hängt sich das System regelmäßig auf, die Clients bleiben hängen und bekommen nach langer Zeit ein Timeout.
System :
Framework 3.5
SQL Server : 2008 R2 Standard (10.50.1600.1)
Server OS : 2008 R2 (Virtuelle Maschine)
Transaction IsolationLevel : ReadUncommitted (Dirty Read erlaubt)
Transaction Deadlocks werden im Programm automatisch aufgelöst, falls sie vorkommen.
Nach meinem Verständniss müsste der SQL Server kurzzeitig Sperren einrichten, solange die Transaktion läuft, also einige Sekunden. Danach müssten die Sperren wieder verschwinden.
Wieso bleiben die Sperren bestehen und behindern alle anderen Vorgänge ?
Mit dem SQL-Befehl 'exec sp_lock' lasse ich mir die Sperren anzeigen. In der Spalte 'Name' lasse ich zusätzlich den Namen der Tabelle anzeigen.
Kann jemand an diesen Sperren etwas erkennen ?
Grüße Bernd
spid dbid ObjId IndId Type Mode Status Name
51 7 0 0 DB S GRANT
52 7 0 0 DB S GRANT
53 7 0 0 DB S GRANT
54 5 0 0 DB S GRANT
55 7 0 0 DB S GRANT
56 7 0 0 DB S GRANT
58 7 0 0 DB S GRANT
60 7 0 0 DB S GRANT
61 7 0 0 DB S GRANT
61 1 1131151075 0 TAB IS GRANT
62 7 0 0 DB S GRANT
63 7 0 0 DB S GRANT
64 7 0 0 DB S GRANT
65 7 2121058592 1 PAG IU GRANT zf
65 7 181575685 0 TAB IX GRANT ar
65 7 2121058592 0 TAB IX GRANT zf
65 7 229575856 0 TAB IX GRANT br
65 7 229575856 1 KEY X GRANT br
65 7 389576426 0 TAB IX GRANT ad
65 7 261575970 0 RID X GRANT ml
65 7 229575856 5 KEY X GRANT br
65 7 613577224 0 TAB IX GRANT fa
65 7 181575685 1 PAG IX GRANT ar
65 7 0 0 DB S GRANT
65 7 261575970 0 PAG IX GRANT ml
65 7 2121058592 1 PAG IX GRANT zf
65 7 389576426 1 PAG IX GRANT ad
65 7 261575970 0 TAB IX GRANT ml
65 7 613577224 1 KEY X GRANT fa
65 7 229575856 4 KEY X GRANT br
65 7 229575856 3 KEY X GRANT br
65 7 229575856 4 PAG IX GRANT br
65 7 229575856 5 PAG IX GRANT br
65 7 389576426 1 KEY X GRANT ad
65 7 229575856 2 PAG IX GRANT br
65 7 629577281 1 PAG IX GRANT po
65 7 2121058592 1 KEY X GRANT zf
65 7 2121058592 1 KEY U WAIT zf
65 7 229575856 2 KEY X GRANT br
65 7 229575856 3 PAG IX GRANT br
65 7 613577224 1 PAG IX GRANT fa
65 7 181575685 1 KEY X GRANT ar
65 7 629577281 1 KEY X GRANT po
65 7 629577281 0 TAB IX GRANT po
65 7 229575856 1 PAG IX GRANT br
68 7 0 0 DB S GRANT
69 7 0 0 DB S GRANT
71 7 0 0 DB S GRANT
71 7 245575913 4 PAG IX GRANT lp
71 7 245575913 3 PAG IX GRANT lp
71 7 245575913 4 PAG IX GRANT lp
71 7 245575913 6 KEY X GRANT lp
71 7 245575913 3 PAG IX GRANT lp
71 7 245575913 2 KEY X GRANT lp
71 7 229575856 5 KEY X GRANT br
71 7 245575913 3 KEY X GRANT lp
71 7 245575913 4 PAG IX GRANT lp
71 7 245575913 6 KEY X GRANT lp
71 7 229575856 5 KEY X GRANT br
71 7 245575913 6 KEY X GRANT lp
71 7 181575685 1 KEY X GRANT ar
71 7 245575913 6 PAG IX GRANT lp
71 7 245575913 3 PAG IX GRANT lp
71 7 389576426 1 PAG IX GRANT ad
71 7 245575913 3 KEY X GRANT lp
71 7 229575856 2 KEY X GRANT br
71 7 229575856 1 KEY X GRANT br
71 7 181575685 1 PAG IX GRANT ar
71 7 181575685 1 PAG IX GRANT ar
71 7 181575685 1 PAG IX GRANT ar
71 7 181575685 1 KEY X GRANT ar
71 7 245575913 4 PAG IX GRANT lp
71 7 181575685 1 PAG IX GRANT ar
71 7 181575685 1 KEY X GRANT ar
71 7 245575913 3 KEY X GRANT lp
71 7 245575913 1 KEY X GRANT lp
71 7 245575913 4 PAG IX GRANT lp
71 7 229575856 4 KEY X GRANT br
71 7 245575913 4 PAG IX GRANT lp
71 7 229575856 2 PAG IX GRANT br
71 7 229575856 1 KEY X GRANT br
71 7 261575970 0 TAB IX GRANT ml
71 7 229575856 2 KEY X GRANT br
71 7 245575913 6 KEY X GRANT lp
71 7 229575856 5 KEY X GRANT br
71 7 229575856 1 KEY X GRANT br
71 7 245575913 4 PAG IX GRANT lp
71 7 245575913 3 PAG IX GRANT lp
71 7 245575913 1 KEY X GRANT lp
71 7 229575856 2 PAG IX GRANT br
71 7 261575970 0 PAG IX GRANT ml
71 7 261575970 0 PAG IX GRANT ml
71 7 261575970 0 RID X GRANT ml
71 7 261575970 0 PAG IX GRANT ml
71 7 261575970 0 PAG IX GRANT ml
71 7 261575970 0 PAG IX GRANT ml
71 7 181575685 1 PAG IX GRANT ar
71 7 229575856 5 KEY X GRANT br
71 7 229575856 3 KEY X GRANT br
71 7 245575913 5 KEY X GRANT lp
71 7 261575970 0 RID X GRANT ml
71 7 229575856 4 PAG IX GRANT br
71 7 229575856 5 PAG IX GRANT br
71 7 229575856 5 PAG IX GRANT br
71 7 229575856 1 KEY X GRANT br
71 7 245575913 5 KEY X GRANT lp
71 7 229575856 2 KEY X GRANT br
71 7 229575856 1 KEY X GRANT br
71 7 181575685 1 KEY X GRANT ar
71 7 245575913 4 PAG IX GRANT lp
71 7 245575913 5 KEY X GRANT lp
71 7 245575913 3 PAG IX GRANT lp
71 7 181575685 1 KEY X GRANT ar
71 7 245575913 6 KEY X GRANT lp
71 7 229575856 3 PAG IX GRANT br
71 7 229575856 5 KEY X GRANT br
71 7 245575913 6 KEY X GRANT lp
71 7 261575970 0 RID X GRANT ml
71 7 245575913 4 KEY X GRANT lp
71 7 229575856 4 PAG IX GRANT br
71 7 613577224 0 TAB IX GRANT fa
71 7 229575856 4 KEY X GRANT br
71 7 245575913 4 KEY X GRANT lp
71 7 245575913 5 KEY X GRANT lp
71 7 245575913 4 PAG IX GRANT lp
71 7 229575856 3 KEY X GRANT br
71 7 229575856 1 KEY X GRANT br
71 7 229575856 3 KEY X GRANT br
71 7 245575913 5 PAG IX GRANT lp
71 7 245575913 7 PAG IX GRANT lp
71 7 245575913 5 KEY X GRANT lp
71 7 245575913 2 KEY X GRANT lp
71 7 261575970 0 RID X GRANT ml
71 7 229575856 3 KEY X GRANT br
71 7 245575913 7 KEY X GRANT lp
71 7 245575913 0 TAB IX GRANT lp
71 7 229575856 2 KEY X GRANT br
71 7 245575913 7 KEY X GRANT lp
71 7 245575913 8 KEY X GRANT lp
71 7 229575856 3 KEY X GRANT br
71 7 245575913 4 PAG IX GRANT lp
71 7 245575913 9 KEY X GRANT lp
71 7 245575913 4 PAG IX GRANT lp
71 7 245575913 4 KEY X GRANT lp
71 7 245575913 7 KEY X GRANT lp
71 7 245575913 7 KEY X GRANT lp
71 7 245575913 8 KEY X GRANT lp
71 7 389576426 0 TAB IX GRANT ad
71 7 229575856 2 KEY X GRANT br
71 7 245575913 7 KEY X GRANT lp
71 7 245575913 8 KEY X GRANT lp
71 7 261575970 0 RID X GRANT ml
71 7 245575913 9 KEY X GRANT lp
71 7 261575970 0 RID X GRANT ml
71 7 245575913 7 KEY X GRANT lp
71 7 245575913 8 KEY X GRANT lp
71 7 245575913 4 KEY X GRANT lp
71 7 245575913 9 KEY X GRANT lp
71 7 229575856 5 KEY X GRANT br
71 7 245575913 3 PAG IX GRANT lp
71 7 229575856 2 KEY X GRANT br
71 7 229575856 5 KEY X GRANT br
71 7 229575856 0 TAB IX GRANT br
71 7 261575970 0 PAG IX GRANT ml
71 7 261575970 0 RID X GRANT ml
71 7 2121058592 0 TAB IX GRANT zf
71 7 245575913 1 KEY X GRANT lp
71 7 261575970 0 RID X GRANT ml
71 7 229575856 1 KEY X GRANT br
71 7 245575913 1 KEY X GRANT lp
71 7 245575913 2 KEY X GRANT lp
71 7 181575685 0 TAB IX GRANT ar
71 7 2121058592 1 PAG IX GRANT zf
71 7 629577281 1 KEY X GRANT po
71 7 229575856 5 KEY X GRANT br
71 7 245575913 5 PAG IX GRANT lp
71 7 245575913 9 PAG IX GRANT lp
71 7 629577281 0 TAB IX GRANT po
71 7 245575913 3 PAG IX GRANT lp
71 7 245575913 5 KEY X GRANT lp
71 7 229575856 3 PAG IX GRANT br
71 7 229575856 3 KEY X GRANT br
71 7 229575856 4 KEY X GRANT br
71 7 245575913 3 PAG IX GRANT lp
71 7 245575913 4 KEY X GRANT lp
71 7 245575913 4 KEY X GRANT lp
71 7 245575913 2 KEY X GRANT lp
71 7 245575913 3 PAG IX GRANT lp
71 7 245575913 5 KEY X GRANT lp
71 7 229575856 3 KEY X GRANT br
71 7 245575913 3 PAG IX GRANT lp
71 7 245575913 3 KEY X GRANT lp
71 7 229575856 4 KEY X GRANT br
71 7 245575913 9 PAG IX GRANT lp
71 7 245575913 2 KEY X GRANT lp
71 7 245575913 3 PAG IX GRANT lp
71 7 245575913 4 PAG IX GRANT lp
71 7 229575856 4 KEY X GRANT br
71 7 245575913 3 PAG IX GRANT lp
71 7 245575913 4 PAG IX GRANT lp
71 7 245575913 5 KEY X GRANT lp
71 7 245575913 3 KEY X GRANT lp
71 7 229575856 4 KEY X GRANT br
71 7 245575913 3 KEY X GRANT lp
71 7 229575856 2 KEY X GRANT br
71 7 229575856 1 KEY X GRANT br
71 7 181575685 1 KEY X GRANT ar
71 7 245575913 5 KEY X GRANT lp
71 7 245575913 8 PAG IX GRANT lp
71 7 245575913 3 PAG IX GRANT lp
71 7 245575913 6 KEY X GRANT lp
71 7 245575913 4 KEY X GRANT lp
71 7 181575685 1 PAG IX GRANT ar
71 7 245575913 2 PAG IX GRANT lp
71 7 245575913 2 PAG IX GRANT lp
71 7 245575913 7 PAG IX GRANT lp
71 7 245575913 6 KEY X GRANT lp
71 7 245575913 3 KEY X GRANT lp
71 7 613577224 1 PAG IX GRANT fa
71 7 245575913 1 PAG IX GRANT lp
71 7 245575913 3 KEY X GRANT lp
71 7 229575856 2 PAG IX GRANT br
71 7 229575856 2 PAG IX GRANT br
71 7 245575913 8 KEY X GRANT lp
71 7 245575913 7 KEY X GRANT lp
71 7 245575913 9 KEY X GRANT lp
71 7 245575913 4 PAG IX GRANT lp
71 7 245575913 4 KEY X GRANT lp
71 7 245575913 2 KEY X GRANT lp
71 7 245575913 9 KEY X GRANT lp
71 7 245575913 4 PAG IX GRANT lp
71 7 181575685 1 KEY X GRANT ar
71 7 245575913 8 KEY X GRANT lp
71 7 181575685 1 KEY X GRANT ar
71 7 245575913 8 KEY X GRANT lp
71 7 245575913 7 KEY X GRANT lp
71 7 245575913 9 KEY X GRANT lp
71 7 245575913 3 PAG IX GRANT lp
71 7 181575685 1 KEY X GRANT ar
71 7 245575913 1 KEY X GRANT lp
71 7 229575856 4 KEY X GRANT br
71 7 261575970 0 RID X GRANT ml
71 7 245575913 9 KEY X GRANT lp
71 7 245575913 8 KEY X GRANT lp
71 7 245575913 8 KEY X GRANT lp
71 7 245575913 7 KEY X GRANT lp
71 7 613577224 1 KEY X GRANT fa
71 7 261575970 0 RID X GRANT ml
71 7 245575913 9 KEY X GRANT lp
71 7 245575913 3 KEY X GRANT lp
71 7 245575913 8 KEY X GRANT lp
71 7 245575913 7 KEY X GRANT lp
71 7 229575856 2 KEY X GRANT br
71 7 245575913 9 KEY X GRANT lp
71 7 245575913 1 KEY X GRANT lp
71 7 229575856 4 KEY X GRANT br
71 7 229575856 2 KEY X GRANT br
71 7 245575913 1 KEY X GRANT lp
71 7 245575913 3 KEY X GRANT lp
71 7 245575913 3 PAG IX GRANT lp
71 7 229575856 3 PAG IX GRANT br
71 7 229575856 1 KEY X GRANT br
71 7 245575913 2 KEY X GRANT lp
71 7 229575856 5 KEY X GRANT br
71 7 229575856 4 KEY X GRANT br
71 7 245575913 1 KEY X GRANT lp
71 7 181575685 1 KEY X GRANT ar
71 7 245575913 3 PAG IX GRANT lp
71 7 2121058592 1 KEY X GRANT zf
71 7 245575913 8 PAG IX GRANT lp
71 7 245575913 4 KEY X GRANT lp
71 7 229575856 5 KEY X GRANT br
71 7 245575913 6 KEY X GRANT lp
71 7 245575913 4 PAG IX GRANT lp
71 7 629577281 1 PAG IX GRANT po
71 7 245575913 6 KEY X GRANT lp
71 7 245575913 3 PAG IX GRANT lp
71 7 245575913 2 KEY X GRANT lp
71 7 245575913 4 KEY X GRANT lp
71 7 229575856 3 KEY X GRANT br
71 7 229575856 4 KEY X GRANT br
71 7 245575913 1 KEY X GRANT lp
71 7 245575913 2 KEY X GRANT lp
71 7 245575913 6 PAG IX GRANT lp
71 7 229575856 3 KEY X GRANT br
71 7 229575856 3 KEY X GRANT br
71 7 245575913 1 KEY X GRANT lp
71 7 245575913 2 KEY X GRANT lp
71 7 229575856 2 PAG IX GRANT br
71 7 229575856 5 PAG IX GRANT br
71 7 229575856 1 PAG IX GRANT br
71 7 229575856 3 PAG IX GRANT br
71 7 229575856 1 KEY X GRANT br
71 7 181575685 1 PAG IX GRANT ar
71 7 389576426 1 KEY X GRANT ad
71 7 245575913 5 KEY X GRANT lp
71 7 245575913 3 PAG IX GRANT lp
71 7 245575913 3 PAG IX GRANT lp
71 7 229575856 2 KEY X GRANT br
71 7 245575913 9 KEY X GRANT lp
72 5 0 0 DB S GRANT
73 7 0 0 DB S GRANT
75 7 0 0 DB S GRANT
76 7 0 0 DB S GRANT
Workshop : Datenbanken mit ADO.NET
Xamarin Mobile App : Finderwille Einsatz App
Unternehmenssoftware : Quasar-3
Hallo,
ich bin jetzt zwar nicht der MSSQL-Profi, aber auch bei uns kommt es ab und an zu derartigen Deadlocks.
Meine erste Frage wäre nun eigentlich, treten die bei Inserts/Updates/Deletes auf oder beim Lesen? Reine Select-Prozeduren versehen wir, wenn soetwas auftritt meist mit "NOLOCK". Eventuell hilft dir das weiter?
Wissen ist nicht alles. Man muss es auch anwenden können.
PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |
Mit den Daten kann man nicht wirlklich viel anfangen.
Ohne die Info welche ObjektIDs welche Tabellen, Spalten DBs sind, kannst du auch nicht viel anfangen.
Schau dir am besten mal die sys Tabellen an.
Ebenfalls wären dir die DB_ID und Object_ID Funktionen hilfreich.
Ansonsten sind Deadlocks meist ja gleichzeitige Aktionen auf einen Datensatz.
Hier müsstest du schauen ob in deinem Programm z.B. ein Delete mit einem Update/Select aufeinander trift.
Ein NOLOCK Hint sollte man vermeiden, da es das Problem nicht löst sondern versucht zu umgehen.
Davon halte ich ehrlichgesagt nicht viel 😕
Ich denke mal, dass du schauen solltest wo die Deadlocks auftreten und welche Tabellen diese betreffen.
Dann könntest du ggf. schauen wo du auf die entsprechenden Tabellen zugreifst.
Dies sollte dir helfen das Kernproblem zu lösen!
Ebenfalls solltest du dein Programm mit try/catch und logging ausstatten damit du der Problem auf die schliche kommst.
T-Virus
Developer, Developer, Developer, Developer....
99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.
Evtl. mal mit dem SQL Server Profiler versuchen? Konnte man damit nicht die Ursache von Deadlocks ermitteln?
Anbei könntest du auch über den Aktivitätsmonitor von Mangement Studio schauen welche Abfragen laufen, wenn du wieder Dead Locks bekommst.
Ggf. kannst du dann das Problem einfacher finden.
T-Virus
Developer, Developer, Developer, Developer....
99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.
Inflame : Die Sperren treten beim Update auf. Nur Lesen geht, Dirty Reads sind erlaubt.
Ob diese Sperren Deadlocks sind weiß ich nicht. Werden Deadlocks nicht vom SQL Server automatisch aufgelöst ? Gibt es Fälle wo das nicht klappt ?
T-Virus : Den Tabellennamen zeige ich in der Spalte "Name" an.
Dort sieht man die Tabellen die das betrifft. Wo ich auf die Tabellen zugreife weiß ich.
Try Catch und Logging ist eingebaut. Der Fehler der auftritt ist immer "Timeout".
Welche Abfragen laufen weiß ich ja, ich weiß nur nicht wieso die Abfragen nicht ausgeführt werden, sondern auf "GRANT" oder "WAIT" stehen.
Grüße Bernd
Workshop : Datenbanken mit ADO.NET
Xamarin Mobile App : Finderwille Einsatz App
Unternehmenssoftware : Quasar-3
Werden Deadlocks nicht vom SQL Server automatisch aufgelöst ? Du meinst der Server bricht in diesem Fall eine Transaktion ab? Ja das sollte so sein.
* kannst du denn ausmachen was an diesem Kunden anders ist? Andere Konfiguration, anderer Umgang mit der Software?
* du könntest evtl mal schauen ob der Transaktion Isolation level **Snapshot ** hier helfen könnte.
Hi,
also die Ursache an sich ist ohne detailierte Meldung vom SQL Server nur sehr schwer auszumachen. Ich hab allerdings ein paar Tips, wie wir hier an sowas rangehen:
- Mit dem SQL Server Management Studio können auch unerfahrene Nutzer ziemlich viel über grade laufende Transaktionen herausfinden. Stichwort: Aktivitätsmonitor. Dort wird angezeigt, welcher Prozess grade was tut bzw. von wem er z.B. blockiert wird.
- Die ManagementViews, die mit SQL 2005 eingeführt und seitdem in jeder Version ausgebaut wurden sind extrem hilfreich (darauf beruht auch der Aktivitätsmonitor)
(- Last but not Least: Lies Dir mal ein gutes Tutorial durch, welches alles rund um's Locking erklärt. Da gibt's einiges an Zusammenhängen, die man erst mal gerafft haben muss...)
Bart Simpson:
P.S. Um eine im Thread bereits angesprochenes Thema nochmal aufzugreifen: Ja, der SQL Server erkennt Deadlocks normalerweise automatisch und beendent nach einem Timeout einen der beteiligten Prozesse (welcher das ist, entscheidet er nach eigenem Gusto, typischerweise der, bei dem's am wenigsten beim Rollback zu tun gibt). Allerdings kann's natürlich sein, dass Dein .net Client ein Connection-Timeout gesetzt hat, welches früher zuschlägt. Dann bricht dieser ab und das Timeout des Deadlocks kommt nicht zum Zuge...
Praxis ist wenn alles funktioniert und keiner weiss warum.
Theorie ist wenn man alles weiss, aber nichts funktioniert.
Bei uns wird Theorie und Praxis vereint: Nichts funktioniert und keiner weiss warum...
Update (vielleicht gelöst) :
Ich habe eine Routine geschrieben die alle Werte einer Tabelle nacheinander liest (select ...) und Werte ggf. korrigiert (update ...). Bei dieser Routine bekomme ich nur bei einer bestimmten Kunden-Datenbank auch Time Outs.
Es geht rein um sequentielles Lesen und paarmal Ändern. Nur ein User. Keine großen Transaktionen. Wie kann das sein ?
Der Programmteil :
private void EinzelstatistikPruefen()
{
DataCollectionEinzelStatistik esc = new DataCollectionEinzelStatistik();
foreach (DataObjectsEinzelStatistik es in esc.ReadRowsReadOnly("select * from es order by es_nr")) // Hier steckt ein DataReader dahinter
{
DataObjectsArtikel ar = new DataObjectsArtikel(es.arnr);
double umsatz = es.ep * es.menge;
if (es.umsatz != umsatz)
{
sqlstr = "update es set es_umsatz=@es_umsatz where es_nr = @es_nr";
par = db.CreateParameterCollection("@es_nr", es.nr, "@es_umsatz", umsatz);
db.ExecuteSQL(sqlstr, par);
}
}
}
Hinter "ReadRowsReadOnly()" steckt ein einfacher DataReader. ExecuteSQL führt das übergebene SQL-Kommando aus.
Ich habe mit einem Bekannten alle Server-Logs und Transaktion-Logs überprüft und folgendes festgestellt :
Beim Update-Befehl macht der SQL-Server ein ROW-Locking. Werden jetzt in einer PAGE viele Zeilen gelockt ändert das der SQL Server in ein PAGE-Locking, um den Verwaltungsaufwand niedrig zu halten. Beim PAGE-Locking werden aber auch Zeilen gelockt die in meiner Schleife noch nicht gelesen wurden. Der DataReader läuft also auf eine gesperrte Zeile und wartet darauf dass sie freigegeben wird.
Der DataReader in ADO.NET liest immer im Modus "Read Committed", Dirty Reads sind also erstmal nicht möglich.
Folgende Zeile habe ich zwischen Erzeugung der Connection und Ausführung des SQL-Kommandos eingefügt :
conn.BeginTransaction(System.Data.IsolationLevel.ReadUncommitted).Commit();
Der Teil der den SQL-Befehl ausführt sieht nun so aus :
DBConnection conn = CreateConnection(db);
DbCommand cmd = CreateCommand(sqlstr, conn, db.DbProvider, par);
cmd.Connection.Open();
conn.BeginTransaction(System.Data.IsolationLevel.ReadUncommitted).Commit(); // neu
dr = cmd.ExecuteReader(CommandBehavior.CloseConnection);
Jetzt klappt es !!!!!
Zumindestens diese eine Routine läuft jetzt bei mir. Ob damit alles Routinen beim Kunden laufen weiß ich noch nicht.
Grüße Bernd
Workshop : Datenbanken mit ADO.NET
Xamarin Mobile App : Finderwille Einsatz App
Unternehmenssoftware : Quasar-3
Hallo,
Beim PAGE-Locking werden aber auch Zeilen gelockt die in meiner Schleife noch nicht gelesen wurden. Der DataReader läuft also auf eine gesperrte Zeile und wartet darauf dass sie freigegeben wird.
conn.BeginTransaction(System.Data.IsolationLevel.ReadUncommitted).Commit(); // neu
Was ist an der Zeile neu ? Die komplette Zeile oder nur das ".Commit()" ?
Mein Verständnis sagt mir, da wird eine Transaktion gestartet und sofort wieder
beendet. Eigentlich nutzlos.
Was liefert ReadRowsReadOnly für einen Typ zurück ?
( IEnumerable<?> )
Wenn der Lesevorgang komplett abgeschlossen wurde bevor foreach durch die
Objekte iteriert wäre das m.E. nach übersichtlicher. Die Transaktion schließt
dann alle Updates ein oder entfällt komplett. Eine Transaktion für ein einzelnes
Update ist wohl unnötig. In diesem Fall müsste der Lesevorgang auch nicht
vorher abgeschlossen sein.
Leider ist aus der Methode (Auszug? ) nicht zu erkennen wann eine Transaktion
beginnt und wann sie endet.
Hallo Red Baron,
Was ist an der Zeile neu ? Die komplette Zeile oder nur das ".Commit()" ?
Die ganze Zeile ist neu.
Mein Verständnis sagt mir, da wird eine Transaktion gestartet und sofort wieder beendet. Eigentlich nutzlos.
Fast nutzlos. Sie ändert den Isolation Level der aktiven Connection von ReadCommited auf ReadUncommitted, d.h. bei Sperren wird nicht gewartet.
Was liefert ReadRowsReadOnly für einen Typ zurück ?
IEnumerable<DataObjectsEinzelStatistik>. DataObjectsEinzelStatistik ist eine Klasse die eine Tabelle aus der Datenbank darstellt. Man kann also mit foreach alle Zeilen einer Tabelle der Datenbank durchgehen.
Das Ganze ist ein selbstgeschriebener ORM, um schnell und komfortabel auf Datenbanken zuzugreifen.
Beispiel für das Addieren aller Umsätze aller Statistiken :
double umsatz = 0;
DataCollectionEinzelStatistik esc = new DataCollectionEinzelStatistik();
foreach (DataObjectsEinzelStatistik es in esc.ReadRowsReadOnly("select * from es order by es_nr"))
{
umsatz += es.umsatz;
}
Wenn der Lesevorgang komplett abgeschlossen wurde bevor foreach durch die
Objekte iteriert wäre das m.E. nach übersichtlicher.
Das geht nicht da ggf. mehrere Millionen Datensätze geladen werden und wenn man die auf einmal lädt geht das sicher schief. Das ist ja gerade der Vorteil von DataReader und yield, dass man beliebig große Datenmengen damit verarbeiten kann.
Leider ist aus der Methode (Auszug? ) nicht zu erkennen wann eine Transaktion
beginnt und wann sie endet.
Es wurde keine Transaktion benutzt bzw. die Benutzung ist irrelevant.
Grüße Bernd
Workshop : Datenbanken mit ADO.NET
Xamarin Mobile App : Finderwille Einsatz App
Unternehmenssoftware : Quasar-3
Hallo,
ich denke Du wirst nicht der einzige sein der lesend und gleichzeitig
schreibend auf eine Tabelle zugreift. Seltsam auch, es soll nur eine
Installation betreffen was das Problem anbelangt.
Es wurde keine Transaktion benutzt bzw. die Benutzung ist irrelevant.
Wenn tatsächlich keine Transaktion für die Updates benutzt wird, wieso
bleiben dann die Sperren bestehen. Einzelne Befehle werden doch atomar
ausgeführt, nach meinem Verständnis.
db.ExecuteSQL(sqlstr, par); schließt die Verbindung nach jedem Schreibvorgang wieder ?
Sie ändert den Isolation Level der aktiven Connection von ReadCommited auf ReadUncommitted, d.h. bei Sperren wird nicht gewartet.
Das ist naheliegend 😉 okay,
Wenn genau das hilft muss auf der Kundendatenbank ein isolierter Update-Befehl
eine Sperre erzeugen und diese muss bestehen bleiben.
Hast Du schon mal Probiert im Managment Studio eine Zeile der Tabelle zu aktualisieren und anschließend im selben Abfrage Fenster zu lesen ?
Vorher auch das IsolationsLevel so setzen wie Du es per Default von dem
in der App verwendeten Provider erwartest.
Das selbe auf einer Kundeninstallation ausführen wo bisher das Problem noch
nicht aufgetreten ist.
Nicht das es irgendwo eine Einstellung pro Datenbank gibt, die ein solches
Default - Isolation Level setzen läßt !
Hallo Red Baron,
ich denke Du wirst nicht der einzige sein der lesend und gleichzeitig
schreibend auf eine Tabelle zugreift.
Das dachte ich auch.
Seltsam auch, es soll nur eine Installation betreffen was das Problem anbelangt.
Es liegt an der Verteilung der Daten in der Datenbank. Wenn ich in der betroffenen Tabelle jeden Datensatz ändere, dann kann ich mit meiner Routine keinen Time-Out mehr erzeugen. Dann ist die Verteilung der Rows auf die Pages geändert worden.
Wenn tatsächlich keine Transaktion für die Updates benutzt wird, wieso
bleiben dann die Sperren bestehen. Einzelne Befehle werden doch atomar
ausgeführt, nach meinem Verständnis.
Wenn man keine Transaktion angibt dann packt der SQL Server jeden einzelnen Befehl in eine eigene Transaktion.
db.ExecuteSQL(sqlstr, par) schließt die Verbindung nach jedem Schreibvorgang wieder ?
Klar !
Wenn genau das hilft muss auf der Kundendatenbank ein isolierter Update-Befehl
eine Sperre erzeugen und diese muss bestehen bleiben.
Ja, erzeugt eine Sperre, nein, die bleibt nicht bestehen.
Hast Du schon mal Probiert im Managment Studio eine Zeile der Tabelle zu aktualisieren und anschließend im selben Abfrage Fenster zu lesen ?
Vorher auch das IsolationsLevel so setzen wie Du es per Default von dem
in der App verwendeten Provider erwartest.
Das selbe auf einer Kundeninstallation ausführen wo bisher das Problem noch
nicht aufgetreten ist.
Ja, geht alles.
Nicht das es irgendwo eine Einstellung pro Datenbank gibt, die ein solches
Default - Isolation Level setzen läßt !
Das weiß ich nicht, ich setze das aber lieber per C# Kommando.
Der Grund für die Sperre ist ja die Art der Verteilung der Table Rows in einer Page und der Übergang vom Row Lock zum Page Lock genannt "Lock Escalation".
"Beabsichtigte Sperren werden aus zwei Gründen verwendet:
...
Um die Effizienz des Database Engine (Datenbankmodul) beim Erkennen von Sperrkonflikten auf einer höheren Granularitätsebene zu steigern."
Quelle : https://msdn.microsoft.com/de-de/library/jj856598(v=sql.120).aspx
Weitere Infos zu Sperren : http://db-berater.blogspot.de/2014/06/sperrverhalten-von-shared-locks.html
Lock Escalation in SQL Server : https://msdn.microsoft.com/en-us/library/ms184286.aspx
Grüße Bernd
Workshop : Datenbanken mit ADO.NET
Xamarin Mobile App : Finderwille Einsatz App
Unternehmenssoftware : Quasar-3