1. Ana Sayfa
  2. Exchange Server 2007
  3. Exchange Server 2007 E-posta Veritabanlarında “Clean Shutdown” ve “Dirty Shutdown” Durumları

Exchange Server 2007 E-posta Veritabanlarında “Clean Shutdown” ve “Dirty Shutdown” Durumları

Exchange Management Console’da bir e-posta veritabanının () durumu “” görünüyorsa öncelikle normal yollardan “” edilmeye çalışılır. Bu sırada hata çıkarsa ve “” edilemezse olay günlüğü, ve araçlarını kapsayan bazı yöntemlere başvurulmalıdır. Bu yazımızda; LOG dizini aşırı büyüdüğü için bağlantısı kopan (dismount olan) veritabanlarının tekrar nasıl bağlanılacağına değineceğiz.LOG dizini taşan veritabanı tekrar bağlanmaya çalışıldığında şuna benzer bir hata ile karşılaşabilirsiniz:

MSExchangeIS (3188) SGYENI0101: The database engine log disk is full. Deleting logfiles to recover disk space may make your database unstartable if the database file(s) are not in a state. Numbered logfiles may be moved, but not deleted, if and only if the database file(s) are in a state. Do not move E:\TESTMBX01\DATA01\E01.log.

MSExchangeIS (3188) SGYENI0101: Unable to create a new logfile because the database cannot write to the log drive. The drive may be read-only, out of disk space, misconfigured, or corrupted. Error -529.

Böyle bir durumla karşılaşıldığında ilk olarak yapılması gereken veritabanının düzgün bir şekilde kapatılıp katılmadığını öğrenmektir. Burada Exchange’in iki önemli kavramına değinmemiz gerekiyor:

  • Clean Shutdown State ( durumu): Eğer düzgün bir şekilde kapanmışsa (dismount olmuşsa) tekrar bağlanması için herhangi bir değişiklik kaydı (log) dosyasına ihtiyaç olmayacaktır.
  • State ( durumu): Eğer veritabanı üzerinde bir işlem yapılırken aniden kapanmışsa genellikle bazı değişiklik kaydı dosyalarının işlenmesinde sorunlar oluşur. Bu da veritabanının tutarsız bir duruma gelmesi demektir.

Öncelikle bağlantısı kopmuş veritabanımızın hangi durumda kapatıldığını öğrenmemiz gerekiyor. Bunun için aşağıdaki ESEUTIL komutunu kullanıyoruz.

eseutil /mh E:\TESTMBX01\DATA01\DATA\DBYENI0101.edb

Komutun çıktısında özellikle de “State” ve “Log Required” alanlarına dikkat edilmelidir:


Resim-1

Eğer Durum (State) alanında “Clean Shutdown” yazıyorsa:

Veritabanınızın düzgün bir şekilde kapatıldığı anlamına gelir. Doluluk sorununu çözmek için bazı değişiklik kaydı (log) dosyalarını gönül rahatlığıyla silebilirsiniz (Silebilirsinizden kastım onları başka bir yere kopyalamanızdır). Hangi log dosyalarını silebileceğiniz ise bir sonraki satırda (Log Required) belirtilmektedir. Gerekli kayıtlar (Log required) dışında kalan değişiklik kayıtlarını silebilirsiniz. Bu alan içinde kalan kayıtları silmeniz ise veritabanında bozulmalara neden olacaktır.

Bu alanda 0-0 yazması demek; o veritabanının başlatılabilmesi için herhangi bir değişiklik kaydı (log) dosyasına ihtiyacı yok demektir. Bu durumda tüm kayıtlar silinebilir (Son kayıt hariç! Bu kaydın silinmesi önerilmez. Genellikle ismi E01, E02 şeklindedir).

Eğer Durum (State) alanında “Dirty Shutdown” yazıyorsa:

Veritabanınızın hatalı bir şekilde kapandığı anlamına gelir. Aşağıdaki ekran görüntüsünde görüleceği üzere veritabanı düzgün kapanmamıştır ve çalışmak için 16015-16030 arasındaki değişiklik kaydı (log) dosyalarına ihtiyaç duymaktadır.


Resim-2

Veritabanı durumunun “Dirty Shutdown” olarak görünmesi, değişiklik kayıtlarının (LOG dosyalarının) veritabanına doğru bir şekilde işlenmediğini gösterir. Veritabanının bozulduğu anlamına gelmemektedir.

Not: İzlenen bu yöntem test ve ürün ortamında denenmiş ve başarılı olmuştur. Ancak bu yöntemi kullanmanızın yine de sizin sorumluluğunuzda olduğunu hatırlatmak isterim.

İşlemlere başlamadan önce veritabanınızı (edb dosyasını) ve tüm değişiklik kayıtlarını (LOG dosyalarını) yedeklemenizi öneririm.

1. Olay görüntüleyicisi (Event Viewer) açılarak veritabanının neden bağlantısının koptuğu araştırılır. Eğer LOG dizinin taşması gibi genel durumlar haricinde özel bir sebep belirtiliyorsa öncelikle bu konuda ayrıca araştırma yapmanızı öneriyorum. Devam eden adımlar sorunun genel çözümüdür.

