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.

Wichtig hierbei ist lediglich zu beachten, dass der durchführende Datenbankbenutzer das Recht für „Bulk-Operations“ hat.

Keine Produkte gefunden.

CREATE TABLE TEMP (

  [personalnr] varchar(15),

  [Emailadresse] varchar(200),

  [Ort] varchar(40)

— Hier erstellen wir eine Temporäre Tabelle um die Daten der CSV-Datei erstmals anzunehmen und zwischenzulagern.

— Die Reihenfolge der Spaltennamen muss auch in der CSV-Datei eingehalten werden.

)

GO

BULK INSERT TEMP— Temporäre Tabelle mit CSV-Daten füllen

FROM ‚J:\WORK\import\mail.csv‘— Dies ist der Pfad zu der Datei die importiert wird. WICHTIG: Der Pfad bezieht sich auf den Pfad im Server, nicht auf den Rechner auf dem das Managementstudio ausgeführt wird.

WITH

 (

    FIELDTERMINATOR=‚,‘,    — Darauf achten, dass die CSV-Datei wirklich die Spalten mit Komma und nicht mit Semikolon separiert

    rowterminator=‚\n‘     –\n ist in den meisten Fällen korrekt, zumindest wenn die Datei aus einer deutschen Excel-Version als CSV erstellt wurde und ggf. nochmal mit dem Editor nachbearbeitet wurde.

  )    

GO

UPDATE mitarbeiter— Inhalte der temporären Tabelle werden in die Produktivtabelle übernommen. Als Zuordnungsmerkmal fungiert die Personalnummer, welche wir in der temporären Tabelle „joinen“.

SET Emailadresse=temp.Emailadresse,Ort=temp.Ort

FROM mitarbeiter

INNERJOIN temp

ON mitarbeiter.personalnr=temp.personalnr

GO

DROP TABLE TEMP  — Nach Abschluss aller vorherigen Vorgänge können wir die temporäre Tabelle löschen.

GO

All the links in this text are Amazon Affiliate Links, and by clicking on an affiliate link I will earn a percentage of your subsequent Amazon purchases. However, this circumstance does not influence the background of my product recommendation. This product recommendation is independent, honest and sincere.

Bei allen genannten Links handelt es sich um Amazon-Affiliate-Links. Durch einen Klick auf einen Affiliate-Link werde ich prozentual an Euren darauf folgenden Amazon-Einkäufen beteiligt. Dieser Umstand beeinflusst aber nicht die Hintergründe meiner Produktempfehlung. Diese Produktempfehlung erfolgt unabhängig, ehrlich und aufrichtig.

Der Beitrag Inhalte einer CSV-Datei per SQL in bestehende Tabelle importieren (Bulk Operation) erschien zuerst auf Pixelfriedhof.

Zuerst packen wir alle als Liste angelieferten Werte, in diesem vereinfachten Fall Personalnummern, untereinander in die Spalte.

In einer benachbarten Spalte fügen wir nun die Funktion „Verketten“ zur Erstellung einer Zeichenfolge ein:

=VERKETTEN(„INSERT INTO personal VALUES(„;A3;„,Wert1,Wert2,’01.01.2015′,Porta Westfalica, NULL)„)

Dabei wird der rot geschriebene Text statisch übernommen und der blaue Baustein referenziert automatisch immer die vorstehende Spalte mit der Personalnummer.

Das Ergebnis sieht dann so aus und kann als Text-Kopie direkt ins SQL-Managementstudio importiert werden:

Der Beitrag SQL-Statements mit Excel erstellen (Quick and Dirty) 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.