SQL – Fragen und AntwortenAnmeldungstrigger, Datendateidefragmentierungen und mehr

Herausgegeben von Nancy Michell

Einstellen des Dienstkontos

Tipp: Sicherere Kennwörter

Durch das SQL Server 2000-Modul werden zwei Kopien jedes SQL Server-Anmeldekennworts verwaltet. Eine Version ist das eigentliche Kennwort, das vom Benutzer bereitgestellt wird, die andere ist das Kennwort in Großbuchstaben.

Diese Vorgehensweise unterstützt Kennwortprüfung ohne Beachtung der Groß-/Kleinschreibung, da ein Benutzer sich sowohl mit einem Kennwort mit Groß- und Kleinschreibung also auch mit einem Kennwort nur in Großschreibung anmelden und Zugriff auf den Server erhalten kann. Diese Methode ist zwar bequem, hat jedoch einen Haken. Das Speichern von Kennwörtern in Großschreibung erleichtert Brute-Force-Angriffe zum Erraten von Kennwörtern durch Verringerung der Anzahl möglicher Kennwörter.

In SQL Server 2005 wird nur die Originalkopie des Kennworts gespeichert. Ein von einem Benutzer eingegebenes Kennwort muss mit dem auf dem Server abgelegten Kennwort übereinstimmen. Wenn das Kennwort nicht übereinstimmt, schlägt die Anmeldung fehl, und dem Benutzer wird der Zugriff verweigert. Wenn die präzise Groß- oder Kleinschreibung der Kennwortzeichen vergessen wurde, muss das Kennwort zurückgesetzt werden.

Angenommen der Anmeldename eines Benutzers lautet SQLCOMMUNITY. Das SQL Server-Kennwort des Benutzers kann mit dem folgenden Befehl zurückgesetzt werden:

Use Master;
ALTER LOGIN SQLCOMMUNITY WITH PASSWORD = 'k3t9h4s8wJF7t';

Durch diesen Befehl wird das Kennwort für die SQLCOMMUNITY SQL Server-Anmeldung auf „k3t9h4s8wJF7t“ zurückgesetzt.

F: In SQL Server™ 2000 habe ich das Dienstkonto für das SQL Server-Modul und den -Agent in der Regel mit dem Applet „Dienste“ in „Verwaltung“ festgelegt. Jetzt habe ich gehört, dass in SQL Server 2005 das Configuration Manager-Tool verwendet werden soll. Weshalb kann ich nicht einfach die Windows-Tools weiterverwenden?

A: SQL Server 2005 bietet mehr Sicherheit als vorherige Versionen. In vielen Unternehmen legen Benutzer nur interne Konten wie „LocalSystem“ fest, um SQL Server auszuführen. Diese Konten verfügen jedoch häufig über mehr oder weniger Rechte und Berechtigungen unter Windows® als sie benötigen. Sie sollten ein Windows-Konto ohne erweiterte Berechtigungen einrichten, um die Dienste SQL Server 2005-Modul und -Agent auszuführen. Wenn Sie diese Konten mit Configuration Manager auswählen, werden ihnen automatisch die entsprechenden Rechte und Berechtigungen sowohl für SQL Server als auch das Betriebssystem gewährt. Wenn Sie die Windows-Tools für die Verwaltung der SQL Server-Dienste verwenden, gewähren Sie möglicherweise nicht die richtigen bzw. zu viele Rechte.

Weitere Informationen finden Sie im Tipp zum Ändern des Dienstkontos.

Wer meldet sich bei meinem Server an?

F: Ich möchte wissen, wer sich wann bei meinem Server anmeldet. Außerdem möchte ich bestimmte Benutzer auf bestimmte Zeiträume einschränken und die Benutzeraktivität nachverfolgen. Ist dies möglich?

A: Ja, all dies ist mit SQL Server 2005 möglich, wenn Service Pack 2 installiert ist.

Mit SQL Server 2005 können Sie Anmeldungstrigger erstellen, die eine T-SQL- oder gespeicherte Prozedur als Reaktion auf ein LOGON-Ereignis auslösen. Sie können einen Anmeldungstrigger verwenden, um Benutzer durch Verfolgen von Anmeldeaktivitäten zu überwachen und zu kontrollieren, um Anmeldungen auf SQL Server zu beschränken, oder die Anzahl an Sitzungen für bestimmte Anmeldungen einzuschränken. Beachten Sie, dass das Ereignis nur nach erfolgreicher Authentifizierung einer Anmeldung ausgelöst wird, jedoch kurz bevor die Sitzung tatsächlich eingerichtet ist. Deshalb werden alle Nachrichten, die von innerhalb des Triggers (z. B. Nachrichten oder Fehler) von der PRINT-Anweisung herrühren, an das SQL Server-Fehlerprotokoll gesendet. Wenn die Authentifizierung für eine Anmeldung fehlschlägt, werden die Anmeldungstrigger nicht ausgelöst.

