So wie versprochen reiche ich noch den Artikel zum Thema SQL Server Best Practices nach

Wie wir ja alle wissen ist der SQL Server ein essentieller Bestandteil einer SharePoint Farm da fast alle Daten in zahlreichen Datenbanken abgelegt werden. Es ist daher äußerst wichtig, dass die Konfiguration dieser Datenbanken und der Server gut geplant und implementiert ist.

Was sind die Anforderung an die Datenbanken ?

Das Problem sind die vielen heterogenen Daten und Datentypen die in SharePoint abgelegt werden können.

Um diese Daten auch vernünftig ablegen zu können ist es notwendig ein ausgeklügeltes Datenbank Schema anzuwenden um die unterschiedlichen Datentypen abzubilden. Ein “Problem” ist auch, dass alle Dokumente, Listen, Seiten, in jeweils nur genau einem Table abgelegt werden und dann nur auf die einzelnen Sites und Webs referenziert wird. Um die Performance dieser Tables zu gewährleisten wird ein Record in SharePoint Content Datenbanken auf mehrere Zeilen aufgeteilt.

Doch ich möchte mich an dieser Stelle nicht allzu sehr in technischen Details über den Aufbau der Datenbank Schemen verlieren, sondern auf das wesentliche Thema des Eintrags zurückkehren.

Nämlich Best Pratices für SQL Server in Verbindung mit SharePoint 2010

Zunächst ein paar Grundlegende Dinge die zu beachten sind im Umgang mit SQL Server 2008 für SharePoint Installationen:

1. NIEMALS !!!SharePoint Datenbanken direkt über das SQL Management Studio öffnen oder bearbeiten, sondern nur über die Benutzeroberfläche der Central Administration.
2. SQL Server und SharePoint sollten nicht am gleichen Server installiert werden
3. Server müssen immer in 64-Bit Version mit möglichst viel Hauptspeicher installiert werden. Minimum sind 8GB, je mehr, desto besser
4. Gigabit Ethernet Verbindung zwischen Datenbank- und Frontend Servern
5. Ausfallsicherheit: SQL Server sollten geclustert werden, wenn das nicht möglich ist, sollte zumindest Database Mirroring eingerichtet werden.
6. NIEMALS !!! SharePoint Datenbanken direkt verändern !!! (und ja, es ist Absicht, dass ich das zweimal erwähne )

SQL Server ist, was die Performance betrifft, auch sehr abhängig vom jeweiligen Storage System auf dem die Datenbanken abgelegt werden, daher gibt es auch da einiges zu beachten:

Host Bus Adapter sollten immer auf dem neuesten Firmware Stand sein um optimale Performance zu garantieren. Es macht auch durchaus Sinn, sich von der tatsächlichen I/O Performance mit einem kleinen Tool selbst zu überzeugen und nicht blind den Angaben des Storage Herstellers zu vertrauen. Mit SQLIO.exe kann man die Performance des eigenen Storage Systems selbst ausmessen.

Bei den Festplatten selbst muss dann auf die Größe der Zuordnungseinheiten geachtet werden. Standardmäßig ist diese Allocation unit size auf 4K eingestellt. Für SharePoint Datenbanken empfiehlt sich, diese Größe auf 64K zu ändern, was bis zu 30% Performance Steigerung bringen kann.

Positionierung der Datenbanken

Wenn möglich, sollten die TempDB einer SQL Server Installation auf einem RAID 10 um zusätzliche Ausfallsicherheit zu haben. Natürlich sollte man auch die Datenfiles und Logfiles auf jeweils eigene Disken legen, aber das sollte ja durchaus bekannt sein.

Bei größeren Implementierungen empfiehlt es sich auch, die Search Datenbanken auf eigenen Disken abzulegen um die Performance der Content Datenbanken nicht zu beeinträchtigen.

Abschließend möchte ich noch kurz die I/O intensivsten Datenbanken in absteigender Reihenfolge auflisten:

1. TempDB Data/Logfiles
2. Transaction Logs
3. Search DB
4. Content Datenbanken

Das ist natürlich noch längst nicht alles; es gibt noch vieles mehr, das es bei einer erfolgreichen Installation eines performanten SQL Servers zu beachten gibt doch das würde dann schön langsam den Rahmen dieses Beitrags sprengen, also möchte ich nur noch ein paar Schlagworte erwähnen

Maximum degree of parallelism

Health Analyzer rules

Index fragmentation

pre-sizing of database files

Sollte der geschätzte Leser noch mehr Details oder Beratung bei der eigenen Implementierung wünschen, steht Ihnen das Team von HATAHET gerne mit Rat und Tat zu Seite.

Mit diesem Artikel beschließe ich nun einmal die Berichterstattung von der SharePoint Konferenz 2011 in Berlin

und melde mich mich wieder mit neuen, interessanten Beiträgen

so long Ernst | ernst@hatahet.eu