DB Wachstum seit SQL 2K SP4

[O. Helper]

Hallo zusammen,

bisher hatte ich den SQL Server 2000 mit Service Pack 3 im Einsatz.
In der Zeit ist z.B. eine der DBs mit einer Größe von 1 GB täglich netto im Schnitt um ca. 2-3 MB gewachsen.

Nun habe ich vor einem Monat das Service Pack 4 installiert und seit dem wächst diese DB täglich um ca. 50 MB an, obwohl Programm- oder Workflow-technisch sich nichts geändert hat; mittlerweile ist sie 2,5 GB groß. Zumindest wird mir diese DB Größe im Enterprise Manager angezeigt, ebenso mit "exec sp_spaceused".
Ein SHRINKDATABASE, SHRINKFILE, ReIndex etc. hat an der Nettogröße (ohne LOG) nichts geändert.

Wenn ich aber hingegen mit SQL-DMO (SQLDMO.Table.DataSpaceUsed und .IndexSpaceUsed) mir über alle Tabelle den Speicherbedarf aufsummiere lasse, komme ich wieder auf die "alten" Werte von ca. 1,1 GB.

Hat jemand das gleiche Phänomen beobachtet?
Hat jemand eine Idee, wo & wie sich die 1,3 GB zusätzlicher Speicherplatzbedarf verstecken könnten?

Danke im Voraus.

Gruß, Olaf

[Andreas Kosch]

Hallo,
die Frage ist, ob nicht die Logdatei für das Anwachsen verantwortlich ist. Der folgende Aufruf sollte diese Frage klären:

DBCC SQLPERF (LOGSPACE)

Ist die Datenbank in irgendeine Replikation eingebunden

[O. Helper]

Hallo Andreas,

- Nein, das LOG ist nicht dafür verantwortlich. Das LOG lasse ich stündlich sichern (auch schon vorher) und bevor ich die Größe prüfe, lasse ich sie verkleiner. Aktuelle Größe ist 5 MB, so sehe ich es mit LOGSPACE, im Enterprise Manager und auch im Explorer bei der .LDF.

- Nein, die DB ist auch nicht in einer Replikation eingebunden

[O. Helper]

Etwas weiter bin ich gekommen; falls es jemanden interessiert, hier das Ergebnis:

Ich habe von 2 Software-Hersteller Datenbanken auf dem SQL Server, die DBs von Hersteller A wachsen wie erwähnt seit SP4 extrem stark, die von Hersteller B mit der normalen, bisher gewohnten Rate; es kann also nicht nur am SP4 liegen.

Mit EXEC sp_spaceused konnte ich dann mit der Zeit beobachten, das mit je 1 MB Daten ca. 6-8 MB "unused space" hinzukamen, statt das der vorhandene unused verwendet wurde.
Nach langem, detailierten Suchen viel mir dann auf, das Hersteller B konsequent "Clustered Indizes" verwendet hat (wie es auch allgemeine Empfehlung ist) und Hersteller A hat es ebenso konsequent vermieden.

Ich habe mir dann mal mit EXEC sp_spaceused 'TableName' die Tabellen mit den größen "unused space" herausgesucht und dort einen eigenen "Clustered Index" angelegt. Kaum geschehen, wurde der "unused space" freigegeben und die Datenbank konnte verkleinert werden.
Etwas darüber nachgedacht, ist es auch (fast) verständlich. Durch den "Clustered Index" werden die Daten physikalisch zusammenhängend geschrieben, während ohne sie der Reihe nach weg geschrieben werden und es zu Fragmentierung kommt.
Interessant nur, das bis SP3 der SQL Server es scheinbar besser organisieren konnte und es nun mit SP4 zu diesem Verhalten kommt.

Nun ja, seitdem ich auf den "großen" Tabellen überall einen "Clustered Index" habe, ist wieder alles in Ordnung, die DB Größe + Wachstumsrate ist wieder wie zu Zeiten SP3.

Da kann man mal wieder sehen, ein schlechter Datenbankentwurf rächt sich immer; manchmal halt nur etwas später.

Gruß, Olaf

[Andreas Kosch]

Hallo,

>..Hersteller A hat es ebenso konsequent vermieden.

das erklärt einiges. Wenn ein NONCLUSTERED INDEX für eine Tabelle angelegt hat, die keinen CLUSTERED INDEX hat, muss der SQL Server einen "Phanton-Clustered Index" anlegen. Der SQL Server bildet einen NONCLUSTERED INDEX, indem dort die Row-ID (RID) auf den entsprechenden Clusterd Index-Eintrag vermerkt wird. Wenn es zu diesem Zeitpunkt aber noch keinen Clusterd Index gibt, legt der SQL Server diesen als Phantom an. Das Phantom belegt Platz, ist jedoch im Schema nicht sichtbar (weil es ja ein internes technisches Hilfsmittel ist).

Anscheinend hat das SP4 die "Phantom"-Regeln modifiziert