Schrumpfen von Datenbanken - unstimmige Belegungsangaben

[CBonnkirch 0]

Bei Tasks - Verkleinern - Dateien ergibt sich in Summe für Daten und Log eine DB-Größe von 30 GB,  davon 29 GB verfügbar. Bei Tasks - Verkleinern - Datenbank sind dann plötzlich von 30 GB nur 5 GB verfügbar. Letzteres trifft eher zu, schon die Größe einiger Tabellen überschreitet 3 GB. 

 

Woher kommt diese Differenz und wie kann ich sie korrigieren. DBCC CheckDB, updateusage etc. haben nicht geholfen.

 

Vielen Dank

bearbeitet 18. März von CBonnkirch

[wznutzer 37]

Was siehst Du genau bei verkleinern -> Dateien? Also bei aktuell zugeordnet und frei, getrennt nach Daten und Log? Der verfügbare Speicherplatz ist nicht gleich dem, der beim Verkleinern frei wird.

[CBonnkirch 0]

Hier nochmal die exakten Anzeigen

 

Beim Verkleinern - Datenbank

 

Beim Verkleinern - Dateien

für Daten

für Protokoll

 

Das passt doch nicht zusammen.

[NilsK 3.046]

Moin,

 

Ist dir das nur aufgefallen oder entstehen daraus Probleme? 

 

Ich habe keine direkte Erklärung, aber vermutlich hängt es damit zusammen, wie SQL Server die Daten in den Dateien organisiert. Sie liegen meist nicht "am Stück". Durchaus denkbar, dass eine der Angaben daher falsch oder irreführend ist. Ich kann dem im Moment leider nicht genauer auf den Grund gehen. 

 

Gruß, Nils

[CBonnkirch 0]

vor 9 Minuten schrieb NilsK:

Moin,

 

Ist dir das nur aufgefallen oder entstehen daraus Probleme? 

 

Ich habe keine direkte Erklärung, aber vermutlich hängt es damit zusammen, wie SQL Server die Daten in den Dateien organisiert. Sie liegen meist nicht "am Stück". Durchaus denkbar, dass eine der Angaben daher falsch oder irreführend ist. Ich kann dem im Moment leider nicht genauer auf den Grund gehen. 

 

Gruß, Nils

Es scheint schon einen gewissen Einfluss auf die Speichernutzung zu haben. Bei ca. 50 GB Gesamtgröße aller DBs (davon zwei mit solchen Symptomen) hat MSSQL eine Hauptspeichernutzung von 80GB. Oder ist das "normal"?

bearbeitet 19. März von CBonnkirch

[NorbertFe 2.283]

vor 8 Minuten schrieb CBonnkirch:

MSSQL eine Hauptspeichernutzung von 80GB. Oder ist das "normal"?

Soll der ram lieber ungenutzt rumliegen?

[cj_berlin 1.508]

Moin,

 

SQL cacht Ergebnisse aller Leseabfragen, denn es könnte ja sein, dass man sie gleich nochmal benötigt. Es gibt vier PerfMon-Indikatoren, die Aufschluss darüber ermöglichen, was da abgeht:

 

• MSSQL$<Instanz>:Puffer-Manager: „Lebenserwartung der Seite“ und „Puffercache-Trefferquote“ --> besagen eigentlich das gleiche, nur aus unterschiedlichen Blickwinkeln. Wenn die Lebenserwartung hoch und die Trefferquote nah bei 100% liegt, wird der Cache zumindest genutzt  
• MSSQL$<Instanz>:Memory Manager: „Zielserverspeicher“ und „Serverspeicher gesamt“ --> im Idealfall sind beide gleich und unterhalb des für die Instanz konfigurierten Höchstspeichers.

 

Ich habe dazu vor 9 Jahren mal was für den IT-Administrator geschrieben.

[NilsK 3.046]

Moin, 

 

Ja, das ist normal und erwünscht, um das ausdrücklich zu beantworten. Die RAM-Nutzung ist beim SQL Server kein Hinweis auf Last. 

 

Gruß, Nils

[Dukel 468]

Bitte nicht ohne Grund MSSQL Datenbanken shrinken!

https://www.brentozar.com/archive/2009/08/stop-shrinking-your-database-files-seriously-now/

[wznutzer 37]

vor 2 Stunden schrieb CBonnkirch:

Das passt doch nicht zusammen.

Hast Du Filestream aktiv? Das ist ein weiterer Punkt in der Combobox der beim manuellen Vergleichen beachtet werden müsste. Soweit ich weiß, siehst du beim Shrink die Werte des PFS (Page Free Space), das ist etwas anderes, als Du mit dbcc updateusage aktualisierst. PFS sagt dem SQL-Server wo welche Seiten frei sind. Das lässt sich, meine ich, nur mit dbcc checkdb (ohne physical_only) "korrigieren", wenn da etwas durcheinander ist.

[v-rtc 92]

vor 39 Minuten schrieb Dukel:

Bitte nicht ohne Grund MSSQL Datenbanken shrinken!

https://www.brentozar.com/archive/2009/08/stop-shrinking-your-database-files-seriously-now/

Gibts ne Kurzfassung? Frage für einen Freund :)

[Dukel 468]

vor 6 Minuten schrieb v-rtc:

Gibts ne Kurzfassung? Frage für einen Freund :)

Ich zitiere aus dieser Seite:

Zitat

AAAAAAAAAAARGH.

 

[v-rtc 92]

vor 3 Minuten schrieb Dukel:

Ich zitiere aus dieser Seite:

 

Ich wusste es

[t-sql 22]

@CBonnkirch Was zeigt denn der Report Disk Usage bzw. Disk Usage by Table im SSMS? Mal abgesehen davon, das es eigentlich faktisch keinen Grund gibt um Datenbanken zu verkleinern.

bearbeitet 20. März von t-sql

[t-sql 22]

vor 12 Stunden schrieb vkf:

Da gibt es einige Gründe, vielleicht sind Daten "fünf Jahre und alter" nicht mehr relevant der Markt sich geändert hat oder oder oder.

Nö, alte Daten sind ja kein Grund. Und auch sonst gibt keinerlei Gründe Datenbanken zu schrumpfen.