Das folgende Beispiel zeigt, wie Sie einen Anmeldungstrigger erstellen und eine Meldung an das SQL Server-Fehlerprotokoll senden können, sobald sich ein beliebiger Benutzer angemeldet hat:

ALTER TRIGGER Ops_Login
ON ALL SERVER
AFTER LOGIN
AS
PRINT SUSER_SNAME() + ' has just logged in to ' + LTRIM(@@ServerName) + ' SQL Server at '+LTRIM(getdate())
GO

Um alle auf Serverebene eingerichteten Trigger anzuzeigen, verwenden Sie die folgende Abfrage:

SELECT * FROM sys.server_triggers;

Best Practices für die Defragmentierung

F: Wie lässt sich eine Datendateifragmentierung in SQL Server am besten beheben? Bei Verwendung der Defragmentierungstools in Windows wird die SQL-Datendatei als ein Ganzes behandelt und nicht fein defragmentiert.

A: Sie könnten eine Sicherungskopie der Datenbank erstellen und sie anschließend wiederherstellen. Wenn Platz für eine zusammenhängende Datei vorhanden ist, sollte die Datenbank zusammenhängend geschrieben werden. Die Ausfallzeit für einen Defragmentierungsversuch der physischen Dateien lohnt sich jedoch in der Regel nicht. Normalerweise ist ohnehin nicht viel externe Fragmentierung vorhanden. Es ist hilfreicher, Daten regelmäßig neu zu indizieren, um die interne Defragmentierung so weit wie möglich zu verringern. Dies maximiert die Effizienz von Read-Ahead-Lesevorgängen sowie die Datenmenge, die gepuffert werden kann.

Die wichtigsten Faktoren für effiziente Datenträger-E/A sind folgende: eine Gewährleistung, dass die Datenträgerausrichtung und RAID-Konfiguration korrekt sind, die Skalierung von Festplattenarrays für eine ordnungsgemäße Verarbeitung der E/A-Belastung und die Verwaltung des korrekten Layouts der Protokoll-, Daten-, TempDB- und Sicherungsdateien. Wenn Sie die automatische Vergrößerung/Verkleinerung als primäre Methode für die Größenanpassung von Datendateien vermeiden, verringern Sie die Anzahl der auf Volumeebene erstellten Dateifragmente. Die Durchführung von beispielsweise 10 automatischen Vergrößerungen von jeweils 500 MB hätte wahrscheinlich das Hinzufügen von 10 neuen physischen Dateifragmenten zur Folge. Im Gegensatz dazu wird durch eine einzelne manuelle Vergrößerung von 5 GB nur ein Fragment hinzugefügt.

Tipp: Ändern des Dienstkontos

Wussten Sie, dass wenn das Anmeldekonto des SQL Server-Diensts mit einem Windows NT®-Konto konfiguriert ist, in SQL Server Windows-Benutzerrechte und -Berechtigungen für mehrere Dateien, Ordner und Registrierungsschlüssel festgelegt werden? Sie können auch das SQL Server-Dienstkonto von der Dienstekonsole in der Verwaltung festlegen. Wenn Sie dies jedoch über die Dienste ausführen, werden die Rechte und Berechtigungen nicht festgelegt, und es können ernsthafte Probleme durch fehlende korrekte Sicherheitseinstellungen und die oben genannten SQL Server- und Windows-Elemente auftreten.

Daher wird dringend empfohlen, SQL Server Configuration Manager zu verwenden und nicht die Dienstekonsole, wenn Sie das SQL Server- oder das SQL Server Agent-Dienstkonto ändern. Wenn Sie jedoch bereits Änderungen am Konto mithilfe der Dienstekonsole vorgenommen haben, können Sie dieses Problem nach wie vor beheben.

Schritt 1: Wenden Sie vollständige Berechtigungen für den folgenden Registrierungsschlüssel und dessen Unterschlüssel an:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\90
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\<MSSQL.x>

Schritt 2: Richten Sie uneingeschränkten Zugriff für das Startkonto für den MSSQLServer-Dienst und den SQLServerAgent-Dienst (entweder ein lokales Windows NT-Konto oder ein Domänen-Windows NT-Konto) auf diesem NTFS-Ordner ein:

Drive:\Program Files\Microsoft SQL Server\<MSSQL.1>\MSSQL

Es wird empfohlen, dies nicht manuell vorzunehmen, sondern SQL Server Configuration Manager für Änderungen an SQL Server/Agent-Dienstkonten zu verwenden.

Unser Dank gilt den folgenden Microsoft-IT-Experten für ihre fachliche Unterstützung: Cary Gottesman, Saleem Hakani, Trayce Jordan, Peter Kalbach, Al Noel, Uttam Parui, Amber Sitko und Buck Woody.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.