Wenn man vom SQL Server Management Studio ein Skript für einen Index generieren lässt, dann werden automatisch folgende Optionen eingefügt:

STATISTICS_NORECOMPUTE = OFF,
IGNORE_DUP_KEY = OFF, --das hier lässt man wohl besser abgeschaltet
ALLOW_ROW_LOCKS = ON,
ALLOW_PAGE_LOCKS = ON

Was bedeuten diese Optionen bzw. sollte ich die Standardwerte ändern? Sollte ich z.B. Page-Locks ausschalten, um die Nebenläufigkeit zu steigern?

den ersten Teil kannst du wohl vergessen:

NORECOMPUTE

Gibt an, dass Statistiken nicht automatisch von Datenbankmodul neu berechnet werden sollen. Wenn diese Option angegeben ist, werden zuvor erstellte (alte) Statistiken von Datenbankmodul weiter verwendet, auch wenn sich die Daten geändert haben. Die Statistiken werden von Datenbankmodul nicht automatisch aktualisiert und verwaltet. Dies kann zu nicht optimalen Plänen führen.
ms188038.Caution(de-de,SQL.90).gifVorsicht:
Es wird die begrenzte Verwendung dieser Option empfohlen, die nur einem qualifizierten Systemadministrator vorbehalten sein sollte.

Quelle: http://msdn.microsoft.com/de-de/library/ms188038%28SQL.90%29.aspx

ALLOW_ROW_LOCKS bedeutet, daß ein oder mehrere Datensätze gesperrt werden können.
Zum Beispiel durch ein select for update, werden die betreffenden Datensätze gesperrt und können durch andere Transaktionen erst benutzt werden, wenn die Sperre wieder aufgehoben wird.

Du schreibst, daß du SQL-Server 2005 benutzt, daher ist dieser Parameter völlig irrelevant, da der Server automatisch Zeilensperren nutzt.

Mit Seitensperren bin ich nicht so bewandert, nehme aber an daß sie ähnlich arbeiten wie Zeilensperren.

Also ist die Frage ob du in deiner Datenbank das Sperren von Datensätzen grundsätzlich zulassen und auch nutzen möchtest.

Ich stimme MiW 100% zu. Da du nach best-pactice fragst, ist die Antwort "Lass die Standardwerte so wie sie sind" (darum sind es Standardwerte :-) und in diesem Fall auch sinnvoll). Allerdings kann es Fälle gegeben, bei denen es sinnvoll ist, von den Standardwerte abzuweichen, aber alle diese Fälle hier zu diskutieren, führt du weit und vor allem weg von der Frage nach best-practice.