Eseutil ile Exchange Database Onarımı Nasıl Yapılır?
ESEUTIL, Microsoft Exchange Server’ın Extensible Storage Engine (ESE) veritabanlarını analiz etmek ve belirli bakım/kurtarma işlemlerini gerçekleştirmek için kullanılan komut satırı aracıdır. Veritabanının durumunu incelemek, transaction log tutarlılığını kontrol etmek ve uygun senaryolarda çevrimdışı bakım yapmak için kullanılır.
Ekim 2026 güncellemesi: Bu yazının Exchange Server 2003 döneminden kalan özgün anlatımını ve 16 ekran görüntüsünü koruyarak teknik açıklamaları yeniledim. Aşağıdaki eski konsol ekranları ve priv1.edb yolları tarihsel örnektir; güncel Exchange sürümlerinin birebir kurulum talimatı değildir.
Kritik uyarı: ESEUTIL bir genel performans hızlandırma aracı değildir. Kuyruk birikmesi, yavaş istemci erişimi veya disk doluluğu her zaman EDB bozulması anlamına gelmez. Özellikle eseutil /p veri kaybına neden olabilir; mevcut log veya checkpoint dosyalarını silmek kurtarma olasılığını ortadan kaldırabilir. Üretim ortamında önce doğrulanmış yedek, log zinciri, depolama sağlığı ve desteklenen kurtarma seçenekleri değerlendirilmelidir.
ESEUTIL Nedir, Ne İşe Yarar?
Exchange Server üzerinde posta kutusu verileri ESE veritabanında tutulur. ESEUTIL, veritabanı dosyasının iç yapısını ve ilişkili transaction log dosyalarını değerlendirmede kullanılan yönetim aracıdır. Aracın farklı parametreleri birbirinden çok farklı işler yapar: durum sorgulama ve doğrulama işlemleri ile veritabanı onarımı aynı risk seviyesinde değildir.
Eski Exchange ortamlarında uygulama dosyaları, veritabanı konumları, storage group ve streaming database gibi kavramlar günümüzdeki sürümlerden farklıydı. Bu makaledeki komut ve ekran görüntülerini değerlendirirken ilgili Exchange sürümünü mutlaka dikkate almak gerekir.
Exchange Veritabanı Dosyaları: EDB, STM, LOG ve CHK
Orijinal makalemde Exchange Server 2003 için örnek veritabanı klasörünü C:\Program Files\Exchsrvr\MDBDATA olarak göstermiştim. Bu yol modern Exchange kurulumları için varsayılan kabul edilmemelidir; gerçek EDB ve log konumları Exchange yönetim araçlarıyla doğrulanmalıdır.
EDB ve STM dosyaları
Exchange Server 2003 döneminde priv1.edb ve priv1.stm gibi dosyalar aynı store yapısına ait olabiliyordu. STM (streaming database) kavramı Exchange Server 2003 mimarisine özgüdür; sonraki Exchange sürümlerinde aynı STM yapısı kullanılmaz. Güncel Exchange veritabanlarını değerlendirirken eski EDB/STM ayrımını doğrudan taşımamak gerekir.
Transaction log dosyaları
Transaction log dosyaları ESE işlemlerinin sürekliliğinde rol oynar. Dosya adlandırması ve log dosyasının boyutu sürüme göre değişebilir. Eski sürümlerde 5 MB boyutlu log örnekleri görülürken daha yeni Exchange sürümlerinde farklı boyutlar söz konusudur. Log dosyalarının kontrolsüz silinmesi, özellikle Dirty Shutdown durumunda veri kaybına veya kurtarmanın başarısız olmasına yol açabilir.
Checkpoint dosyaları
E00.chk gibi checkpoint dosyaları, log işlemlerinin veritabanına uygulanma durumuyla ilişkili bilgileri tutar. Checkpoint’in bulunması tek başına veritabanının sağlıklı olduğunu kanıtlamaz. Log zinciri ve veritabanı header bilgileri birlikte ele alınmalıdır.
Geçici ve rezerv dosyaları
Eski Exchange kurulumlarında Res1.log, Res2.log ve geçici ESE dosyaları gibi bileşenler de bulunabilir. Bunların görevini anlamak önemlidir; ancak yalnızca disk alanı açmak amacıyla bu dosyaları rastgele silmek doğru bir bakım yaklaşımı değildir.
ESEUTIL Parametrelerini Görüntüleme
Özgün makalede Exchange Server 2003 sunucusunda Exchsrvr\bin klasöründen ESEUTIL çalıştırılması gösteriliyordu. Güncel sürümlerde aracın yolu ve kullanılan Exchange Management Shell ortamı farklı olabilir. Dosyanın yerini sürümünüze göre doğrulayın.
Üretim ortamında işlem öncesi yapılabilecek önemli ayrım: /mh veritabanı header bilgisini okumaya yöneliktir; /r recovery, /d offline defragmentation, /p hard repair işlemleridir. Aynı komut ailesinde bulunmaları, bu işlemlerin birbirinin yerine geçebileceği anlamına gelmez.
Eseutil /mh: Clean Shutdown ve Dirty Shutdown Kontrolü
Bir Exchange veritabanının durumu incelenirken öncelikle ilgili EDB dosyasının header bilgileri kontrol edilebilir. Clean Shutdown, veritabanının tutarlı biçimde kapandığını; Dirty Shutdown ise gerekli log işlemlerinin henüz veritabanına uygulanmadığını gösterebilir. Dirty Shutdown tek başına fiziksel veritabanı bozulması demek değildir.
eseutil /mh "D:\ExchangeDatabases\DB01\DB01.edb"
Buradaki yol yalnızca örnektir. Gerçek dosya konumunu ve ilgili database’in mount durumunu doğrulamadan komutu kullanmayın. Header çıktısındaki State ve Log Required değerleri kurtarma değerlendirmesi için önemlidir.
Eseutil /d: Offline Defragmentation
Özgün yazıda Exchange Server 2003 üzerinde Mailbox Store’un dismount edilmesi ve ESEUTIL ile offline defragmentation yapılması adım adım gösteriliyordu. Bu ekranlar arşiv değeri taşıyor. Ancak modern Exchange’de performans düşüşü veya kuyruk sorunu yaşandığında otomatik çözüm olarak offline defrag önermek doğru değildir.
Aşağıdaki komut, eski kurulum yoluna göre hazırlanmış tarihsel bir örnektir. Gerçek bir üretim veritabanına doğrudan uygulanacak öneri değildir.
Offline defragmentation veritabanının çevrimdışı kalmasını gerektirir, yeni bir veritabanı dosyası oluşturmak için yeterli geçici disk kapasitesine ihtiyaç duyar ve operasyonel risk taşır. Özellikle DAG kullanılan ortamlarda kopyalar ve desteklenen bakım prosedürleri ayrıca değerlendirilmelidir. Veritabanındaki kullanılabilir boş alan, disk üzerinde derhal geri kazanılacak alanla aynı kavram değildir.
Orijinal örnekte işlemin ardından store yeniden mount ediliyordu. Bu adım yalnızca işlem sorunsuz tamamlanmışsa, veritabanı sağlığı doğrulanmışsa ve uygun kurtarma/geri dönüş planı varsa uygulanmalıdır.
Eseutil /d ile /b parametresi
Eski makalemde /b seçeneğiyle defragmentation sırasında bir yedek dosya konumu tanımlama örneği gösteriyordum. Bu parametreyi Exchange-aware, doğrulanmış bir veritabanı yedeğinin alternatifi olarak görmemek gerekir. Dosya kopyası oluşturulması, tek başına uygulanabilir kurtarma planı demek değildir.
Özgün örnekte /t parametresiyle geçici defragmentation veritabanı için farklı bir konum tanımlanıyordu. Bu, geçici dosya konumunu değiştiren bir seçenektir; kaynak diskteki kapasite, hedef diskteki boş alan ve işlem sırasında oluşabilecek kesintiler yine değerlendirilmelidir. Paylaşımlı veya ağ sürücüsünde geçici dosya kullanımı için genel bir başarı garantisi verilmemelidir.
Soft recovery, geçerli transaction log zincirindeki işlemlerin uygun ESE veritabanına uygulanarak tutarlı duruma ulaşılması için kullanılan kurtarma yaklaşımıdır. Önemli olan log prefix, log dizini, veritabanı ilişkisi ve gerekli dosyaların eksiksiz olmasıdır. Log dosyaları doğrulanmadan silinmemeli veya yeniden adlandırılmamalıdır.
Bu işlem için tek bir genel komut vermek doğru olmaz; kullanılacak parametreler ilgili Exchange sürümüne, veritabanı konumuna ve recovery senaryosuna göre belirlenmelidir. Özellikle log zincirinin eksik olduğu durumlarda kurtarma yöntemi değişir.
Eseutil /p: Hard Repair ve Veri Kaybı Riski
En kritik bölüm burası.eseutil /p, bozuk sayfalar veya kayıtlar üzerinde onarım yaparken veritabanından veri çıkarabilir. Bu nedenle kullanıcı verilerinin kaybolması mümkündür. Başarılı komut sonucu bile bütün posta kutusu içeriğinin eksiksiz olduğunu kanıtlamaz.
Özgün makalemde aşağıdaki gibi bir Exchange Server 2003 komutu yer alıyordu. Bunu yalnızca tarihsel örnek olarak tutuyorum; üretim sunucusunda doğrudan çalıştırmanı önermiyorum.
Öncelik sırası sağlıklı DAG kopyalarının, desteklenen veritabanı kurtarma yöntemlerinin ve doğrulanmış yedeklerin değerlendirilmesi olmalıdır. Onarım kaçınılmazsa dosya seviyesinde koruma, veri kaybı değerlendirmesi, kurtarma sonrası içerik doğrulaması ve mümkünse yeni sağlıklı veritabanına taşıma planı gerekir. Ayrıca Microsoft destek kapsamı ve ilgili sürümün yaşam döngüsü dikkate alınmalıdır.
Özellikle uzak durulması gereken kestirme yol: Veritabanı mount olmuyor diye tüm .log, .chk veya geçici dosyaları silip ardından /p çalıştırmak. Bu, gerekli log zincirini yok ederek veri kaybını artırabilir.
Exchange Veritabanı Mount Olmuyorsa Nasıl Yaklaşılmalı?
Öncelikle hata kodu, olay günlükleri ve veritabanı header bilgileri birlikte incelenmelidir. Depolama sorunları, eksik log dosyaları, disk alanı, erişim yetkileri ve ESE hataları birbirinden farklı nedenlerdir. Bir hata kodunu görür görmez bunu tek bir dosyanın bozulmasıyla eşleştirmek yanlış teşhise neden olabilir.
Etkilenen veritabanını, Exchange sürümünü ve varsa DAG durumunu belirleyin.
Olay günlüklerini, ilgili ESE hata kodlarını, disk ve dosya sistemi sağlığını inceleyin.
Güncel, doğrulanmış yedeği ve sağlıklı kopyaları kontrol edin.
EDB ve transaction log dosyalarını değiştirmeden önce dosya düzeyinde koruma planını oluşturun.
Header ve log gereksinimlerine göre desteklenen soft recovery veya restore seçeneklerini değerlendirin.
Hard repair seçeneğini yalnızca veri kaybı riski ve kurtarma sonrasındaki kontroller açıkça kabul edildiğinde son çare olarak ele alın.
Exchange Server Sürümleri ve Güncel Destek Durumu
Exchange Server 2003 ekran görüntüleri ve yolları, bu yazının teknik arşiv değerini oluşturuyor. Ancak Exchange Server 2003, 2007, 2010, 2013, 2016 ve 2019 gibi sürümlerin destek yaşam döngüleri ve modern Exchange Server Subscription Edition yaklaşımı birbirinden ayrılmalıdır. Eski ortamda çalışmış bir kurtarma adımını güncel üretim ortamına aynen taşımamak gerekir.
Sonuç
ESEUTIL güçlü bir tanılama ve bakım aracıdır; fakat bütün Exchange problemleri için tek çözüm değildir. En doğru yaklaşım, önce sorunun kaynağını belirlemek, verinin kurtarılabilirliğini korumak ve işlem türüne uygun desteklenen prosedürü seçmektir. Bu yazıdaki eski ekran görüntüleri orijinal Exchange Server 2003 uygulamasını belgelemeye devam ederken yeni açıklamalar güvenli karar vermeye yardımcı olmak için eklenmiştir.
Published On: 20 Ocak 2014 / Categories: Exchange Server / 9,6 min read /
