Hallo Patrick, Transaktionen dienen bei einer relationalen Datenbank dem Zweck, die Datenkonsistenz der zu ver�ndernden Daten sicherzustellen. Grunds�tzlich ist hier jede Anweisung, welche in irgendeiner Form Daten in der Datenbank ver�ndert eine solche Transaktion. So wird zum Beispiel sichergestellt, dass der Abbruch einer DML Anweisung nicht die zugrundliegenden Daten zerst�rt, sondern dass in diesem Fall ein sogenannter Rollback stattfindet, welcher die betroffenen Daten in den urspr�nglichen (konsistenten) Zustand vor der Anweisung zur�cksetzt. Dies gilt sowohl f�r Einzelanweisungen, als auch f�r eine Reihe aufeinanderfolgender, voneinander abh�ngiger Anweisungen.
Ist der Parameter 'IMPLICIT_TRANSACTIONS' auf 'OFF' gesetzt (Default), f�hrt SQL Server nach jeder erfolgreichen Anweisung ein COMMIT, also eine Best�tigung durch und die Datenver�nderung ist g�ltig. Ist dieser Parameter hingegen auf 'ON' gesetzt, muss dies von Hand mittels 'COMMIT TRANSACTION' zur Best�tigung oder 'ROLLBACK TRANSACTION', um die Anweisung r�ckg�ngig zu machen, erfolgen. Unabh�ngig davon kann man eine Transaktion auch von Hand durch die Anweisung 'BEGIN TRANSACTION' einleiten. Ein kleines Beispiel zu Transaktionen: Zwei Personen heben gleichzeitig bei verschiedenen Nierderlassungen einer einen gewissen Betrag von einen Konto ab. Dazu wird zun�chst der Kontostand �berpr�ft und, falls genug Geld vorhanden ist, der Betrag abgebucht. In diesem Fall muss sichergestellt sein, dass, w�hrend A seinen Kontostand abruft und den Betrag abbucht, B solange warten muss, bis die Abbuchung von A erfolgt ist, damit zum einen auch wirklich BEIDE Betr�ge abgebucht werden und zum anderen f�r beide der richtige Kontostand ausgegeben wird. Von elementarer Wichtigkeit bei der Transaktionsverwaltung sind Sperren. Diese dienen vorrangig dazu, dass die Daten, die man gerade sichtet oder ver�ndert vor Zugriffen anderer User f�r die Dauer der Transaktion gesch�tzt werden. Sperren k�nnen auf nahezu alle denkbaren Datenbankobjekte gelegt werden. Hierzu z�hlen die Datenbank als solche, Tabellen, Tabellenschemata, Indizes, Seiten, Zeilen usw. Zudem gibt es verschiedene Arten von Sperren, welche je nach Bedarf gesetzt werden. Die wichtigsten sind: - Shared (S) Locks (Gemeinsame Sperres) werden bei Lesezugriffen gesetzt und unterbinden eine Ver�nderung der Daten, w�hrend sich das Objekt im Zugriff befindet. Gleichzeitige Lesezugriffe sind m�glich. - Exclusive (X) Locks (Exklusive Sperren) werden bei der Ver�nderung von Daten gesetzt und verhindern weitere Schreibzugriffe und, in abh�ngigkeit von der Isolationsstufe, auch Lesezugriffe. Dann gibt es noch sogenannte Intent-Locks, also beabsichtigte Sperren. Diese treten dann auf, wenn eine Schreiboperation auf ein Objekt anliegt, welches gerade mit einer Gemeinsamen Sperre belegt ist. Das in aller K�rze zum Thema Transaktionen und Sperren. Wesentlich mehr und detaillierte Informationen findest Du in der SQL Server Hilfe zu 'sp_locks' und 'syslockinfo'. Zur Frage, wann es kritisch wird: �bel wird es immer dann, wenn Tabellensperren �ber einen l�ngeren Zeitraum gehalten werden. Unabh�ngig vom Sperrtyp ist definitiv kein Schreibzugriff und bei exklusiven Sperren in der Regel auch kein Lesezugriff mehr m�glich. bis die Sperre entfernt wurde. Ich hoffe, dass ich Dir mit diesem Miniaturcrashkurs in Sachen Sperren und Transaktionen habe helfen k�nnen. Gru� Michael > -----Urspr�ngliche Nachricht----- > Von: Patrick-M. Engel [mailto:engel@;united-online.com] > Gesendet: Freitag, 18. Oktober 2002 12:42 > An: ASP Datenbankprogrammierung > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Betreff: [aspdedatabase] AW: Re: AW: Probleme mit SQL2000-Server > > > Hallo Jutta und Michel, > > vielen Dank f�r Eure R�ckmeldungen. Ich hoffe mal sehr, dass es > daran liegt. > > Ja, es greifen recht viele User gleichzeitig auf die Datenbank zu - und es > scheint so, als w�rden nicht alle Tabellen aufh�ngen. Manche Abfragen > klappen n�mlich (das sind ganz einfache Abfragen). W�hrend andere sich > irgendwann aufh�ngen. > > > Eine weitere M�glichkeit, die ich noch sehe, sind offen gebliebene > > Transaktionen (z.b. vergessenen COMMITS) > > Mmmh, "COMMITS" kenne ich gar nicht ;-) Wird daher auch nicht in den SPs > verwendet. Das kann es also nicht sein. > > > Das kann auch passieren, wenn der Parameter 'IMPLICIT_TRANSACTIONS' auf > 'ON' steht > > Den Parameter habe ich auch nirgends verwendet. > > > Sperreninformationen kannst Du im Query-Analyzer mit der > > Prozedur 'sp_lock' ausgeben lassen. > > Das habe ich mal ausprobiert (allerdings habe ich den SQL vor ca. 1 Stunde > restartet). Im "Raster" werden mir einige Werte angezeigt. Aber da blicke > ich jetzt nicht durch. Was sagt mir das? Bzw. bei was sollte ich alarmiert > sein? > > Viele Gr��e, > Patrick > | [aspdedatabase] als [email protected] subscribed | http://www.aspgerman.com/archiv/aspdedatabase/ = Listenarchiv | Sie k�nnen sich unter folgender URL an- und abmelden: | http://www.aspgerman.com/aspgerman/listen/anmelden/aspdedatabase.asp
