Der Beitrag Videoreihe „MS SQL-Server für blutige Anfänger“ erschien zuerst auf Pixelfriedhof.

Das kann zum Beispiel passieren, wenn ein fehlerhafter Restore-Prozess gestartet wird. So im Falle meines Kunden geschehen. Restore über die MSSQLSMS-GUI gestartet, Medium ausgewählt, LDF und MDF-Datei ausgetauscht, aber das Ziel vergessen. Endeffekt beim SQL-Server 2008: Ziel- und Quelldaten(banken) komplett gesperrt und eine riesige Menge offener Transaktionen, die sich nicht beenden lassen. Es gibt aber noch Hoffnung:

Folgendes Script killt alle Transaktionen zu einer bestimmten Datenbank.

Bitte ‚DB_NAME‘ gegen den tatsächlichen Namen der gesperrten Datenbank austauschen und abfeuern.

USE master

GO

SET NOCOUNT ON

DECLARE @DBName varchar(50)

DECLARE @spidstr varchar(8000)

DECLARE @ConnKilled smallint

SET @ConnKilled=0

SET @spidstr = “

Set @DBName = ‚DB_NAME‘

IF db_id(@DBName) < 4

BEGIN

PRINT‚Connections to system databases cannot be killed‘

RETURN

END

SELECT @spidstr=coalesce(@spidstr,‚,‘ )+‚kill ‚+convert(varchar, spid)+ ‚; ‚

FROM master..sysprocesses WHERE dbid=db_id(@DBName)

IF LEN(@spidstr) > 0

BEGIN

EXEC(@spidstr)

SELECT @ConnKilled = COUNT(1)

FROM master..sysprocesses WHERE dbid=db_id(@DBName)

END

Im Anschluss daran funktioniert ein ggf. vorher nicht erfolgreiches

ALTERDATABASE DB_NAME

SET MULTI_USER;

GO

wieder.

Der Beitrag Alle Connections zu einer SQL-Datenbank trennen erschien zuerst auf Pixelfriedhof.

Der Beitrag SQL-Server: LDF- und MDF-Datei – Unterschied und Zusammenhang erschien zuerst auf Pixelfriedhof.

LDF- und MDF-Datei auf unterschiedliche Laufwerke verteilen

Es ist durchaus sinnvoll, die LDF- und die MDF-Dateien einer Datenbank auf verschiedene Laufwerke zu legen. Am besten auch auf Laufwerke abseits des eigentlichen Systemlaufwerks, unter dem z.B. das Betriebssystem arbeitet.

Jede Festplatte hat nur einen Schreibkopf, bzw. bei SSDs einen Controller. Ist der Schreibkopf, bzw. der Controller zum Beispiel gerade dabei die Logdatei (LDF) permanent fortzuschreiben, so muss er diesen Vorgang zum Auslesen der Datendatei (MDF) unterbrechen. Fortlaufende Logdateiinhalte müssen zwischengespeichert werden und dann bei Wiederaufnahme des Vorgangs auf die Platte gebracht werden. Das verzögert den ganzen Prozess ungemein und stellt gerade bei der Verwaltung von großen Datenmengen (meiner Definition nach MDF-Dateien > 20GB) ein ernsthaftes Problem dar. Gleiches gilt allerdings auch, wenn mehrere MDF- oder LDF-Dateien unterschiedlicher Datenbanken auf ein und demselben physischen Laufwerk liegen.

Zudem ist das Verteilen der Daten im Falle eines Laufwerkschadens wesentlich sicherer. Ist die MDF-Datei beschädigt oder verloren, gibt es noch die LDF-Datei und umgekehrt.

Sie sollten die Datenbankdateien, egal ob MDF- oder LDF-Dateien, aus o.G. Gründen nach Möglichkeit auch auf einem anderen Laufwerk lagern, als das Serverbetriebssystem.

Der SQL-Server gehört nicht auf einen Domaincontroller

