ms-sql.tsql.queries.crud.html

Insert Into

Mittels Insert Into können einer Tabelle neue Zeilen hinzugefügt werden. Eine Variante ermöglicht das Einfügen einer Zeile:

Insert Into dbo.users ([user], [password]) values('Hugo', 'bo55')

Eine Zweite Variante ermöglicht es, die Daten aus einer zweiten Tabelle zu entnehmen und in der Zieltabelle einzufügen:

  Insert Into dbo.users ([user], [password]) 
select [users], [password] 
from  [shuttle].dms.dbo.users   -- Daten aus der users- Tabelle aus einem Zweiten Server 
                                -- entnehmen

Bestimmen der neuen Id beim Einfügen in eine Tabelle mit Identity- Schlüsselspalte

Für Tabellen, deren Schlüssel automatisch erzeugt werden, ist der Wert des neuen Schlüssels nach dem Einfügen oft von interesse. Dieser kann auf zwei Arten bestimmt werden.

Mit dem Output- Zusatz in einer Insert Anweisung können die eingefügten Daten als Resultset zurückgegeben werden:

  insert into dbo.EventLog (msg)
output  inserted.id
values  ("Eine neue Meldung")

Mit dem zusatz Into in der output- Klausel können die Eingfügten Daten Variablen zugewiesen werden.

  Declare @line Table(id int)
insert into dbo.EventLog (msg)
output  inserted.id into @line
values  ("Eine neue Meldung")
select @id = id from @line

Delete from ...

  -- Alle Zeilen aus der Tabelle data.FileInfos löschen, die xml- Dateien im Dateibaum beschreiben
delete from data.FileInfos where ext = '.xml' 
go

TRUNCATE TABLE

Sollen alle Zeilen einer Tabelle gelöscht werden, dann kann dies mit einer speziellen Form der delete- Anweisung erfolgen:

  -- Alle Zeilen aus der Tabelle data.FileInfos löschen
delete from data.FileInfos
go

Dabei können alle Löschaktionen für jede Zeile im Transaktionsprotokoll protokolliert werden, was die Ausführungszeit und den Resourcenverbrauch auf dem Server erhöht. Ist eine Protokollierung der Löschaktionen pro Zeile nicht erforderlich, dann die Truncate Table- Anweisung eingesetzt werden. Durch sie wird die Ausführungszeit und den Resourcenverbrauch auf dem Server beim löschen aller Zeilen minimiert.

  -- Alle Zeilen aus der Tabelle data.FileInfos löschen ohne Protokollierung
truncate table data.FileInfos
go

Update ...

  use geoinfo
go
update laender set ewz =  3.4 where land like 'Albanien'
go

Tabellensperren

Die Benutzer konkurrieren beim Zugriff auf die Datensätze in den Tabellen einer Datenbank auf einem Datenbankserver. Durch Sperren wird dabei verhindert, dass sich mehrere Datensatzaktualisierungen überlagern und es so zu Datenverlusten und Inkonsistenzen kommt.

Folgende Arten von Sperren gibt es:

Lesesperre	Exklusive Sperre	Aktualisierungssperre	Beabsichtigte Sperre
Hat eine Objekt eine Lesesperre, dann kann diese nur von den Transaktionen ausgelesen werden, die die Lesesperre gesetzt haben. Parallele Lesevorgänge sind möglich, jedoch keine Aktualisierungen und Löschvorgänge.	Ein Objekt mit einer exklusiven Sperre kann nur von der Transaktion bearbeitet werden, die die Sperre gesetzt hat. Alle anderen Transaktionen wird der Zugriff auf das Objekt verwehrt.	Transaktionen, bei denen im ersten Schritt die Datensätze durchsucht (Lesesperre) und im zweiten Schritt die Datensätze geändert werden (Exklusive Sperre), setzten Aktualisierungssperren um Deadlocks zu vermeiden. Diese überspannen den Lese- als auch den Aktualisierungsvorgang.	Zeigen an, das demnächst ein Objekt mit einer Sperre belegt wird.

Es können folgende Objekte gesperrt werden: Tabellenzeile, Seite (8KB), Block (a 8 Seiten) und Tabelle.

Achtung: Eine Tabellenzeile kann sich über mehrere Seiten und Blöcke erstrecken. Umgekehrt kann eine Seite oder ein Block mehrere Zeilen enthalten.

Das Setzten der Sperren erfolgt beim Bearbeiten der konkurrierenden Datenbankzugriffe durch den SQL- Server in der Regel automatisch. Dabei wird die notwendige Sperre mit möglichst optimaler Ausdehnung (Zeile, Seite, Block oder Tabelle) gewählt. Die Ausdehnung wird aus den Statistiken des Ausführungsplanes abgeleitet. In einem Fall könnten Sperren auf Zeilenebene sinnvoll sein (viel Parallelität, aber auch viel Ressourcenverbrauch beim Sperren vieler Zeilen), im anderen Sperren auf Tabellenebene (keine Parallelität, minimalen Ressourcenverbrauch da nur eine Sperre benötigt wird).

Manuelles setzten von Sperren

Sollten bei der Abarbeitung von Transaktionen Deadlocks auftreten, kann mit dem manuellen setzten von Sperren eingegriffen werden. Dies erfolgt durch sogenannte Sperrhinweise hinter den Tabellennamen.

select * from dbo.Artikel (TABLOCKX) –- Sperrhinweis TABLOCKX= exklusive Tabellensperre setzten

Es sind folgende Sperrhinweise möglich:

Sperrhinweis	Details
ROWLOCK	Die Ausdehnung von Sperren wird auf Zeilen eingeschränkt
PAGLOCK	Die Ausdehnung von Sperren wird auf Seiten eingeschränkt
TABLOCK	Die Sperren betreffen immer die gesamte Tabelle.
TABLOCKX	Belegt eine Tabelle mit einer exklusiven Sperre
NOLOCK READUNCOMMITTED	Es werden nie Sperren auf die Tabelle angewendet. Dadurch können Datensätze von einer Transaktion gelesen werden, während eine zweite sie noch bearbeitet (Dirty Reads).
READPAST	Die gesperrten Zeilen von aktualisierenden Transaktionen werden durch die lesende Transaktion übersprungen. Im Resultset fehlen diese dann, was zu Fehlern bei der Auswertung führen kann.
REPEATEBLEREAD	Lesesperren auf einer Tabelle werden erst aufgehoben, wenn die lesende Transaktion beendet wird. Update und Delete ist auf der Tabelle nicht möglich, wohl aber Insert.
HOLDLOCK SERIALIZABLE	Lesesperren werden erst aufgehoben, wenn die anfordernde Transaktion beendet ist. Insert- Operationen auf den geperrten Objekten sind blockiert.