SQL konusunda iyi değilim ama korunacak bir veritabanım var.
Bunun için neredeyse hiç yer kalmadı, bu nedenle 2008 yılı için tüm verileri silmeye karar verdim. Silme sorgusunu yürüttükten sonra (yaklaşık 10.000.000 satır temizlendi) ve temizleme günlüğünü öğrendim eylemlerin veritabanı boyutu üzerinde etkisi yoktu. Yapmam gereken başka bir şey var mı?
Yanıtlar:
Küçültmek burada belirtilen nedenlerden dolayı gerçekten tehlikelidir. Jimbo'nun cevabı ile John'un cevabı arasında mutlu bir ortam var ... Veritabanınızı küçültmek isteyip istemediğinizi her zaman ciddiye almalısınız.
İdeal bir dünyada - DB'nizi büyümek için bol miktarda boş alan oluşturacaksınız. Bu veritabanına "Doğru Boyutlandırma" diyorum. Bu boş alanın orada olmasına izin verirsiniz ve geri vermek ve toplam bedeninizi kullanılmış bedeninizde doğru tutmak için çabalamazsınız .. Neden? Çünkü veritabanınız sonunda tekrar büyüyecek .. Sonra tekrar küçüleceksin .. Ve bu korkunç yararsız shrink paterninde sıkışıp kalacaksınız, ardından büyümeyi izleyeceksiniz - ve tüm zaman boyunca, bir kaçının işaret ettiği gibi endeks parçalanma oranını arttırmak.
İnsanları " O küçültme düğmesine dokunma! " Ya uyardığım bir yerde blog yazdım ama bazen ... Bazen buna ihtiyacın var. Eğer büyük bir veritabanınız varsa, sadece önemli bir alan boşaltın ve tekrar tekrar büyümeyi beklemeyin - peki daha sonra yeniden oluşturma yoluyla endeks fragmantasyonunuzu halledebildiğiniz sürece tek seferlik bir işlem olarak küçülmeyi düşünmek sorun değil onlar. Büzülme işlemi zaman alabilir, bu yüzden büzüşen koşu fiyatını ödeyebileceğiniz bir süre için plan yapmak istersiniz. Boş bir DB oluşturma ve içine veri kopyalama yaklaşımı işe yarıyor - ancak bu daha büyük veritabanlarında ve birçok veride çok zor olabilir.
Gelecekte normal kullanım ve büyüme modelleriyle o boşluğu tekrar DB'ye eklemeyi planlıyorsanız, o zaman boşluğu orada bırakmak isteyebilirsiniz.
Ayrıca
İşlem günlüğünüzü "temizlediğinizi" söylediniz. Bunu nasıl yaptığınızı bilmek isterdim ama paylaştığım yazıyı okuduğunuzda ve serideki diğer kişiler işlem günlüğü yönetimi hakkında bazı ipuçları göreceksiniz. Ancak, kısacası - Tam Kurtarma modundaysanız, günlüğün kendisini yeniden kullanmasını sağlamak için düzenli kayıt yedekleme yapıyor olmalısınız. Aksi halde - Tam Moddayken hiçbir günlük yedeği olmadan - günlük dosyası büyümeye ve büyümeye ve büyümeye devam eder ve her zaman yaptığınız şeyi kaydeder çünkü SQL’e yalnızca çöküş kurtarma için bu günlüğü korumak istemediğinizi değil Kurtarma amacıyla zamanın belirli bir noktasına kadar kurtarmak için işlemleri geri almak / işlemleri geri almak için el ile yedekleme ... Basit ve günlüklerin aşırı büyüdüğünü görmek içinBEGIN TRAN ... do work.... COMMIT TRANya da sadece büyük bir DELETEaçıklama yaptıysanız ve gizli bir işlemle tüm veri karmaşasını sildiyseniz.
Ayrıca dosya sisteminizde bu boş alanı aradığınızı farz ediyorum. Eğer SQL içinde ve sahip olduğunuz o büyük dosyada arıyorsanız, işlemden hemen sonra bakarsanız, tamamlamak için hayalet temizleme bekliyor olabilirsiniz. Paul Randal, Ghost Cleanup hakkında blog yazdı .
Veritabanındaki satırların silinmesi, asıl veritabanı dosyasının boyutunu azaltmaz.
Satır silme işleminden sonra veritabanını sıkıştırmanız gerekir.
SQL Server 2005 DBCC SHRINKDATABASE (Transact-SQL)
Bunu çalıştırdıktan sonra, dizinleri yeniden oluşturmak isteyeceksiniz. Büzülme tipik olarak indeks parçalanmasına neden olur ve bu da önemli bir performans maliyeti olabilir.
Ayrıca, küçülmeden sonra, biraz boş alan elde etmek için dosyaları yeniden büyütmenizi tavsiye ederim. Bu şekilde, yeni satırlar geldiğinde, otomatik büyümeyi tetiklemiyorlar. Autogrowth'un bir performans maliyeti vardır ve mümkün olduğunda (uygun veritabanı boyutlandırmasıyla) kaçınmak istediğiniz bir şeydir.
VERİTABANINIZI KISMAYIN!
"Neden bu oluyor? Bir veri dosyası küçültme işlemi aynı anda tek bir dosya üzerinde çalışıyor ve GAM bitmaplerini (bkz. Depolama Motorunun İçinde: GAM, SGAM, PFS ve diğer tahsis haritaları) Daha sonra dosyayı olabildiğince ileriye doğru hareket ettirir, vb. vb. Yukarıdaki örnekte, kümelenmiş dizinin sırasını tamamen tersine çevirdi, mükemmel şekilde birleştirilip mükemmel şekilde parçalanmış hale getirdi. "
http://www.sqlskills.com/BLOGS/PAUL/post/Why-you-should-not-shrink-your-data-files.aspx
"Shrinking veritabanının ironisine bakın. Bir kişi veritabanını küçülterek yer kaplar (performansa yardımcı olacağını düşünerek), bu da parçalanmanın artmasına neden olur (performansı düşürür). Parçalanmayı azaltmak için bir tanesi yeniden boyutlandırır. Veritabanının orijinal boyutundan daha fazla arttırılması için veritabanı (küçülmeden önce) Eh, Shrinking ile kişi genellikle aradığı şeyi elde etmedi. "
Verileri sildiğinizde, SQL Server daha sonra yeni veriler eklemek için kullanmak üzere yer ayırır. Veritabanını küçültmeniz gerekir. Daha fazla bilgiyi burada bulabilirsiniz .
Bunu buldum çünkü veritabanımın "maksimize ettiği" bir grup yedek tabloyu sildim. Neden küçülmediğini düşünerek "Boyut" özelliğine bakmaya devam ettim. . Bunu okuduktan sonra hayır, veritabanını küçültmek istemiyorum. Yapmak istediğim şey, daha önce sildiğim önemsiz alanın "geri kazanılması". Bakmam gereken şey "Space Available" idi. Sanırım belki de başkasının da buna bakması gerekebilir.
Tablonun üzerinde dizinler varsa, büyük miktarda veriyi sildikten sonra parçalanmanın olabileceğine dikkat çekmek gerekir. Bugün yaklaşık 13GB alan ~ 70M kayıtların bulunduğu bir masam vardı. 1639 kayıt (geri kalanı tek bir böcek tarafından oluşturuldu) olarak temizledim ancak masa hala 4,5GB civarında sürdü. Tablodaki tüm dizinleri yeniden oluşturduktan sonra sadece 85 sayfa alıyordum (680kb). Ondan sonra, alanı geri kazanmak için artımlı küçültme dosyası kullandım (ve tekrarı önlemek için sistemdeki hatayı düzelttim).