Microsoft Exchange Server Add Database Copy ve Circular Logging Hatası

Microsoft Exchange Server Add Database Copy ve Circular Logging Hatası, Exchange Server’da Database Availability Group (DAG) yapısına yeni bir veritabanı kopyası eklerken, kopyalama işleminin başlamaması veya seeding aşamasında hata vermesiyle karşılaşabiliriz. Bu süreçte kontrol edilmesi gereken ayarlardan biri Circular Logging, yani döngüsel günlük kaydıdır.

Bu yazıda, Archive04 isimli veritabanına kopya ekleme sırasında karşılaşılan hata mesajlarını, veritabanı ve transaction log kontrollerini, Circular Logging ayarının etkisini ve uygulanabilecek çözüm adımlarını ele alacağız.

Vakadaki ekran görüntülerinde iki farklı hata bulunuyor.

Bunlardan biri doğrudan Circular Logging ayarına işaret ederken, diğeri ESE katmanından dönen daha genel bir hatadır. Doğru teşhis için bu iki mesajı ayrı değerlendirmek gerekir.

Vakanın kapsamı: Ekran görüntüleri hata mesajlarını, inceleme adımlarını ve seeding işleminin başladığını gösteriyor. Ancak kopyanın son durumda Healthy olduğunu gösteren bir ekran bulunmuyor. Bu nedenle işlemin başarıyla tamamlandığını ayrıca doğrulamak gerekiyor.

Microsoft Exchange Server Add Database Copy ve Circular Logging Hatas makalesi içinde aşağıda ki konu başlıklarını ve çözümlerini inceliyoruz.

1. Problem nedir?

Exchange Admin Center üzerinden Add database copy işlemi gerçekleştirildiğinde aşağıdaki uyarıyla karşılaşılmaktadır:

Görsel açıklaması: Archive04 veritabanında Circular Logging etkin olduğu için veritabanı kopyası eklenemediğini belirten hata.

Mesaj, veritabanında Circular Logging etkin olduğunu ve kopya ekleme işleminden önce bu özelliğin devre dışı bırakılması gerektiğini söylüyor.

Buradaki kritik ayrıntı, ilk pasif kopyanın oluşturulmasıdır.

Microsoft’un dokümantasyonuna göre tek kopyalı bir veritabanına ilk pasif kopya eklenirken Circular Logging kapalı olmalıdır.

Veritabanı çoğaltılan bir yapıya geçtikten sonra kullanılan mekanizma CRCL olur; üçüncü ve sonraki kopyalar eklenirken CRCL açık kalabilir. Microsoft Learn — Add a mailbox database copy

Dolayısıyla bu hata, tek başına veritabanının bozuk olduğunu göstermez. İşlem için gerekli yapılandırma koşullarından birinin sağlanmadığını gösterir.

1.1 Aynı süreçte görülen diğer hata

Microsoft’un ESE hata tablosunda -1305, JET_errObjectNotFound olarak tanımlanır: İstenen tablo veya nesne bulunamamıştır. Ancak bu kod, tek başına Circular Logging’in hataya neden olduğunu kanıtlamaz

Bu ekranda aşağıdaki ifade görülmektedir:

Tam hata metni ve aynı zamana ait olay kayıtları birlikte incelenmelidir. Microsoft Learn — Extensible Storage Engine Error Codes

Bu vakada Circular Logging engeli açıkça görülmektedir; -1305 hatasının aynı kök nedene bağlı olup olmadığı ise mevcut görüntülerden kesinleştirilemez.

2. Circular Logging nedir, neden bu hataya yol açar?

Exchange Server, veritabanı işlemlerini transaction log dosyalarına kaydeder. Bu dosyalar veritabanı kurtarma işlemlerinde ve DAG içindeki kopyaların güncel tutulmasında kullanılır.

Normal günlük yönetiminde, gerekli koşullar sağlandığında artık ihtiyaç duyulmayan loglar temizlenir.

