Transaction Log Dosyasını Küçültmek

Merhaba

http://sqlblogcasts.com/blogs/davidwimbush/archive/2010/03/04/log-shipping-and-shrinking-transaction-logs.aspx

Öncelikle yanıtınız için teşekkür ederim Hakan bey.

Ben amatörce bir çözüm olarak şöyle yaptım:

1. Mirror'ı iptal et,
2. Recovery Mode'u Simple yap,
3. Transaction Log dosyasına Shrink uygula,
4. Mirror yapısını tekrar oluştur.

Keyifsiz bir çözüm oldu ama hiç olmazsa dolmak üzere olan diskin sorununu çözdü (aslında erteledi).

Benim beklentim bir SQL sorgusu (yada otomatikleştirilebileck başka bir yöntem) yardımıyla belirli periyotlarla bu küçültme işlemini otomatikleştirmek.

Verdiğiniz linkteki tekniği anlamaya çalıştım ama çözemedim Hakan bey [:(] Rica etsem anlatmaya çalıştığı adımları açabilir misiniz?

Konu ilgimi çektiği için transaction log mantığının çalışması açısından ben de tecrübelerinizden feyz almak için şunu sormak isterim.

Şimdi transaction logda database ile ilgili bütün işlemler tutuluyor. Eğer FULL ise büyüme sorunu var bu doğru, fakat FULL den hiç vazgeçemedim belki de korktum. burada anlamak istediğim şu,

yapılacak işler önce transaction loga yazılıyor, ondan sonra asıl database e yazılıyor, benim bildiğim bu yanlışsa düzeltin lütfen?

1.Transaction log FULL özellikli olarak tutuluyorsa database de yapılan işlemlerle ilgili bütün bilgiler tutuluyor, bunu Simple a cevirdiğiniz anda transaction logdan database e aktarılan bütün bilgiler gereksiz olacağı için loglardan siliniyor diyebilirmiyiz? Yani bu işlem için veri kaybı yaşamadığınıza göre böyle çalışmalı gibi yanlışmı düşünüyorum, yanlışmıyım?

2.Transaction log simple olarak tutulursa o zaman son yapılan birkaç işlemin mi logu tutulacak sadece?

3.Shrink işlemini FULL modda çalışmaya devam ederken de yapsaydınız bir faydası olmayacakmıydı, daha doğrusu shrink in simple moda çevirme işleminden farkı nedir tam olarak?

Konu ilgimi çektiği için transaction log mantığının çalışması açısından ben de tecrübelerinizden feyz almak için şunu sormak isterim.

Şimdi transaction logda database ile ilgili bütün işlemler tutuluyor. Eğer FULL ise büyüme sorunu var bu doğru, fakat FULL den hiç vazgeçemedim belki de korktum. burada anlamak istediğim şu,

yapılacak işler önce transaction loga yazılıyor, ondan sonra asıl database e yazılıyor, benim bildiğim bu yanlışsa düzeltin lütfen?

1.Transaction log FULL özellikli olarak tutuluyorsa database de yapılan işlemlerle ilgili bütün bilgiler tutuluyor, bunu Simple a cevirdiğiniz anda transaction logdan database e aktarılan bütün bilgiler gereksiz olacağı için loglardan siliniyor diyebilirmiyiz? Yani bu işlem için veri kaybı yaşamadığınıza göre böyle çalışmalı gibi yanlışmı düşünüyorum, yanlışmıyım?

2.Transaction log simple olarak tutulursa o zaman son yapılan birkaç işlemin mi logu tutulacak sadece?

3.Shrink işlemini FULL modda çalışmaya devam ederken de yapsaydınız bir faydası olmayacakmıydı, daha doğrusu shrink in simple moda çevirme işleminden farkı nedir tam olarak?

Önce transaction log'a yazılıp sonra veritabanına yazılma değil de tersi geçerli olmalı bence yani önce veritabanı sonra log çünkü düşünün log'a yazıldı ama tam veritabanına yazma anında veriye göre işlemi iptal eden bir sp çalıştırılırsa sorun yaşarsınız. Önce veritabanı sonra log daha mantıklı (ama doğrusunu araştırmak lazım yine tabi).

1. Simple çevirdiğiniz anda tüm bilgiler silinmez; önce log dosyasını (sadece data'yı yapmak da yetmez[:)]) shrink yapmalısınız. Bu durumda log dosyanız küçülür ve içindeki eskiye dönük işlemler silinir.

2. Transaction log dosyası simple olarak saklanmaz. Ya tutuluyordur ya da yoktur [:)] Simple olması ise backup'tan geri yüklenebildiğini ifade etmek içindir (yani bir nevi kurtarma var demek9.

3. Shrink işlemini Full modda yaparsanız Data'da ve Log'da az miktardfa küçülme olur ama ifade etmeye çalıştığınız gibi az olmaz kesinlikle. Bunun için Simple->Shrink->Full adımını izlemelisiniz. Eğer bu adımı izlerseniz GB'lık dosyanızın KB'a düştüğünü görürsünüz ama tüm loglar gittiği için geri dönüş şansınız olmaz. Bu yüzden bu işlemden önce backup almanızı öneririm.

Başka aklınıza gelen sorular varsa elimden geldiğince cevaplamaya çalışırım. 

İyi çalışmalar.

Merhaba

Konu ile ilgilendiğim için yeni okudum ve cevap yazma ihtiyacı duydum.

Mert Beyin de dediği gibi database, önce geçici olan tmp dosyasına, sonra veritabanına yazılır. aynı zamanda da logları tutulur.

İyi çalışmalar

merhabalar arkadaşım.bende etkin olarak mirroring ve clustering hizmetlerini kullanan biriyim. Mirroring de maalesef transaction loga direk müdahale edemezsin. sebebi mirror instanceının recovery modda olmasıdır. ve sakın mirrorı veya logu direk shrink etmeye çalışma ki dbnin recovery moddan birdaha çıkamaması gibi bir duruma girme:)