Auf der einen Seite geht es hier um Performance. Unglücklicher als Active Directory (AD)  und SQL-Server kann man keine zwei Rollen und Dienste auf einem Windows-Server zusammenlegen. Beide Systeme ziehen Leistung und blockieren sich unter leicht zu erreichenden Bedingungen gegenseitig. Sie haben dann nicht nur ein Performanceproblem mit dem SQL-Server, sondern auch mit den AD-Funktionen. Wenn auch nicht sofort, aber irgendwann recht sich diese leichtsinnige Entscheidung: Entweder im laufenden Betrieb oder zu einem späteren Zeitpunkt, wenn Sie versuchen Einstellungen des SQL-Servers oder des ADs zu erweitern oder zu verändern.

In den neuesten Versionen des SQL-Servers bricht Microsoft die Installation des SQL-Servers ab, wenn es sich um einen Domaincontroller handelt. Sind Sie findig genug um diesen Mechanismus auszutricksen, nehmen Sie damit ernsthafte Probleme in Kauf.

Sie wollen, dass ich konkret werde? Die Funktion des schreibgeschützten ADs können Sie im Falle des gemeinsamen Hosts schon mal knicken. Genauso Fail-Over und Clustering beim SQL-Server. Sicherheitstechnisch ist der Betrieb eines SQL-Servers in unmittelbarer Nähe des Active Directory auch nicht schlau.

Außerdem gilt ganz besonders hier: Niemals alle Eier in einen Korb. Gerade weil es sich hier um die wirklich wichtigen Eier handelt. Die Haupt-Eier.

Tun Sie sich selbst einen Gefallen: Machen Sie das nicht.

Der SQL-Server gehört nicht auf einen Server mit Terminaldiensten oder Citrix-Terminaldiensten

Terminalservices oder Citrix-Terminaldienste sind Ressourcenfresser. Je nach gehosteter Anwendung kommen hier große Belastungen für CPU, Netzwerkhardware und Arbeitsspeicher zusammen. Sicherlich lassen sich große Teile dieser Problematiken mit der Aufstockung der Hardwarespezifikationen lösen, doch irgendwann ist auch an dieser Front Schluss mit Optimierungen. Tun Sie sich selbst einen Gefallen: Machen Sie das nicht.

Keinen Bildschirmschoner und keinen Energiesparplan

Man sollte meinen dieser Punkt wäre selbstverständlich. Nein, ist er anscheinend nicht. Fakt ist: Auf einem performanten SQL-Server-System haben diese Features nichts zu suchen. Gut gemeint, aber leider alles andere als hilfreich.

Der VM-Netzwerk-Overkill

Auch hier sollte man meinen, dass es sowas gar nicht gibt. Aber glauben Sie mir: Sowas gibt es im Produktiveinsatz.

Folgendes Szenario ist nicht sinnvoll: Ein physischer VM-Host beherbergt Domain Controller, Fileserver, Applikationsserver und natürlich SQL-Server als einzelne VMs. Ein anderer physischer Server im Netzwerk ist für das zeitgesteuerte Backup verantwortlich. Alle VMs des VM-Hosts laufen über eine Netzwerkkarte. Das funktioniert genau solange, bis das Backup anläuft. Die Netzwerkkarte glüht, laufende Applikationen geben den SQL-Server-Durchsatzraten den Rest.
Wenn Sie sich mit Ihrer Virtualisierungsumgebung auskennen, analysieren Sie solche Flaschenhälse und beheben Sie sie durch die Zuordnung von Prioritäten oder neuer Netzwerkhardware.

Netzwerkflaschenhälse lassen sich recht einfach analysieren, teilweise auch an den nachgeschalteten Switches, sollte es an Kenntnissen der VM-Verwaltung mangeln. Meistens hilft aber schon ein analytischer Denkansatz um solchen Problemen auf die Schliche zu kommen.

Der Beitrag Grundlegende SQL-Server-Performance sicherstellen erschien zuerst auf Pixelfriedhof.