SQL Server 2008 R2 Default für Fillfaktor wiederherstellen

Question

Sehr geehrte Damen und Herren,

ich habe drei - idealtypisch - identische Datenbanken im Einsatz (Entwicklung, Referenz, Produktion). Bei einer dieser Datenbanken unterscheidet sich von den anderen beiden Datenbanken geringfügig: Der Fillfaktor ist dort stets auf 90 gesetzt, während er bei den anderen beiden Datenbanken (Referenz) der Fillfaktor NULL ist.

gibt es eine einfache Möglichkeit, auch bei dieser Datenbank den Fillfaktor überhaupt wieder auf NULL zu setzen, ggf. per ALTER in jedem einzelnen betroffenen Objekt?

MfG

Answer 1

Hallo,

Der Fill Faktor als Vorschlagswert ist auf Serverebene definiert, nicht auf Datenbankebene. Du kannst ihn mit

EXEC sys.sp_configure N'fill factor (%)', N'0'
GO
RECONFIGURE WITH OVERRIDE
GO

ändern oder in SSMS über die Server-Eigenschaften => Database Settings

---

Olaf Helper

[ Blog] [ Xing] [ MVP]

Answer 2

Hallo,

ergänzend zu Olafs Antwort:

nach der Erstellung ist der Füllgrad mit dem Index verknüpft. Um ihn zu ändern musst Du den Index neu erstellen.

Siehe Angeben des Füllfaktors für einen Index

Für etwas mehr Hintergrund, lies bitte:

Kalen Delaney: The Fill-Factor Truth

Kendra Little: 5 Things About Fillfactor

Gruß Elmar

Answer 3

Hallo,

ich habe eine Lösung gefunden. Sofern man mit VS (konkret VS2010) zugreifen kann, so lässt sich der Fillfaktor manuell ändern:

) Das ist etwas zeitaufwändig, aber es geht ohne die Indizes und die PK(!) zu entfernen und neu anzulegen.

MfG

Answer 4

Das ist etwas zeitaufwändig, aber es geht ohne die Indizes und die PK(!) zu entfernen und neu anzulegen.

Damit liegst Du falsch. Lass Dir mal für die Änderung von SSMS das Script erstellen, dann wirst Du sehen, das hierbei sehr wohl der Index gelöscht und wieder neu angelegt wird. Der Weg über den Design Wizard ist nur etwas bequemer.

---

Olaf Helper

[ Blog] [ Xing] [ MVP]

Answer 5

Hallo,

FALSCH! Du hättest oben mal etwas lesen sollen.

Ein Füllfaktor wird nur beim Anlegen bzw. Neuaufbau des Indizes berücksichtigt, der eingetragene Wert wird verwendet wenn nichts anderes vorgeben wird. Das Ändern im Designer führt zu einem Neuaufbau - was Du merken würdest wenn die Tabelle etwas größer ist ;)

Als Beispiel - verkürzt, die FKs fehlen - für die Northwind Customers, wenn man als Füllfaktor 100 einträgt:

ALTER TABLE dbo.Customers
	DROP CONSTRAINT PK_Customers
GO
ALTER TABLE dbo.Customers ADD CONSTRAINT
	PK_Customers PRIMARY KEY CLUSTERED 
	(
	CustomerID
	) WITH( PAD_INDEX = OFF, FILLFACTOR = 100, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

GO

Das Skript kommt aus dem SSMS - und nein, die Visual Studio Designer machen das auch nicht anders.

Gruß Elmar

Answer 6

Hallo Elmar,

Deinen Hinweis mit dem Lesen fand ich nicht gerade toll. Es stimmt, meine Antwort war missverständlich, es kommt auf den Blickwinkel an: Mir ging es darum, auf einfache Weise das Problem zu lösen. Wenn das VS unter der Haube so macht, wie Du es beschrieben hast, dann ist das für mich kein Problem, die Implementierung ist mir da erst mal egal. Entscheidend war für mich, was länger dauert: Einen Skript zu schreiben, den ich wahrscheinlich oder hoffentlich nie wieder benötige ODER das Problem mit VS zu lösen. (Es hat übrigens bei einigen Tabellen gedauert.)

Wenn ich richtig verstanden habe, dann würde meine Antwort stimmen, wenn ich nur "Das ist etwas zeitaufwändig." geschrieben und , "aber es geht ohne die Indizes und die PK(!) zu entfernen und neu anzulegen" weggelassen hätte. Mir ging es in diesem Fall um das manuelle Entfernen und Anlegen, nicht um die Implementierung. Olaf hat das ganz gut auf den Punkt gebracht.

Dennoch vielen Dank für die Präzisierung!

MfG

 

Answer 7

Hallo,

ich finde nicht so toll, was Deine Antwort zu bestätigen scheint, dass Dir die Konsequenzen egal sind.

Nimm mal eine Tabelle mit einigen hunderttausend oder gar Millionen Einträgen oder eine mit Dutzenden von Fremdschlüsseln. Du wirst feststellen, dass es nicht "egal" ist, was passiert. Wenn die Änderung über das Visual Studio  wegen eines Timeouts "verreckt", mag das sogar ein Segen sein ;(

IMHO bedenklicher ist, dass Dir eine Anzeige wichtiger zu sein scheint, als was der Füllfaktor aussagt. Denn ob dort eine andere Zahl steht, als bei den anderen Datenbanken, hätte (zunächst) gar keine Auswirkungen - wie man hätte nachlesen können (sollen). Die Aktion wäre aus solchem Blickwinkel sinnbefreit.

Zum Schluss: Hättest Du eine Änderung z. B. mit Ola Hallengren's SQL Server Index and Statistics Maintenance gemacht, hättest Du Deine Zeit anderweitig nutzen können und nebenbei was gelernt.

Was man Dir geschrieben hätte, hättest Du gefragt. Soviel zu Deiner "Lösung".

Gruß Elmar