Otomatik küçültme SQL Server'ın açık olması güvenli midir?

Veritabanları için etkinleştirilebilecek birçok SQL Server seçeneği vardır ve en yanlış anlaşılanlardan biri de otomatik küçültmedir. Güvenli mi? Değilse neden olmasın?

(Başlangıçta normal bir soru olarak sordum ancak doğru yöntemi buldum - teşekkürler BrentO)

Hayır asla.

ServerFault'da bununla birkaç kez karşılaştım ve iyi bir tavsiyeyle geniş bir kitleye ulaşmak istiyorum. İnsanlar böyle şeyler yapmak için kaşlarını çattıyorsa, oy verin ve bunu memnuniyetle kaldıracağım.

Otomatik küçültme, etkinleştirilmesi gereken çok yaygın bir veritabanı ayarıdır. Bu iyi bir fikir gibi görünüyor - veritabanından fazladan boşluk kaldırın. Otomatik küçültmenin pozitif olarak kötü olduğunu bilemeyebilecek çok sayıda 'istemsiz DBA'lar var (TFS, SharePoint, BizTalk veya sadece normal SQL Server'ı düşünün).

Microsoft’ta SQL Server Depolama Motoruna sahip oldum ve otomatik küçültme özelliğini kaldırmaya çalıştım, ancak geriye dönük uyumluluk için kalmak zorunda kaldım.

Otomatik küçültme neden bu kadar kötü?

Veritabanının tekrar büyümesi muhtemel, öyleyse neden küçültelim?

1. Shrink-grow-shrink-grow, dosya sistemi düzeyinde parçalanmaya neden olur ve çok fazla kaynak gerektirir.
2. Ne zaman devreye girdiğini kontrol edemezsiniz (normal-ish olsa bile)
3. Çok fazla kaynak kullanıyor. Sayfaları veritabanında dolaştırmak CPU, çok fazla G / Ç alır ve çok fazla işlem günlüğü oluşturur.
4. İşte gerçek atıcı: veri dosyası daralması (otomatik olsun ya da olmasın) büyük indeks parçalanmasına neden olur ve bu da düşük performansa yol açar.

Bir süre önce neden olduğu sorunları gösteren ve biraz daha ayrıntılı olarak açıklayan örnek bir SQL komut dosyasına sahip bir blog yazısı yaptım. Bkz. Otomatik küçültme - KAPALI konuma getirin! (blogumda böyle bir reklam veya önemsiz). Bu, zaman zaman yararlı ve gerekli olan günlük dosyasını küçültmekle karıştırılmamalıdır.

Öyleyse kendinize bir iyilik yapın - veritabanı ayarlarınıza bakın ve otomatik küçültmeyi kapatın. Aynı şekilde, bakım planlarınızı daraltmamalısınız. Sözcüğü meslektaşlarına yay.

Düzenleme: Bunu, ikinci cevabın hatırlattığı gibi eklemeliyim - bir büzülme işlemini durdurmanın yolsuzluğa neden olabileceği konusunda yaygın bir yanılgı vardır. Hayır olmaz. Shrink kodunu SQL Server'da kullanırdım - mevcut sayfa kesilirse yaptığı hareketi geri alır.

Bu yardımcı olur umarım!

Tabii ki, Paul haklı.

Tüm DB'leri ve autoshrink ayarlarını görün. Çok fazla veritabanınız varsa, gizlice girilir.

sp_msforeachdb  @command1 = 'Select ''[?]'',DATABASEPROPERTYEX(''?'',''IsAutoShrink'')'

Bu dmv'de bir yerlerde mi ... Merak ediyorum.

Bu "güvensiz" değildir - hiçbir şeye zarar vermez.

Ancak, veri tabanının kapanmaya ve pahalı bir düzenleme alıştırması başlatmaya karar verebileceği üretim ortamları için bu taleplerin daha uzun sürmesi için bir istekler gelmeden hemen önce önerilmemektedir. Shrinkleme işlemlerini, yedekleme gibi diğer bakım işlemleriyle birlikte (aslında, yedekleme işleminden sonra - işlem günlüğünden bu şekilde daha fazlasını alacaktır) kullanmaktan çok daha iyidir. Ya da bir büyüme sorunu olmadıkça hiç küçülmeyin - kullanılmayan tahsis edilen alanın belirli bir oranın veya sabit büyüklüğün ötesinde ne zaman büyüdüğünü size bildirmek için her zaman bir monitör ayarlayabilirsiniz.

IIRC seçeneği, Express dışındaki tüm MSSQL sürümlerindeki tüm veritabanları için varsayılan olarak kapalıdır.

TechNet'te, SQL bakımını daha ayrıntılı olarak açıklayan bir beyaz sayfa bulunmaktadır.

http://technet.microsoft.com/en-us/library/cc262731.aspx

Hem Autogrow hem de Autoshrink etkinleştirilmiş bir SQL sunucusu gördüm. Bu (nispeten güçlü) sunucu, son derece yavaştı, çünkü bütün gün bütün yaptıkları daraltıldı ve veritabanı dosyalarını geliştirdi. Autoshrink yararlı olabilir, ancak iki şey öneririm:

1. Autoshrink'i varsayılan olarak kapatın.
2. Sunucunuzun yapılandırmasını belgeleyin, böylece Autogrow ve Autoshrink'in nerede etkin olduğunu ve nerede olmadıklarını bilirsiniz.

Veritabanını küçültmek zorunda kaldığım tek zaman, test sunucusundaki bir kopyasını daha az disk alanı olan (üretim veritabanını tutmak için yetersiz) yenilemek oldu.

Üretim veritabanının dosyalarında cömert boş alan vardı, ne yazık ki yedeklediğiniz dosya boyutunda bir veritabanını geri yüklemeniz gerekiyor. Böylece, yedeklemeden önce üretimi küçültmekten başka seçeneğim yoktu. (Küçültme yaş aldı, çok fazla kaynak tüketildi ve ardından işlem günlüğü büyümesi sorunluydu.)

Ayrıca bu eğitici videoyu inceleyin ....

Paul Randal'ın küçültmenin ve otomatik küçültmenin veritabanınız için nasıl ciddi parçalanma sorunlarına yol açabileceğini göstermesini izleyin http://wtv.watchtechvideos.com/topic194.html