Circular Logging, uygun logların yeniden kullanılmasını veya temizlenmesini sağlayarak log alanının sınırsız büyümesini önlemeye yardımcı olur. Ancak geçmiş logların tutulmasını sınırladığı için kurtarma ve yedekleme tasarımını da etkiler.

Exchange’te iki farklı uygulama vardır:

İlk pasif kopya oluşturulurken tek kopyalı yapıdan çoğaltılan yapıya geçildiği için Circular Logging’in önce kapatılması gerekir. Tek kopyalı veritabanında yalnızca kutucuğun işaretini kaldırmak yeterli değildir; değişikliğin uygulanması için veritabanının dismount ve ardından mount edilmesi gerekir. Microsoft Learn — Configure circular logging

Circular Logging’in neden açık olduğu ise ekran görüntülerinden anlaşılamıyor. Disk alanı yönetimi, önceki bir bakım işlemi veya mevcut veri koruma tasarımı nedeniyle etkinleştirilmiş olabilir. Bunlar olasılıktır; bu vakada doğrulanmış nedenler değildir.

Exchange Server Mailbox Database Circular Logging konu başlığında hazırlamış olduğumu makale ve blog yazısında detaylı bilgilere sahip olabilirsiniz.

3. İlk inceleme: Veritabanının durumunu kontrol etmek

Kopyalama hatasıyla karşılaşıldığında doğrudan onarım işlemine geçmek yerine, önce veritabanının ve kopyaların mevcut durumu belirlenmelidir.

Exchange Management Shell üzerinde şu kontroller yapılabilir:

Copy to Clipboard
Syntax HighlighterGet-MailboxDatabase -Identity "Archive04" -Status | Format-List Name,Server,Mounted,CircularLoggingEnabled,EdbFilePath,LogFolderPath

Bu çıktılar şu soruları yanıtlamaya yardımcı olur:

• Veritabanı hangi sunucuda aktif?
• Veritabanı mounted durumda mı?
• Circular Logging açık mı?
• Hedef sunucuda daha önce oluşturulmuş bir kopya var mı?
• Kopyalama veya replay kuyruğunda birikme var mı?

3.1 ESEUTIL ile başlık kontrolü

Vakada veritabanı başlığını incelemek için şu komut kullanılmıştır:

Copy to Clipboard
Syntax Highlightereseutil /mh "Z:\Archive04\Archive04.edb"

Archive04 veritabanı başlığında Clean Shutdown ve Log Required: 0-0 bilgileri.

Görüntüde şu alanlar dikkat çekmektedir:

Copy to Clipboard
Syntax HighlighterState: Clean Shutdown Log Required: 0-0

Clean Shutdown, incelenen veritabanının düzgün kapatılmış durumda olduğunu gösterir. Log Required: 0-0 ise bu başlık durumuna göre kurtarma için gerekli bir log aralığı belirtilmediğini gösterir.

Bununla birlikte bu çıktı:

• Tüm veritabanı içeriğinin sağlamlığını kanıtlamaz.
• DAG çoğaltmasının sağlıklı olduğunu göstermez.
• Circular Logging yapılandırma hatasını çözmez.

eseutil /mh kontrolü, ilgili veritabanı dosyası çevrimdışıyken veya uygun bir çevrimdışı kopya üzerinde yapılmalıdır. Canlı veritabanını incelemek için önce Exchange yönetim komutları tercih edilmelidir.

Exchange Mailbox Database Offline Defragmentation makalesi içinde Microsoft Exchange Server için eseutil aracının nasıl kullanılması gerektiğini sizlere paylaşmıştık.

4. Transaction log klasörünü incelemek

Eseutil aracı ile yapmış olduğumuz ilk inceleme sırasında Archive04Logs klasöründeki transaction log, checkpoint ve reserve log dosyalarının detaylarını görmektesiniz.

