Dizin yeniden organize edilirken işlem günlüğünün dolu olması nasıl önlenir?

İşlem günlüğünün boyutunu önceden 50 gb'ye ayırdığımız birden fazla makinemiz var. Yeniden düzenlemeye çalıştığım tablonun boyutu 55 - 60 gb, ancak sürekli artacak. Yeniden düzenlemek istediğim temel sebep, alanı geri kazanmak ve herhangi bir performans avantajından dolayı bir avantaj.

Tablonun parçalanma seviyesi% 30 - 35'tir. Bu makinelerin bazılarında "işlem günlüğü dolu" hatası alıyorum ve yeniden düzenleme başarısız oluyor. İşlem günlüğü boyutu 48 gb'a kadar ulaşır. Buna karşı koymanın iyi bir yolu nedir? Otomatik artışımız açık değil ve bunu yapmakta isteksizim.

Günlük boyutunu daha büyük bir değere artırabilirim, ancak tablo boyutu gelecekte arttıkça değer yeterli olmayabilir. Ayrıca, günlük boyutunu eşit olarak artıracaksam, alanı geri kazanmak için yeniden düzenleme yapmayı amaçlamaktadır. Buna nasıl etkili bir şekilde karşı koyabileceğim hakkında bir fikrin var mı? Veri kaybı kabul edilemez olduğundan, toplu modu kullanmak bir seçenek değildir.

En iyi uygulama , REORGANIZEyaklaşık% 30'luk parçalanmanın altında ve bunun REBUILDüzerindedir. Basitçe, REBUILDtemiz bir kopya oluşturur, REORGANIZEyerinde yapar.

Gerçekte ne yaptığınızı kontrol edin: İkisini de yapan bir bakım planınız yok mu?

Daha büyük tablolarda (50GB tablo oraya geliyor) REORGANIZEBu kurala uyursanız, tüm işlem günlüğü alanını tükettiğini gördüm . Sık değil: belirli bir yük modeline sahip tek bir sistem. REORGANIZELog kadar sadece koştu genişletilmiş ve tüm disk alanını tükettiler.

Biz geçti REBUILDartık sorunları ile yerine ancak% 25'in altına parçalanması görmezden geldi. Bu bizim için daha iyi çalıştı: sizin için işe yarayıp yaramadığını görmek zorundasınız.

REBUILDperformansı REORGANIZEüretimdekinden daha fazla etkileyebilir , ancak bu bazen ONLINEseçenekle azaltılabilir (Enterprise Edition gerekir).

Yeniden DÜZENLEME günlüğünün az miktarda gerektiren çok hızlı operasyon (iyi ... çoğunlukla,) 'dir, (alter INDEX ... yeniden DÜZENLEME olduğu gibi), her an kesildi ve daha sonra kaldığı yerden devam ve dahili işler edilebilir küçük toplu işlemler :

birleştirme bir dizi kısa işlem olarak gerçekleştirilir, bu nedenle günlük yedekleri sık sık alınırsa veya kurtarma modeli ayarı BASİT ise büyük bir günlük gerekmez.

Bir yeniden yapılanmadan bahsetmediğinizden emin misiniz ? REBUILD dizini yavaş, pahalıdır, çok sayıda günlük tüketir (çevrimdışı değilse ve en az günlüğe kaydedilemiyorsa , çevrimiçi yeniden oluşturma en az günlüğe kaydedilemez), tek bir dev işlemdir ve tüm işi kaybetmeden kesilemez.

Bana öyle geliyor ki, çok iyi düşünülmüş bir nedeniniz olmadıkça yapmamanız gereken gerçekten olağanüstü bir işlem. Ne tür bir alan geri almayı umuyorsunuz? İşe yaramayacak bir şey var DBCC CLEANTABLEmı? Tablo fiziksel yapısını kontrol ettiniz mi, mantıksal yapıdan mı sürüklendi ( ayrıntılar için başlık altındaki SQL Server tablo sütunlarına bakın)?

Eğer varsa gerçekten tablosunu yeniden zorunda o zaman başka seçeneğim yok ama kabullenmesini ve gerekli günlüğünü tahsis korkuyorum. Otomatik olarak büyümesine izin verme, sadece işlemi yavaşlatır. Tablonun 2.5 katına kadar büyütün.