Yapman gereken çok basit. Belli bir interval ile transaction log backup aldır. log backup ı aldırdığın anda transaction log otomatik olarak back up ın alındığı son LSN numarasına kadar shrink edilmiş olacaktır. sonra istersen bu backupları silebilirsin.

 Kolay gelsin.

Merhaba arkadaşım;

 öncelikle şunu anlatmalıyım. mssql de x bir transaction çalıştırdığınız zaman yapmak istediğiniz işlem ve bununla alakalı tüm dataset tempdb aracılığı ile dbye ve transaction loga aaynı anda yazılır. bu arada fiziksel olarak ayrı iki dosya gibi dursada (.mdf ve .ldf) engine içinde tek bir dosya gibi host edilir ve işlenir.

her hangi bir dbyi simple moda da çekseniz full modda da kalsa yapılan her transaction için bir kayıt tutulur ki transaction tamamlanmadan servisin durması gibi bir durum söz konusu olursa servis yeniden çalıştırıldıktan sonra db recovery modda açılır ve transaction logda en son neyi işlediğini görüp o transactionı kaldığı yerden rollback eder. ama transaction sorunsuz bir şekilde tamalanırsa simple mode da olan db tanımlanan boyuttan büyük ise auto shrink eder ve tanımlanan boyutun altında minimum değere indirir.(tanımlanan boyut diye bahsettiğim şey ise db özelliklerinden transaction logun maximum ne kadar büyüyebileceğini ayarladığınız boyut) 

 full mode da ise transaction logu asla auto shrink etmez. Ama elle shrink edebilirsiniz. yada transaction log back up ile shrink edebilirsiniz. transaction log LSN numaraları ile her transaction logu bir unique ID ye bağlar yani her transactionın bir numarası vardır. back up ı başlattığınız anda işlenmiş son LSN i bulur ve ilk LSN ile son LSN arasındaki tüm transactionların *.trn uzantılı bir backupunı alır ve LDF ten siler.En güvenli shrink metodu budur.

 mirroring veya log shipping yapıları itibarı ile transaction loglara ihtiyaç duyulan hizmetler olduğundan loglar auto shrink veya manuel shrink edilmezler. fakat transaction log back upları alınarak shrink etmeleri sağlanmalıdır.  Dolayısıyla herhangi bir sorun gerçekleştiğinde dblerin recovery modda olması sonucu son trn loglar restore edilerek kurtarma gerçekleştirilebilinir. aksi taktirde dbnize elveda diyebilirsiniz.[:D]

 bu arada mirrorin veya logsipping yapılan dblerin simple modda olması söz konusu bile olamaz.

Önemli Dipnot::: arkadaşlar siz bir dost tavsiyesi. dbniz gerçekten önemli bir db ise ve çok düzgün bir index yapısı ve maintenence ı varsa asla datayı shrink etmeyin. Çünkü çalıştırdığınız shrink işlemi hemen hemen tüm indexlerinizi fragmante edeceğinden lock süreleriniz ve sayıları uzar ve sorgularınız uzun sürmeye başlar ve yazma işlemleri çok ise timeout bile almaya başlarsınız.(bkz. index fragmantation)

her neyse

[:D]

onur eray

   SQL Server'da log shipping
ile db'lerinin yedekleri alındığında, primary db tarafında yapılan bazı
işlemler transaction log dosyasını çok büyütüyor. Bu db'lerin log dosyaları çok
büyüdüğünde, log shipping  kırılmadan log dosyasının boyutunu azaltmak
için

   DBCC SHRINKFILE (  Database_log_file_name , NOTRUNCATE)

ifadesi kullanılıyor. Burada NOTRUNCATE
kısmına özellikle dikkat edilmeli. Bazı formlarda NOTRUNCATE ile boyutun
değişmediği ifadeleri hatalıdır. Çünkü truncate ile shrink farklıdır ve burada
truncate yapılmadan shrink işlemi söz konusudur.

   Bu ifade
çalıştırıldıktan sonra log dosyası ilk seferde istenen boyuta düşmeyebilir. Bu
durumda bu ifade çalıştırıldıktan sonra log shipping için backup, copy ve
restore işlemleri yapıldıktan sonra tekrar yukarıdaki ifade çalıştırıldığında
log dosyasının boyutu düşer. Bazen bu işlemi birkaç kez yapmak gerekebilir.

Örnek olarak iki ayrı db’de ki, uygulama
sonuçlarını aktarıyorum.

   AA db’inde

- ilk çalıştırıldığında log dosyası 6,8 GB
civarındaydı.

- log shipping backup, copy, restore
işlemleri yapıldıktan sonra yukarıdaki ifade 2. kez çalıştırıldığında 1,9 GB

- log shipping backup, copy, restore
işlemleri yapıldıktan sonra yukarıdaki ifade 3. kez çalıştırıldığında 1,7 GB

- log shipping backup, copy, restore
işlemleri yapıldıktan sonra yukarıdaki ifade 4. kez çalıştırıldığında 1 GB
oldu.

  BB
db’inde 50 GB civarında log dosyası vardı. Yukarıdaki ifade ilk kez
çalıştırıldığında 39 GB'a indi. Sonra log shipping için backup, copy, restore
işlemleri yapıldıktan sonra tekrar çalıştırıldığında 1GB oldu. Bu işlemler
sırasında Log shipping’te kırılma olmadı ve secondary db'nin log dosyası
primary db log dosyasıyla aynı boyuta gelmekte.

Bu işlemler SQL Server 2005’de yapılmıştır. 

Mehmet Emin Şahin