32 Secondary Data Files
Gestern wurde mal wieder Software bei uns von einem Drittanbieter installiert. Nachdem ich die Empfehlungen für die Datenbanken gehört hatte, musste ich erst mal tief Luft holen.
Hier sind die Empfehlungen des Herstellers:
- Ursprüngliche Größe der Files 10 MB
- Vergrößerung 1 MB (kein Problem, geht ja automatisch, Ziel sind ein paar GB)
- Wartungsplan mit Shrink-DB und immer Rebuild Index
- Recovery-Modell kann man ruhig auf Simple stellen, da kein Point in Time Recovery möglich ist. (Also immer alles neu installieren? Oder ist hier nur gemeint, kein Restore mit einem Punkt in der ferneren Vergangenheit, da andere Systeme ebenfalls zurückgesetzt werden müssten?)
32 NDFs
Meine größte Überraschung erlebte ich aber, als ich herausfand, dass eine der Datenbanken über 32 secondary datafiles verfügte. Erst mal keine schlechte Idee NDFs zu verwenden:
- Man verteilt diese auf verschiedene Platten um Performance zu gewinnen
- Man legt gezielt einzelne Tabellen in dedizierten NDFs ab, um diese ggf. schneller zurücksichern und verfügbar machen zu können (Enterprise Feature)
- Man trennt Daten und Indizes um Performance zu gewinnen
- Read-Only-Tabellen werden in Dateigruppen gelegt, die auch das Attribut Read-Only erhalten, um die Daten vor Veränderung zu schützen und evtl. Backup-Zeiten zu reduzieren.
- Man kann System- und User-Tabellen trennen (Systemtabellen liegen immer in der PRIMARY Filegroup) um das Risiko zu minimieren, dass die PRIMARY-Filegroup defekt wird und die ganze Datenbank damit unbrauchbar.
Nachdem ich einen Blick in die Datenbank geworfen hatte, wurden meine Befürchtungen bestätigt. Es gibt zwar einzelne Tabellen, die in speziellen Dateigruppen angelegt werden, aber Daten und Indizes liegen immer schön beisammen. Alle NDFs liegen natürlich in einem Verzeichnis und selbst wenn, hätte ich keine 32 Laufwerke zur Verfügung. Ein "Point in Time"-Recovery ist sowieso nicht möglich, eine Rücksicherung einzelner Dateigruppen ist sicher auch nicht vorgesehen.
Die Erklärung des Herstellers: Verteilung auf viele NDFs ist für große Installationen vorgesehen und wird auch bei kleineren Installationen standardmäßig mitgemacht. Bei sehr großen Installationen könnte man die NDFs auch über verschiedene SQL Server verteilen. Hoppla! Das habe ich ja noch nie gehört! ;-)
Eine Datenbank über verschiedene SQL Server? Beide Server haben Zugriff auf die selben Daten?
Nun warte ich darauf, dass unsere Installation auch in den Bereich der sehr großen Installationen kommt, damit ich mir das mal anschauen kann!
Was gab es positives?
Zumindest verwendet diese Software einen dedizierten Windows-Account für ihren Service und benötigt auch nur db_owner-Rechte nachdem die Datenbanken installiert sind. Andere Hersteller kommen immer noch mit der Vorstellung daher, dass ihre Software unbedingt mit dem sa-Account laufen muss, da es sonst nicht möglich ist, die geeigneten Berechtigungen zu bekommen.
Man merke sich
Am besten schon vor der Installation sollte man den Drittanbietern auf die Finger schauen und das ein oder andere Konzept hinterfragen.
Wenn man keine Möglichkeit hat die Installation zu verhindern, sollte man zumindest versuchen die Spätfolgen zu minimieren, indem man z. B. die Größe der Files auf sinnvolle Werte setzt und auch das Wachstum nicht auf den Standardwerten belässt, sondern sinnvolle Zahlen hinterlegt.
Print article | This entry was posted by cmu on 04.09.12 at 12:05:00 . Follow any responses to this post through RSS 2.0. |