Die Einfachheit kann nur eine Erscheinung sein. Microsoft SQL Server ist eine relationale Datenbank-Engine, die es ermöglicht, Ihre erste Datenbank direkt nach der Installation zu erstellen. Diese scheinbare Einfachheit des Produkts, ein paar Mausklicks, lässt Sie glauben, dass Ihre Installation korrekt und fehlerfrei ist… In Wirklichkeit sieht es ganz anders aus.
Die Erscheinungen sind trügerisch
Leider sind die Erscheinungen trügerisch. Eine Installation erfordert die Berücksichtigung von Best Practices in Abhängigkeit von Faktoren wie:
- Ihren aktuellen und zukünftigen Bedürfnissen
- Ihrer physischen oder virtuellen Konfiguration
- Ihrem Speichertyp
- Ihrer Netzwerkkonfiguration
Dieser Ansatz garantiert Ihnen Nachhaltigkeit und ist weniger kostspielig als eine vollständige Neuorganisation, die in den meisten Fällen einen Produktionsstopp erfordert.
Sicherheit
Eine MS SQL Server-Installation beginnt mit den Grundlagen, die durch das Betriebssystem Windows repräsentiert werden. Wenn möglich, wird der Server Teil eines Active Directory-Verzeichnisses sein, in dem ein dediziertes Dienstkonto für MS SQL erstellt wird, um die Sicherheit besser zu verwalten. Warum nicht die Sicherheit an den Systemadministrator delegieren, indem Sie AD-Gruppen innerhalb Ihrer SQL-Instanz verwenden?
Die Wahl der Edition: eine ihrer Konsequenzen
Die Wahl zwischen der Standard- und Enterprise-Edition ist wichtig. Es macht keinen Sinn, eine einzelne SQL Standard-Instanz auf einem Server mit 32 Kernen zu installieren, da nur 4 davon aufgrund der Begrenzung durch die Standard-Edition verwendet werden.
Wahl der Ressourcen für Festplatten
Während der Installation sind die Festplattenressourcen sowohl für die Sicherheit Ihrer Datenbanken als auch für die Leistung wichtig.
Für die Sicherheit:
- Auf Laufwerk C: reserviert für das Betriebssystem und die gemeinsam genutzten Programme von MS SQL
- Auf Laufwerk D: SQL-Engine + Systemdatenbanken master, model, tempdb, msdb, distribution
- Auf Laufwerk E: Benutzerdatenbanken, .mdf- und .ndf-Dateien
- Auf Laufwerk F: Transaktionsprotokolle, .ldf-Datei und die tempdb-Datenbank
- Auf Laufwerk G: lokale Sicherungen
Dies ist ein typisches Beispiel. Man kann es noch verbessern, indem man eine Ressource für Indizes und andere zum Speichern von Partitionen hinzufügt. Aber wie bereits erwähnt, muss dies organisiert werden.
Für die Leistung:
- Es ist wichtig, Dateigruppen für die Daten zu verwenden, andere für die Indizes, die Partitionen, bestehend aus mehreren sekundären Dateien, die nicht größer als 32 GB sind. Auf diese Weise schreibt die Engine die Informationen in Streifen.
- Für große Datenbanken ist es möglich, eine Datenbank nach Dateigruppen zu sichern, anstatt die gesamte Datenbank zu sichern.
- Achten Sie auf Informationen im Internet über die Möglichkeit, eine Datenbank mit einer einzigen .mdf-Datei von 800 GB oder mehr als 1 TB zu erstellen. Ja, das ist möglich, aber man sollte vernünftig bleiben, besonders wenn man Tabellen, Ansichten, Indizes, Systemobjekte usw. in einer einzigen Datei mischt!
Dichtigkeit
Wenn Ihre Instanz erstellt ist, gibt es wichtige Nachinstallationsaktionen, um sie "dicht" zu machen. Die Entwickler, die die Konfiguration der Server ihrer Kunden nicht kennen, werden sich auf die Systemdatenbank model stützen, um ihre eigenen zu erstellen. Wenn diese model-Datenbank nicht gemäß Ihren Anforderungen konfiguriert ist, wird das Ergebnis nicht wie erwartet sein. Viele Kunden verwenden nur die beiden Hauptdateien, die eine minimale Datenbank bilden: die .mdf-Datei und die .ldf-Datei. Es ist wichtig zu wissen, dass die Master Data File (mdf) die Systeminformationen ihrer eigenen Datenbank enthält, wie Objekte (Tabellen, Ansichten, Indizes usw.), Benutzer und ihre zugehörigen Rechte. Das Erstellen eigener Objekte in dieser Datei ist dasselbe, als würde man Tabellen direkt in der Systemdatenbank master der Instanz erstellen. Es wird empfohlen, Dateigruppen für Benutzerobjekte zu erstellen.
Art der Nutzung der Datenbank
Je nach Nutzung der Instanz im OLTP-Modus (kurze Transaktionen wie insert, update, delete, merge, select usw.) oder OLAP-Modus für das Entscheidungswesen werden die Parameter unterschiedlich sein und müssen gemäß Ihren Anforderungen angepasst werden.
Backup und Wiederherstellung
Es gibt zwei Hauptmethoden zur Wiederherstellung einer Datenbank:
- Der SIMPLE-Modus, der die Wiederherstellung von Daten nur ab der letzten Sicherung garantiert. In diesem Fall erlauben Sie den Verlust von Daten, die seit der letzten Sicherung eingegeben wurden, im Falle eines Absturzes.
- Der FULL-Modus, der die vollständige Wiederherstellung der Datenbank im Falle eines Absturzes garantiert.
Je nach Wiederherstellungsmodus werden die Sicherungsverfahren unterschiedlich sein. Viele denken, dass das Full-Backup eine Sicherung der Datenbank sowie des Transaktionsprotokolls durchführt, was falsch ist. Es sichert nur die Datenbank, das heißt den Inhalt der .mdf- und .ndf-Dateien. Aus diesem Grund findet man häufig ein Log von 1 GB für eine Datenbank von 300 MB. Um die Informationen im Falle eines Absturzes zu erhalten, können die Transaktionen in der .ldf-Datei nur nach einem BACKUP LOG und nicht nach einem BACKUP DATABASE gelöscht werden. Wenn Sie in den Sicherungsverfahren den Wechsel vom FULL- zum SIMPLE-Wiederherstellungsmodus finden, um ihn zu leeren, und dann wieder von SIMPLE zu FULL, um die Datenbank erneut zu sichern, hat die Person das Prinzip nicht verstanden und riskiert den Verlust von Daten im Falle eines Absturzes!
Disaster Recovery
Für Disaster Recovery-Lösungen verdienen die Sicherungsverfahren noch mehr Aufmerksamkeit. Zum Beispiel sollte man sich nicht darauf beschränken, die Sicherungsverfahren nur auf dem aktiven Server eines SQL-Spiegels zu implementieren. Im Falle eines Failovers zum Backup-Server werden diese Sicherungsverfahren auf diesem Server nicht vorhanden sein. Wenn diese Sicherungsverfahren jedoch auf beiden Servern vorhanden sind, denken Sie daran, sie so zu konfigurieren, dass sie keine Warnungen vom passiven Server aufgrund des Status der Datenbanken auf diesem Server generieren: im RECOVERY-Modus und daher nicht zugänglich.
Best Practices
Es ist nie zu spät, um auf die "Best Practices" zurückzukehren. Oft haben diese den Austausch der Hardwarekonfiguration vermieden, was die Leistungsprobleme nur in die Zukunft verschoben hätte, anstatt sie zu beheben. DEEP verfügt über umfangreiche Erfahrung in der Implementierung und Verwaltung von Microsoft SQL Server. Möchten Sie mehr darüber erfahren? Kontaktieren Sie uns für weitere Informationen.
