SQLskills.com’un CEO’su Paul Randal’ın ilettiğine göre Transaction Log dosyalarının mimari yapısında bulunan VLF (Virtual Log File)'lerdeki log blokları en fazla 60K'lık veri barındırabilirmiş. Bir gün merak etmiş ve Transaction Log'un mimarisinden sorumlu bölümdeki adamla konuşmuş bu konuyu. Demiş ki, örneğin neden 64K değil de 60K'dır bunun üst sınırı? Adam da "bunun nedenini kimse bilmiyor" demiş, bunun dokümantasyonu yokmuş.
Bir Transaction Log dosyasının içeriğini DBCC LOGINFO komutuyla incelediğimizde raporlanan değerlerden "Status" değeri "0" olursa, bu o VLF'in "inactive" olduğunu, değer "2" olursa VLF'in "active" olduğunu gösteriyor; fakat "1"in ne anlama geldiğini kimse bilmiyor.
TechEd 2014'te “Always On” sunumlarında Senior Program Manager Lead Luis Vargas'ın şöyle bir soruyu: Eğer Primary ile Secondary'ler arasındaki bağlantı koparsa, Primary'de Transaction Log'un şişmesini nasıl engelleriz? sorusunu ilginç bir şekilde cevapladı…
“ Bugün Transaction Log büyümeye devam edecek, çünkü herhangi bir veriyi kaybetmek istemeyiz. Bu nedenle Transaction Log dosyası ancak tüm Secondary'ler ilgili Log'ları aldığında temizlenecektir (Truncate olacak). Örneğin eğer birkaç saatlik bir kesinti olduysa ve Transaction Log doluluğu tehlikeli bir noktaya geldiyse, o zaman ilgili replikaları Availibility Group'tan çıkarabilirsiniz ve bağlantı geri sağlandığında replikaları tekrar eklersiniz. Gelecekte bu Transaction'ları Transaction Log'un dışında başka bir yerde konumlandırmayı düşünüyoruz.”
Kayıtlar
0 comments :
Yorum Gönder