CBonnkirch 0 Geschrieben 18. März Melden Geschrieben 18. März (bearbeitet) 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 Zitieren
vkf 0 Geschrieben 18. März Melden Geschrieben 18. März Warum steckst du nicht einfach eine zusätzliche Festplatte in deinen Server? Zitieren
wznutzer 36 Geschrieben 18. März Melden Geschrieben 18. März 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. Zitieren
CBonnkirch 0 Geschrieben 19. März Autor Melden Geschrieben 19. März Hier nochmal die exakten Anzeigen Beim Verkleinern - Datenbank Beim Verkleinern - Dateien für Daten für Protokoll Das passt doch nicht zusammen. Zitieren
NilsK 2.987 Geschrieben 19. März Melden Geschrieben 19. März 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 Zitieren
CBonnkirch 0 Geschrieben 19. März Autor Melden Geschrieben 19. März (bearbeitet) 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 Zitieren
NorbertFe 2.182 Geschrieben 19. März Melden Geschrieben 19. März vor 8 Minuten schrieb CBonnkirch: MSSQL eine Hauptspeichernutzung von 80GB. Oder ist das "normal"? Soll der ram lieber ungenutzt rumliegen? Zitieren
cj_berlin 1.412 Geschrieben 19. März Melden Geschrieben 19. März 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. 1 Zitieren
NilsK 2.987 Geschrieben 19. März Melden Geschrieben 19. März 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 Zitieren
Dukel 463 Geschrieben 19. März Melden Geschrieben 19. März Bitte nicht ohne Grund MSSQL Datenbanken shrinken! https://www.brentozar.com/archive/2009/08/stop-shrinking-your-database-files-seriously-now/ Zitieren
wznutzer 36 Geschrieben 19. März Melden Geschrieben 19. März 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. Zitieren
v-rtc 92 Geschrieben 19. März Melden Geschrieben 19. März 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 :) Zitieren
Dukel 463 Geschrieben 19. März Melden Geschrieben 19. März vor 6 Minuten schrieb v-rtc: Gibts ne Kurzfassung? Frage für einen Freund :) Ich zitiere aus dieser Seite: Zitat AAAAAAAAAAARGH. 2 Zitieren
v-rtc 92 Geschrieben 19. März Melden Geschrieben 19. März vor 3 Minuten schrieb Dukel: Ich zitiere aus dieser Seite: Ich wusste es Zitieren
t-sql 22 Geschrieben Donnerstag um 17:10 Melden Geschrieben Donnerstag um 17:10 (bearbeitet) @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 Donnerstag um 17:11 von t-sql Zitieren
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.