Görüntüde aşağıdaki dosya türleri bulunmaktadır:

Log dosyaları incelenirken yalnızca dosya sayısına bakmak yeterli değildir. Dosyaların hangi sunucuda bulunduğu, ait oldukları log akışı, nesil sırası, tarihleri ve kopya durumu birlikte değerlendirilmelidir.

Clean Shutdown görülmesi, log klasöründeki dosyaların topluca silinebileceği anlamına gelmez. Başka bir kopyanın, yedekleme sürecinin veya kurtarma işleminin bu dosyalara ihtiyacı olabilir.

Bu vakada da ekran görüntülerinden hareketle manuel log silme işlemini standart çözüm olarak önermek doğru değildir.

5. ÇözümCircular Logging’i kapatmak ve değişikliği uygulamak

5.1 İşlem öncesi koşulları doğrulayın

İlk pasif kopyayı eklemeden önce:

• Kaynak ve hedef sunucuların aynı DAG içinde olduğunu doğrulayın.
• DAG ve quorum durumunu kontrol edin.
• Aktif veritabanının mounted olduğunu doğrulayın.
• Hedefte veritabanı ve log yollarının uygunluğunu kontrol edin.
• Veritabanı, log büyümesi ve seeding süreci için yeterli boş alan bulunduğundan emin olun.
• Yedekleme ve geri dönüş olanaklarını kontrol edin.

Bu koşullar, kopya ekleme işleminin temel ön koşullarıdır. Microsoft Learn — Add a mailbox database copy

5.2 Circular Logging’i devre dışı bırakın

Exchange Admin Center üzerinden:

• Servers > Databases bölümüne gidin.
• Archive04 veritabanını seçin.
• Düzenleme ekranında maintenance bölümünü açın.
• Enable circular logging seçeneğinin işaretini kaldırın.
• Değişikliği kaydedin.

Archive04 veritabanının maintenance ekranında Circular Logging seçeneğinin işaretsiz olduğunu görmektesiniz.

Aynı işlem Exchange Management Shell ile yapılabilir:

Copy to Clipboard
Syntax HighlighterSet-MailboxDatabase -Identity "Archive04" -CircularLoggingEnabled $false

Ardından ayarı kontrol edin:

Copy to Clipboard
Syntax HighlighterGet-MailboxDatabase -Identity "Archive04" | Format-List Name,CircularLoggingEnabled

Beklenen değer:

Copy to Clipboard
Syntax HighlighterCircularLoggingEnabled : False

5.3 Tek kopyalı veritabanında dismount ve mount uygulayın

İlk pasif kopya eklenmeden önce kullanılan JET Circular Logging ayarının değişmesi için veritabanı yeniden bağlanmalıdır.

Bu işlem sırasında ilgili veritabanındaki posta kutularına erişim kesilir. İşlemi planlı bakım aralığında uygulayın.

Copy to Clipboard
Syntax HighlighterDismount-Database -Identity "Archive04"
Copy to Clipboard
Syntax HighlighterMount-Database -Identity "Archive04"

Dismount komutunun onay istemini değerlendirerek devam edin. Bu işlem için tüm Information Store servisini yeniden başlatmak yerine ilgili veritabanının dismount/mount edilmesi yeterlidir. Microsoft Learn — Configure circular logging

Adım 4 — Olay kayıtlarını kontrol edin

ESE Event ID 105 — Archive04 için veritabanı motorunun yeni bir instance başlattığını gösteren kayıt.

ESE Event ID 326 — Archive04.edb dosyasının veritabanı motoruna bağlandığını gösteren kayıt.

Bu olaylar, görüntülerde belirtilen veritabanı motoru başlatma ve attach işlemlerini gösterir. Ancak Circular Logging ayarının kapalı olduğunu veya pasif kopyanın sağlıklı olduğunu tek başlarına kanıtlamazlar.

Ayarı Exchange Management Shell’den, kopya durumunu ise Get-MailboxDatabaseCopyStatus çıktısından doğrulamak gerekir.