2. “Log Required” alanında bu veritabanı için gerekli olan kayıtlar (LOG’lar) belirtilmektedir. Eğer daha önceden kayıtların yedeğini almışsanız burada belirtilenleri LOG dizinine kaydetmeniz sorunu çözecektir.

3. Eğer kayıtların yedeği yoksa; LOG dizininde “Log Required” alanında belirtilen isimlere sahip boş kayıtlar oluşturabilirsiniz.

4. “Eseutil /K EXX” komutu ile veritabanınızın, değişiklik kayıtlarınızın ve kontrol noktası (checkpoint) dosyalarının doğruluğunu kontrol edebilirsiniz. Burada EXX olarak belirtilen değer değişiklik kaydı ön ekidir (Log file prefix). Bu değeri veritabanının bulunduğu depolama grubunun (storage group) özelliklerinde görebilirsiniz.


Resim-3

5. “Eseutil /R EXX” komutu ile kayıtların tekrar veritabanına işlenmesini (replay transaction log files) sağlayabilirsiniz.Bu işlemden sonra veritabanını tekrar bağlamanızı deneyin. Eğer hala bağlanmıyorsa aşağıdaki adımlara devam edebilirsiniz.

6. “Eseutil /G veritabaniadi.edb” komutu ile ESE seviyesinde ve mantıksal anlamda veritabanı kontrolü yapabilirsiniz.

7. “Isinteg -fix” komutu ile veritabanı uygulama seviyesinde denetlenir ve varsa hatalar düzeltilir.

8. Eğer tüm bu adımları uyguladığınız halde sorun çözülmediyse (ki bu düşük bir ihtimaldir) veritabanınızı onarmayı veya yedekten dönmeyi deneyebilirsiniz.

Not 1: Yukarıda belirtilen şartlar dışında, değişiklik kaydı (log) dosyalarına elle müdahala etmekten kaçınılmalıdır. Çünkü yanlış bir müdahale veritabanı üzerinde kalıcı hasarlara neden olabilir.

Not 2: Şarlar sağlandığı durumlarda dahi değişiklik kayıtları kalıcı olarak silinmemelidir. Mutlaka bir yere yedekleri alındıktan sonra silinmelidir.

Not 3: Tüm değişiklik kayıtlarını silebileceğiniz durumlarda dahi en son kaydı tutmanız gerekir.

Yapılan işlemler sonrasında veritabanı bağlandı. Ancak CCR (veya LCR) düğümleri arasındaki kopyalama başarısız (Failed) olarak görünüyor?

Veritabanı bağlama işlemi başarıyla tamamlanmasına rağmen aktif-pasif sunucular arasındaki eşleme başarısız olabilir. Bu durumda ilgili veritabanı için “Copy Status” alanı “Failed” olarak görünecektir. Bu sorunu çözmek için aşağıdaki komut uygulanabilir. Bu komutta yapılan işlem; aktif ve pasif kopyalar arasındaki eşlemeyi tetiklemektir.
Not: Bu komut çalıştırılmadan önce (storage group) üzerine sağ tıklanır ve “Suspend Storage Group Copy” denir. Aksi takdirde komut hata verecektir. Ayrıca komutun pasif sunucu üzerinde çalıştırılması gerekmektedir.

Update-StorageGroupCopy -Identity TESTMBX01\SGYENI0101 -DeleteExistingFiles

Bu komut uygulanırken “DeleteExistingFiles” parametresi unutulmamalıdır. Bu parametrenin görevi; eğer pasif sunucudaki kayıtların aynıları varsa bunları silmektir. Daha sonra eşleme tekrar yapılacağı için bu kayıtların silinmesi herhangi bir soruna neden olmayacaktır.

Bu konuyla ilgili sorularınızı https://forum.mshowto.org linkini kullanarak ulaşacağınız forum sayfamızda sorabilirsiniz.

Referanslar

Update-StorageGroupCopy

Update Storage Group Copy Wizard

How to Seed a Cluster Continuous Replication Copy

Eseutil aracı hakkında

Isinteg aracı hakkında

How to remove Exchange Server transaction log files

Yorum Yap

Yazar Hakkında

2008 yılında Erciyes Üniversitesi Bilgisayar Mühendisliğinden birincilikle mezun oldu. Türkiye'nin en büyük kurumlarından birisinde Mesajlaşma Sistemleri üzerine çalıştı ve halen aynı kurumda Veri Merkezi Planlama ve Mimari Yönetimi konusunda görevini sürdürmektedir. Exchange Server 2010 ve Windows Server 2008 R2 SP1 kitaplarının yazarıdır. Bu ürünler hakkında MCITP sertifikasına sahiptir. Sistem ile ilgili çalışmalarının yanı sıra 60'dan fazla web sitesinin tasarımını yapmıştır.

Yorum Yap

Yorumlar (1)

  1. 9 sene önce

    profosyonelce yazılmış bir makale
    teşeküürler