Christoph Muthmann
Architektur und Administration
Architektur und Administration
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:
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:
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!
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.
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 Christoph Muthmann on 04.09.12 at 12:05:00 . Follow any responses to this post through RSS 2.0. |
04.09.12 @ 19:07:47
Hallo Christoph,
fehlt nur noch der Name der großzügigen Anwendung. :-)
Viele Grüße
Volker
05.09.12 @ 07:52:03
Den Namen werde ich hier nicht preisgeben, denn trotz der etwas unkonventionellen Datenbankinstallation macht diese Software genau das, was sie soll. Abgesehen von den vielen Filegroups habe ich alle anderen Einstellungen mittlerweile angepaßt und verwende natürlich auch unsere Wartungs- und Sicherungsmechanismen.
Versöhnlich stimmt, dass Begriffe wie Foreign Key Constraints und Default keine Fremdwörter für den Hersteller sind und die Konsistenz der Daten nicht nur auf Applikationsebene geprüft wird.
Falls Du mehr wissen willst, können wir gerne mal in der Regionalgruppe drüber sprechen...
05.09.12 @ 10:27:31
Es ist empfohlen von externen Beratern, die teuer sind. Also - per Definition - muss es richtig(er) als das, was der Inhouse angestellte Subject Matter Expert in diesem Fall machen würde. Punkt! :-)