6. Log temizleme kayıtları nasıl yorumlanmalı?

ESE Event ID 224 — Belirtilen log dosyası aralığının silindiğini bildiren olay.

Bu kayıt, belirtilen log aralığı için temizleme işlemi gerçekleştiğini gösterir. Ancak log silinmesi ile Circular Logging aynı şey değildir.

Görselde görev kategorisinin Shadow Copy olması da önemlidir. Bu nedenle kayıt, yedekleme zamanları ve diğer olaylarla birlikte değerlendirilmelidir. Tek başına bu olaydan Circular Logging’in açık olduğu sonucuna varılamaz.

Görsel açıklaması: Daha sonraki kontrolde log klasörünün ve E00.chk dosyasının görünümü.

Farklı bir tarihte log klasöründeki dosyalar ve checkpoint dosyasının görünümü.

Bu görüntüler farklı zamanlara aittir. Dosya sayısının değişmesi; log üretimi, temizleme, bakım veya çoğaltma faaliyetleriyle ilişkili olabilir. Yalnızca klasör görünümüne bakarak hangi mekanizmanın çalıştığını kesinleştiremeyiz.

Ayrıca görsellerde sunucu adları farklı biçimlerde görünüyor. Teknik değerlendirmede, her görüntünün kaynak sunucuya mı yoksa hedef sunucuya mı ait olduğunun kaydedilmesi önemlidir.

7. Veritabanı kopyasını yeniden eklemek veya seeding uygulamak

Circular Logging kapatıldıktan ve gerekli dismount/mount işlemi tamamlandıktan sonra kopya ekleme tekrar denenebilir.

7.1 Hedefte henüz kopya yoksa

Aşağıdaki örnekte HEDEF-SUNUCU yerine gerçek Exchange sunucu adını yazın:

Copy to Clipboard
Syntax HighlighterAdd-MailboxDatabaseCopy -Identity "Archive04" -MailboxServer "HEDEF-SUNUCU" -ActivationPreference 2

Bu işlem yeni kopyayı oluşturur ve varsayılan akışta seeding başlatır. Microsoft Learn — Add a mailbox database copy

7.2 Önceki denemede kopya zaten oluşturulmuşsa

Önce mevcut durumu kontrol edin:

Copy to Clipboard
Syntax HighlighterGet-MailboxDatabaseCopyStatus -Identity "Archive04\HEDEF-SUNUCU"

Kopya mevcutsa ve yeniden seeding gerektiği doğrulanmışsa, yeni bir kopya eklemek yerine mevcut kopyayı güncelleyin:

Copy to Clipboard
Syntax HighlighterSuspend-MailboxDatabaseCopy -Identity "Archive04\HEDEF-SUNUCU"
Copy to Clipboard
Syntax HighlighterUpdate-MailboxDatabaseCopy -Identity "Archive04\HEDEF-SUNUCU"

Update-MailboxDatabaseCopy çalıştırılmadan önce ilgili pasif kopyanın suspended durumda olması gerekir. Hedefte mevcut dosyalarla ilgili bir uyarı alınırsa dosyaların hangi kopyaya ait olduğu doğrulanmadan silme seçeneği kullanılmamalıdır. Microsoft Learn — Update-MailboxDatabaseCopy

Görsel açıklaması: Archive04 veritabanı için seeding işleminin başladığını ve veri aktarımının sürdüğünü gösteren ekran.

Bu görüntüde veri aktarımı başlamıştır. Ancak ilerleme ekranı, kopyanın tamamlandığını ve çoğaltmanın sağlıklı olduğunu göstermez.

Seeding süresi; veritabanı büyüklüğüne, ağ kapasitesine ve depolama performansına bağlıdır. EAC üzerinden yürütülen işlem tamamlanana kadar ilgili işlem penceresini açık tutun.

