https://www.insidesql.org/blogs/uricken/?disp=comments de-DE http://backend.userland.com/rss 60 Wed, 29 Apr 2015 08:58:54 +0000 mmeyer c8161@https://www.insidesql.org/blogs/ Hallo Herr Ricken, danke für diesen Artikel. Allerdings hilft er mir nicht weiter, wenn eine Datenbank wirklich verkleinert werden muss um freien Speicher zu bekommen. Ein Kunde hat eine 800 GB Datebank. Nach einer Datenbereinigung ist die DB eigentlich nur noch ca. 80 GB groß und wird durch den regelmäßigen Einsatz von Löschskripten auch nicht mehr größer als ca. 100 GB. Ohne Shrinken kommt man aber nicht mehr an den Speicherplatz heran. Was wäre denn Ihre Empfehlung für so einen Fall? Viele Grüße Markus Meyer https://www.insidesql.org/blogs/uricken/2013/09/08/dbcc-shrinkdatabase-wirklich-ein-segen#c8161 Tue, 10 Sep 2013 15:13:32 +0000 uricken c2409@https://www.insidesql.org/blogs/ Hallo Torsten, ACK! - aber eine 600 GB-Datenbank für mehrere Stunden offline zu nehmen, ist ein NOGO :) Es gibt SLA, die pro Jahr maximal 6 Stunden definieren! Ein SHRINKDATABASE ist in solchen Systemen IMMER der falsche Ansatz. Aber leider so z. B. in einer Anwendung erlebt, bei der JEDEN Montag ein Incident geöffnet wurde, um die Datenbank (DATA und LOG) zu verkleinern! Das die Kosten für diese "Snnlosaktion" deutlich über den Kosten für zusätzlichen Storage liegen, war/ist dem Business bis heute nicht zu vermitteln! https://www.insidesql.org/blogs/uricken/2013/09/08/dbcc-shrinkdatabase-wirklich-ein-segen#c2409 Tue, 10 Sep 2013 05:59:54 +0000 tosc c2405@https://www.insidesql.org/blogs/ p.s.: kleiner Nachtrag zur starken Fragmentierung von Dateien im NTFS-Volume <a href="http://support.microsoft.com/kb/967351" target="_blank">http://support.microsoft.com/kb/967351</a> http://support.microsoft.com/kb/967351]]> https://www.insidesql.org/blogs/uricken/2013/09/08/dbcc-shrinkdatabase-wirklich-ein-segen#c2405 Mon, 09 Sep 2013 14:32:32 +0000 tosc c2396@https://www.insidesql.org/blogs/ gerne :-) ... auch bei 24/7 muss es ein Maintenance Fenster geben. https://www.insidesql.org/blogs/uricken/2013/09/08/dbcc-shrinkdatabase-wirklich-ein-segen#c2396 Mon, 09 Sep 2013 14:02:50 +0000 uricken c2395@https://www.insidesql.org/blogs/ Lieber Torsten, herzlichen Dank für den Link; das Tool kannte ich noch nicht. Da aber für eine Defragmentierung ein DB-File offline genommen werden muss, ist es nicht wirklich sinnvoll in einer 24 / 7 - Anwendung ;( Bezüglich der "Erfahrungen eines dba" solltest Du nicht zu optimistisch sein :) Gerade im Segment Betrieb / Operations weltweit agierender Konzerne sollte man die Messlatte nicht sehr hoch setzen. Ich habe schlechte Erfahrungen in diesem Bereich mit den Kollegen "jenseits des Pazifks" machen müssen. Sicherlich nicht repräsentativ aber immer wieder erstaunlich! https://www.insidesql.org/blogs/uricken/2013/09/08/dbcc-shrinkdatabase-wirklich-ein-segen#c2395 Mon, 09 Sep 2013 11:39:40 +0000 tosc c2394@https://www.insidesql.org/blogs/ Hallo Uwe, ich dachte über diesen Punkt sind die meisten DBA's schon raus - naja. Kleine Anmerkung noch zur hohen Fragmentierung auf Dateisystemebene, hier hilft Contig von Mark Russinovich (<a href="http://technet.microsoft.com/en-us/sysinternals/bb897428" target="_blank">http://technet.microsoft.com/en-us/sysinternals/bb897428</a>). Mit contig -a DatenbankName.mdf kann man sich die physikalische Fragmentierung ansehen. Und nach einem ALTER DATABASE [DatenbankName] SET OFFLINE kann man mit contig DatenbankName.mdf die Datenbank auf Dateisystemebene defragmentieren. http://technet.microsoft.com/en-us/sysinternals/bb897428). Mit contig -a DatenbankName.mdf kann man sich die physikalische Fragmentierung ansehen. Und nach einem ALTER DATABASE [DatenbankName] SET OFFLINE kann man mit contig DatenbankName.mdf die Datenbank auf Dateisystemebene defragmentieren.]]> https://www.insidesql.org/blogs/uricken/2013/09/08/dbcc-shrinkdatabase-wirklich-ein-segen#c2394