SQL Server spezifische Einstellungen

Probleme mit Deadlocks

In seltenen Fälle kann es zu Fehler mit Datenbank Deadlocks kommen.

Vorab: Diese sind nicht zu 100% vermeidbar und vom Prinzip her auch nicht kritisch.

Wir konnten dieses Verhalten bei cardo Anwendungen die unsere Workflow System PiB verwenden beobachten.

Interessanterweise trat dies bei PostgreSQL als Datenspeicher bisher noch nicht auf, obwohl die Transaktionslevel identisch sind (die Deadlock Erkennung ist nicht SQL Server spezifisch).

Relevant ist hierbei die Einstellung READ_COMMITTED_SNAPSHOT auf SQL Server, der Standardwert hier ist 0 (also deaktiviert) bei lokalen Installationen.

Wir empfehlen das Aktivieren dieser Einstellung, das Verhalten entspricht dann weitgehend dem, wie es auch in PostgreSQL ist.

Für eine einzelne Datenbank :

ALTER DATABASE NameDerDatenBank SET READ_COMMITTED_SNAPSHOT ON

Für eine Menge von Datenbanken nehmen Sie folgendes Script und passen Sie 'NameDerDatenBanken' an.


DECLARE @myValue nvarchar(45);
DECLARE @stmt nvarchar(200);
DECLARE myCursor CURSOR FOR
	select name from sys.databases where name like '%NameDerDatenBanken%' and is_read_committed_snapshot_on <> 1;
OPEN myCursor;
FETCH NEXT FROM myCursor INTO @myValue;
While (@@FETCH_STATUS = 0)
BEGIN
	set @stmt = 'ALTER DATABASE ['+@myValue+'] SET READ_ONLY WITH ROLLBACK IMMEDIATE';
    PRINT @stmt;
	exec(@stmt);

	set @stmt = 'ALTER DATABASE ['+@myValue+'] SET READ_COMMITTED_SNAPSHOT ON';
    PRINT @stmt;
	exec(@stmt);

	set @stmt = 'ALTER DATABASE ['+@myValue+'] SET READ_WRITE WITH ROLLBACK IMMEDIATE';
    PRINT @stmt;
	exec(@stmt);

    FETCH NEXT FROM myCursor INTO @myValue;
END
CLOSE myCursor;     
DEALLOCATE myCursor;


Zuletzt geändert: 01.11.2024 09:52:42 (erstmals erstellt 01.11.2024) // Alias: "msSqlEinstellungen"