Tablo bölümlenmişse, her seferinde bir bölümü çevrimdışı olarak yeniden oluşturabilir (ve yeniden düzenleyebilirsiniz). Çevrimiçi yeniden oluşturma yalnızca tüm tablo düzeyinde yapılabilir.

Bu sorunu daha önce yaşadım.

• Büyük bir veritabanınız ve küçük bir günlük sürücünüz var. Yeniden düzenlemek istiyorsunuz (çeşitli nedenlerle).
• Bunu büyük bir parçalanmış tabloda denediğinizde, günlük, günlük sürücüsü dolana ve komut iptal edilene kadar dolar.
• Basit moddaysa, günlük bir sonraki kontrol noktasında temizlenene kadar diğer işlemler başarısız olabilir ve tam modda ise diğer işlemler bir sonraki günlük yedeklemesine kadar başarısız olabilir. Kesinti!
• Tam moddaysanız günlük yedekleme sıklığınızı artırırsınız, ancak yeniden yapılanma örtük bir işlemde yapıldığı için sorunun önlenmesine yardımcı olmaz, bu işlem bitene veya iptal edilene veya durdurulana kadar günlük temizlenmez.
• Ve GERÇEKTEN bu yeniden düzenlemenin tamamlanmasını istiyorum.

Bu biraz karşı-sezgisel çünkü yeniden düzenlemeyi bıraktığınızda kaldığı yerden devam edebilir, biliyorsunuz sadece geri alma yerine işlemi iptal ediyor.

İşte yaptıklarınız. Biraz uzun ama anlaşılır.

• Günlük dosyanızı nispeten büyük bir boyuta getirin, ancak en fazla değil. Temel olarak, yararlı işler yapmak için yeterli alan bırakmak ve ayrıca bazı küçük büyümeler için ortaya çıkarlar, böylece normal işlemler durmaz.
• Dizininizi yeniden düzenlemek için bir iş oluşturun ('Yeniden Düzenle').

• Performans koşulunda bir aracı WMI uyarısı ('Emniyet Valfini Yeniden Düzenleyin') oluşturun.

  • Nesne: SQLServer: Veritabanları
  • Sayaç: Kullanılan Günlük Yüzdesi
  • Eşgörünüm: (büyük veritabanı adınız)
  • Sayaç yukarı çıkarsa uyarı: 80
  • Yanıt: İşi yürütün ('Çeki Yeniden Düzenle')

• Bir iş oluşturun ('Çeki Yeniden Düzenle')

  • İşte 'Yeniden Düzenle' işinin çalışıp çalışmadığını görmek için msdb.dbo.sysjobactivity'yi kontrol edin. Ve eğer öyleyse ...
  • İşi durdurun ve durana kadar yoklayın. Bu birkaç saniye sürebilir.
  • (Tam moddaysanız) Günlük yedekleme işinizi tetikleyin ve bittiğinde onaylayın.
  • Sys.dm_os_performance_counters'da, günlük boş alan sayacınızın eşiğin altında azaldığını kontrol edin.
  • 'Yeniden Düzenle' işini başlatın.

• Üretim sunucunuza yapıştırmadan önce düzgün çalıştığından emin olmak için bunu bir yerde, hatta bir geliştirme sanal alanında test edin.

Göreceğiniz şey, 'Yeniden Düzenle' işi başlar ve günlüğü doldurmaya başlar. Günlük yüzde dolmuşsa, 'Yeniden Düzenle' işinin çalıştığını ve büyük olasılıkla hatalı olduğunu gören diğer işinizi çalıştıran WMI uyarısını (yaklaşık 30 saniye içinde) tetikler. Daha sonra 'Yeniden Düzenle'yi durdurur, bir yedekleme yapar, günlük boş alanın makul bir değere döndüğünü doğrular, ardından' Yeniden Düzenleme 'işinizi tekrar kaldığı yerden alır.

Bu nedenle, günlüğünüzü bu senaryoda makul bir şekle göre önceden boyutlandırmanızın nedeni, daha verimli olabilmesi ve ayrıca daha verimli olabilmesi için büyüme / tetikleyici / iş / durdurma / yeniden başlatma sayısını azaltmaktır. zaman içinde yakalanmayan nadir büyüme.