8. Çözümün başarılı olduğunu nasıl doğrularız?

Seeding sonrasında aşağıdaki komutu çalıştırın:

Copy to Clipboard
Syntax HighlighterGet-MailboxDatabaseCopyStatus -Identity "Archive04\*" | Format-Table Name,Status,CopyQueueLength,ReplayQueueLength -AutoSize

Sonuçları değerlendirirken:

• Aktif kopyanın Mounted durumda olduğunu kontrol edin.
• Yeni pasif kopyanın Healthy durumuna geçtiğini doğrulayın.
• Copy ve replay kuyruklarının azaldığını, normal çalışma düzeyinde kaldığını izleyin.
• Tekrarlayan kopyalama veya replay hataları olup olmadığını inceleyin.

Gerekirse sunucunun çoğaltma sağlığını ayrıca kontrol edin:

Copy to Clipboard
Syntax HighlighterTest-ReplicationHealth -Identity "HEDEF-SUNUCU"

9. Sorunun tekrar oluşmasını nasıl önleriz?

9.1 Kopya ekleme öncesinde Circular Logging’i kontrol edin

İlk pasif kopya oluşturulacaksa bu kontrolü standart hazırlık adımına ekleyin:

Copy to Clipboard
Syntax HighlighterGet-MailboxDatabase -Identity "Archive04" | Format-List Name,CircularLoggingEnabled

Ayarı kapattıktan sonra tek kopyalı veritabanında gerekli dismount/mount adımını atlamayın.

9.2 Disk kapasitesini önceden planlayın

Circular Logging kapatıldığında logların büyüme davranışı değişebilir. Seeding süresince oluşacak loglar için kaynak ve hedefte yeterli alan ayırın. Boş alanı yalnızca işlem başında değil, aktarım sürerken de izleyin.

9.3 Yedekleme ve log temizleme davranışını takip edin

Log birikmesini yalnızca Circular Logging açarak çözmeye çalışmak yerine, yedekleme işlerinin sonucunu ve çoğaltma sağlığını inceleyin. Circular Logging kararını kurumun geri dönüş hedefleriyle birlikte değerlendirin.

9.4 Circular Logging’i otomatik olarak yeniden açmayın

Kopya eklendikten sonra teknik olarak yeniden etkinleştirmek mümkün olsa da bu, her ortam için gerekli bir adım değildir. Ayarın son durumunu yedekleme ve veri koruma tasarımı belirlemelidir.

9.5 Log dosyalarını elle temizlemeyi rutin çözüm haline getirmeyin

.log, .chk veya .jrs dosyalarını yalnızca sayıları fazla olduğu için silmeyin. Önce veritabanı, yedekleme ve tüm kopyaların durumunu değerlendirin.

9.6 Başarı ölçütünü önceden belirleyin

İşlemin tamamlanma ölçütü ilerleme çubuğunun hareket etmesi değildir. Yeni pasif kopyanın Healthy olması, kuyrukların normal düzeye gelmesi ve çoğaltma kontrollerinin başarılı olmasıdır.

Bu vakada doğrudan doğrulanabilen yapılandırma engeli, Archive04 veritabanında Circular Logging açıkken kopya eklenmeye çalışılmasıdır. İlk pasif kopyayı oluşturmak için Circular Logging kapatılmalı, tek kopyalı veritabanında değişiklik dismount/mount ile uygulanmalı ve ardından kopya ekleme veya gerekli seeding işlemi gerçekleştirilmelidir.

ESE -1305 hatası ise ayrı bir teknik bulgu olarak ele alınmalıdır. Circular Logging engeli giderildikten sonra devam ederse, tam hata metni ve ilgili olay kayıtları üzerinden ayrıca araştırılmalıdır.

Paylaşılan görüntüler seeding’in başladığını göstermektedir. Çözümün tamamlandığını belgelemek için son adım, yeni pasif kopyanın Healthy durumda olduğunu doğrulamaktır.