SQL Server sık sık "emmek" büzülen endişe için iyi bir neden var. SQL 2005'teki Depolama Motorunun başkanı Paul Randal, ShrinkDB'nin çok kötü yazıldığını belirtti. Verileri en sonunda alarak boş alan bulacaktır ve en başına koyup DB dosyalarının 'ucunda' boş alan olana kadar bunu yapmaya devam edecektir. Bu noktada, alanı SQL Server'dan serbest bırakıp işletim sistemine geri verebilir. Veritabanı dosyalarınızı etkili bir şekilde tersine çevirirsiniz, böylece genellikle büyük parçalanma görürsünüz. Bu blog yayınındaki veya bu MCM Internals Video'daki görüşlerini okuyabilirsiniz
Her şeyde olduğu gibi, öncelikle bunları ortamınızda test etmeniz gerekir. Bunu yapmanın daha iyi bir yolu, verileri farklı bir dosya grubuna taşımaktır. Kümelenmiş dizin ile çevrimiçi dizin yeniden oluşturma ve sonra yeni dosya grubunda yeniden dizin yapabilirsiniz. Sonra eskisini bırakıp alanı serbest bırakabilir ve neredeyse hiç parçalanamazsınız. Bunun üzerinde çalışırken% 120 daha fazla yer kaplayacağını unutmayın. Buradaki sorun, sahip olmayabileceğiniz gibi ek boş alana bile ihtiyacınız olmasıdır. Bu bir kurumsal özelliktir.
Boş alan bu kadar yüksek bir seviyedeyse, uzun süren işlemleri önlemek için mermiyi ısırmanız ve DB'yi yavaşça küçültmeniz gerekebilir. Verilerinizin büyük ölçüde parçalanacağını ve her şeyi yeniden dizine eklemek istediğinizi unutmayın. Her şeyi yeniden endeksledikten sonra, kullanılmış alanınızı biraz havaya uçuracağınızı ve ek boş alana sahip olacağınızı unutmayın. Brent'in tavsiyelerine buradan bakın .
Boş alanın sizin için iyi olduğu ölçüde, parçalanma ve dosya büyüme faaliyetlerini ne kadar karşılayabileceğiniz meselesidir. IFI etkinken, dosya büyümesi neredeyse anında olur, ancak yine de parçalanırsınız. İyi bir kural, ihtiyacınız olduğunu düşündüğünüz kadar yer önceden konumlandırmak veya gerekiyorsa büyümeyi izlemek ve parçalar halinde düzenli olarak ayarlamaktır. Bu fiziksel parçalanmayı azaltır.
Ayrıca günlük dosyası büyümesi çok daha önemlidir. Ek günlük dosyaları VLF parçalanmasına neden olabilir. Bu, geri yüklemelerinizi çok daha yavaş hale getirir ve kontrol noktasını / kesikleri etkileyebilir. Parçalanmış bir günlükle aldığınız bazı performans riskleri. Bir Do DBCC LOGINFO();her veritabanı üzerinde. Kim Tripp başına sayıyı 50ish civarında tutmaya çalışın, ancak yüzlerce görürseniz, parçalama sorunlarınız vardır, bu da günlük dosyalarınızın işlemleri desteklemek için büyümesi gerektiği anlamına gelir. Paul Randal'a göre günlük dosyanızın ne olması gerektiğini görmenin iyi bir yolu, bir hafta boyunca büyümesine ve yeniden dizine eklemesine izin vermektir. Bu iyi bir nokta olabilir, belki de her ihtimale karşı biraz daha fazla boş alan atabilirsiniz. Günlüklerinizin DBCC LOGINFO () ile parçalanmadığından emin olun; yine ve eğer öyleyse, çok fazla büyüdükleri anlamına gelir. Kullanarak günlük dosyasını küçültün ve yeniden genişletinbu yöntem .