Bu bir çeşit garip senaryo. Birkaç yıl önce bunu başaracağımdan eminim ve burada temeldeki temel sorunlar var. Ancak yüzlerce sunucuyla ilgilenirseniz, MacGyver'in işi yapan geçici bir çözüm haricinde, iş nedenlerinden ötürü, herhangi bir şekilde ele alınamayan birkaç uç vaka ortaya çıkacaktır.

Güvenli, mantıklı, test edilmiş ve iyi belgelenmiş olduğu sürece sorun olmamalıdır.

İndeks reorg için genellikle yaptığım şeydir (ayrıca her biri 80 + GB büyüklüğünde birkaç tablom var) (çünkü indeks reorg önceki reorg çalışmasını kaybetmeden herhangi bir zamanda durdurulabilir).

1. İndeks yeniden yapılandırması sırasında tlog yedeklemesini normal 30 dk frekansımdan her 10 dk frekansa yükseltirim
2. Her 1 dakikada bir tlog boş alan denetimi yapan başka bir oturum var ve tlog boş alan bir eşiğin altındaysa, dizin yeniden oturumunu durdurur ve tlog yedeklemesini başlatır (veya bekler). Sonra yeniden dizin indeksini yeniden başlatın.

Dizin bakım çerçevemde, dizinleri iki gruba ayırıyorum, biri dizin yeniden oluşturma, diğeri dizin yeniden oluşturma içindir. Dizin yeniden oluşturma için, ben bir dizin yeniden oluşturma oturumu durdurmak istemiyorum çünkü biraz farklı bir yaklaşım kullanacağım (bir geri alma neden olur ve önceki tüm çalışmalarını kaybeder). Dizin yeniden oluşturma sırasında, izleme oturumumda kullanılan bir tlog dosyası boş alanı senaryosu fark ederse, izleme oturumu tlog dosyasını otomatik olarak önceden artıracaktır ve en kötü senaryoda (yani disk dolu), izleme oturumum başka bir günlük dosyası ( ancak daha sonra başka bir sürücüye (yedek sürücü) bırakacağım

Soru yazarı ile aynı sorunu yaşadım ve yorumlarına baktığımda aynı düzene sahip olduğumu söyleyebilirim. Bir şey yapmaya çalışırken REORGANIZE, günlük, boyuttan bağımsız olarak, tüm tablonun boyutunun birden çok katına kadar büyür.

Sorun, işlem çoğaltmasından kaynaklandı . Görünüşe göre, REORGANIZEişlem tamamlanana kadar günlük yedeklenemez . Bir yerde Microsoft tarafından bilinen bir sorun olduğunu okudum, ama nerede olduğundan emin değilim.

İşlem çoğaltmasını devre dışı bıraktığımda, günlük yedekleri yeniden normal şekilde çalıştı ve yeniden düzenleme yaparken her 30 saniyede bir günlük yedeklemeleri yaptım.

Ben çizgileri boyunca bir şey çalıştırdığınız varsayıyorum:

REORGANİZE İLİŞKİN ALTER INDEX

Ne yazık ki, kısmi bir düzenleme çalıştırmanın bir yolu yoktur (örneğin, bir günlük dosyasını kısmen küçültme yolu). Bu sorunları düşünebileceğim yollar:

1) yeniden düzenlemeyi çalıştırırken veritabanını basit kurtarma moduna ayarlayın, ancak bunun kabul edilemez olduğunu söylediniz

2) dizini bölümleme - yaklaşık olarak eşit boyutlu bölümler elde etmek için dizini bölümleme yolunu düşünebilirseniz, her bölümü bağımsız olarak yeniden düzenleyebilir (veya çevrimiçi seçenekle yeniden oluşturabilirsiniz) ve böylece günlük dosyası büyümesini sınırlayabilirsiniz

Bunu yaptığınızdan eminim, ancak değilseniz, kullanılan alanı geri kazanmasına izin verecek herhangi bir dizin optimizasyonu yapmadan önce ve sonra bir günlük dosyası yedeklemesi başlatmak isteyebilirsiniz.