Genişletilebilir Depolama Altyapısı Dosyaları

Şunlar için geçerlidir: Windows | Windows Server

Genişletilebilir Depolama Altyapısı Dosyaları

Genişletilebilir Depolama Altyapısı aşağıdaki dosya türlerini kullanır:

• İşlem Günlüğü Dosyalarını
• Geçici İşlem Günlüğü Dosyalarını
• Ayrılmış İşlem Günlüğü Dosyalarını
• Denetim Noktası Dosyaları
• Veritabanı Dosyaları
• Geçici Veritabanları
• Harita Dosyalarını Temizleme

Bu tablo, ESE tarafından yönetilen veri dosyası adlara genel bir bakış içerir. Windows Vista ve sonraki sürümlerde, JET_paramLegacyFileNames ayarı kullanılan dosya adlarını etkiler.

Dosya Türü	Eski Adlar (JET_bitESE98FileNames)	Modern Adlar (Varsayılan)
İşlem Günlüğü Dosyaları	<taban>.log, <temel>XXXXX.log	<base.jtx>, <base>XXXXX.jtx
Geçici İşlem Günlüğü	<temel>tmp.log	<base>tmp.jtx
Ayrılmış İşlem Günlüğü Dosyaları	res1.log, res2.log (Windows Server 2003 ve öncesi)	<temel>RESXXXXXX.jrs (Windows Vista ve üzeri)
Denetim Noktası Dosyaları	<base.chk>	<base.jcp>
Veritabanı Dosyaları	Kullanıcı tarafından belirtilen (örn. .edb)	Kullanıcı tarafından belirtilen (örn. .edb)
Geçici Veritabanları	JET_paramTempPath aracılığıyla kullanıcı tarafından belirtilen	JET_paramTempPath aracılığıyla kullanıcı tarafından belirtilen
Harita Dosyalarını Temizle	N/A	<database.jfm> (Windows 10 Yıldönümü Güncelleştirmesi ve üzeri)

İşlem Günlüğü Dosyaları

İşlem günlüğü dosyaları, veritabanı dosyalarındaki işlemleri içerir. Bunlar, beklenmeyen bir işlem sonlandırma veya sistem kapatma işleminden sonra veritabanını mantıksal olarak tutarlı bir duruma getirmek için yeterli bilgi içerir.

Günlük dosyalarının adları, JET_paramBaseNameile ayarlanabilen üç harfli bir temel ada bağlıdır. Aşağıdaki örneklerde varsayılan temel ad olduğundan "edb" temel adı kullanılır. İşlem günlüğü dosyalarının uzantısı, JET_bitESE98FileNames JET_paramLegacyFileNames parametresinde ayarlanıp ayarlanmadığına bağlı olarak .log veya .jtx olur. Daha fazla bilgi için bkz. Genişletilebilir Depolama Altyapısı Sistem Parametreleri.

İşlem günlüğü dosyaları, 1'den başlayarak <temel><oluşturma numarası>.log olarak adlandırılır. Günlük oluşturma numarası onaltılık biçimdedir. Örneğin, edb00001.log ilk günlük, edb000ff.log ise 255. günlük. Günlük dosyalarının günlük dosyası adında, 1048576. günlük dosyasına kadar beş onaltılık basamak vardır ve bu noktada günlük dosyaları 11,3 biçiminde adlandırılmaya başlar (örneğin, edb00100000.log). <temel>.log her zaman kullanılmakta olan günlük dosyasıdır. Veritabanı altyapısı etkin değilse, edb.log oluşturma işlemi şu komut kullanılarak tanımlanabilir: esentutl.exe -ml edb.log.

İşlem günlüğü dosyalarına sahip olsa da. Genellikle metin dosyalarıyla ilişkili LOG uzantısı, işlem günlüğü dosyaları ikili biçimdedir ve hiçbir zaman kullanıcı tarafından düzenlenmemelidir. Veritabanı işlemleri önce günlüğe yazılır. Veriler daha sonra veritabanı dosyasına yazılabilir; muhtemelen hemen, potansiyel olarak çok daha sonra. Beklenmeyen işlem veya sistem sonlandırma durumunda, işlemler günlük dosyalarında hala bulunur ve tamamlanmamış işlemler geri alınabilir. İşlem günlüğü dosyalarını yeniden yürütme eylemi, geçici kurtarmaolarak adlandırılır ve JetInit veya jetInit2 çağrıldığında otomatik olarak gerçekleştirilir. Yazılımdan kurtarma, Esentutl.exe programının "-r" seçeneğiyle el ile de gerçekleştirilebilir. Bir yedekten geri yüklenen bir veritabanında işlem günlüğü dosyalarını yeniden yürütme eylemi, sabit kurtarmaolarak adlandırılır.

Günlük dosyaları sabit boyuttadır ve JET_paramLogFileSizeile özelleştirilebilir. Geçerli günlük dosyası (edb.log) doldurulduğunda, <temel><oluşturma numarası>.log olarak yeniden adlandırılır ve işlem günlüğü akışında yeni bir işlem günlüğü dosyası gerekir.

Her veritabanı örneğinin kendisiyle ilişkilendirilmiş tek bir günlük dosyası dizisi vardır. Windows XP, JetCreateInstance'ı kullanıma sunarak tek bir işlem tarafından birden çok işlem günlüğü dosya dizisinin kullanılmasına olanak sağlar. Ancak aynı dizinde birden çok işlem günlüğü dosyası dizisi bulunamaz.

Veri bozulmasına neden olabileceği için işlem günlüğü dosyaları neredeyse hiçbir zaman el ile işlenmemeli, yeniden adlandırılmamalı, taşınmamalı veya silinmemelidir.

İşlem günlüğü dosyaları tam yedekleme sırasında (bkz. JetBackup , JetTruncateLog, JetTruncateLogInstance) veya döngüsel günlük etkinse normal işlemler sırasında silinir.

İşlem günlüğü dosyası doldurulduktan sonra veritabanı altyapısının yeni bir günlük dosyası oluşturması gerekir. Döngüsel günlük, günlük dosyalarının kilitlenme kurtarması için artık gerekli olmadığında veritabanı altyapısı tarafından otomatik olarak temizlenebileceği bir araçtır. Bu işlem, yedekleme işleminin yan ürünü olarak günlük dosyalarını kaldırmaya alternatiftir. Döngüsel günlük, JET_paramCircularLog sistem parametresiyle denetlenebilir. İşlem günlüğü dosyaları başka bir yöntem kullanılarak silinmemelidir.

Geçici İşlem Günlüğü Dosyaları

edb.log dolduğunda ESE'nin yeni bir dosya oluşturması gerekir. Yeni günlük işlemi dosyası, ESE tarafından kullanılmadan önce geçici işlem günlüğü dosyası olarak bilinir.

Yeni bir günlük dosyası oluşturulur ve boyutu genişletilirken, temel<tmp.log >olarak adlandırılır. Yeni dosya oluşturmak maliyetli olabilecek bir işlem olabileceğinden, ESE arka plan görevi olarak bir sonraki günlük dosyasını proaktif olarak oluşturur.

Geçici işlem günlüğü dosyası, yeni bir işlem günlüğü dosyasına ihtiyaç duyulacak şekilde oluşturulduğundan, herhangi bir yararlı bilgi içermez.

Ayrılmış İşlem Günlüğü Dosyaları

Ayrılmış işlem günlüğü dosyaları, altyapı temiz bir kapatma almak için önemli işlemlerin günlüğe kaydedilmesine izin vermemeye başladığında oluşturulur.

Windows Vista: Windows Vista ve sonraki sürümlerde, Ayrılmış İşlem Günlüğü Dosyaları RESXXXXX.jrs<temel >olarak adlandırılır.

Windows Server 2003: Windows Server 2003 ve önceki sürümlerinde, Ayrılmış İşlem Günlüğü Dosyaları res1.log ve res2.log olarak adlandırılır.

Veritabanı altyapısında disk alanı dolduğunda yeni bir günlük dosyası oluşturamaz. Yapılacak en güvenli şey, temiz bir şekilde kapatmaktır, ancak bazı işlemlerin (geri alma işlemleri gibi) yine de günlüğe kaydedilmesi gerekir. Çoğu veritabanı işlemi bu aşamada başarısız olur.

Ayrılmış işlem günlüğü dosyaları, disk dışı bir senaryoda işlem günlüğü dosyalarına ihtiyaç duyulacak şekilde oluşturulduğundan, yararlı bilgiler içermez.

Denetim Noktası Dosyaları

Denetim noktası dosyası, belirli bir işlem günlüğü dosya dizisi için denetim noktasını depolar. Denetim noktası dosyası, JET_bitESE98FileNames JET_paramLegacyFileNames parametresinde ayarlanıp ayarlanmadığına ve konumunun <tarafından verilip verilmediğine bağlı olarak >temel<.chk veya >temel.jcp olarak adlandırılır.

Veritabanı işlemleri önce günlük dosyalarına yazılır ve ardından bellekte önbelleğe alınır. Sonraki bir noktada, işlemler veritabanı dosyasına yazılır, ancak performans nedenleriyle, işlemlerin veritabanı dosyasına yazılma sırası başlangıçta günlüğe kaydedildikleri sırayla eşleşmeyebilir. İşlem günlüğü dosyasına yazılan işlemler iki durumdan birinde olur:

• İşlem günlüğü dosyasına ve veritabanı dosyasına yazılır.

• İşlem günlüğü dosyasına yazılır ve henüz veritabanı dosyasına yazılmaz.

Birçok veritabanı işlemi tek bir işlem günlüğü dosyasında depolanabilir. Belirli bir günlük dosyası aşağıdaki öğelerden oluşabilir:

• Veritabanı dosyasına yazılan tüm işlemler.

• Veritabanı dosyasına hiçbir işlem yazıldı

• Veritabanı dosyasına yazılan işlemlerin ve henüz veritabanı dosyasına yazılmayan işlemlerin bir karışımı.

Denetim noktası, denetim noktasından önceki tüm işlemlerin veritabanı dosyasına yazıldığı işlem günlüğü akışındaki belirli bir noktaya başvurur. Denetim noktasından sonra gerçekleşen işlemler hakkında hiçbir garanti yoktur; bazıları bellekte, bazıları da veritabanına yazılabilir.

Denetim noktasından önceki günlük dosyalarındaki tüm işlemler veritabanı dosyasında temsil edilmiş olduğundan, geçici kurtarmanın belirli bir veritabanını temiz duruma getirmek için yalnızca denetim noktasından sonraki işlem günlüğü dosyaları gerekir.

Veritabanı Dosyaları

Veritabanı dosyası veritabanındaki tüm tabloların şemasını, veritabanındaki tüm tabloların kayıtlarını ve tablolar üzerindeki dizinleri içerir. Konumu JetCreateDatabase, JetCreateDatabase2, JetAttachDatabaseveya JetAttachDatabase2kullanılarak verilir.

Veritabanı yalnızca jetterm veya JetTerm2 başarılı bir çağrıdan sonra temiz bir şekilde kapatılır.

Esentutl.exe programı bir veritabanının "-mh" seçeneğiyle temiz bir şekilde kapatılıp kapatılmadığını algılayabilir. Örneğin, "esentutl.exe -mh sample.edb" sample.edb adlı veritabanının veritabanı üst bilgisini okur ve sample.edb durumunu yazdırır. "Durum: Temiz Kapatma" veya "Durum: Kirli Kapatma" yazdırılabilir.

Temiz bir şekilde kapatılmayan bir veritabanı kirli kapatma durumundadır. Windows XP'den önce, bu durum tutarsız olarak adlandırılıyordu. Kirli (tutarsız) bir veritabanı, geçici kurtarma ile temiz bir duruma getirilebilir. Bozuk veritabanı, kirli ("tutarsız") veritabanıyla aynı değildir.

Bozuk veritabanı fiziksel veya mantıksal bozulmaya başvurur ve geçici kurtarma ile düzeltilemez. Fiziksel bozulmalar, genellikle veritabanı sayfalarında sağlama toplamları tarafından yakalanacak bit çevirmeleri olabilir. Veritabanı dosyasındaki başarısız sağlama toplamı kendisini JET_errReadVerifyFailure hatası olarak bildirir.

Yalnızca temiz bir şekilde kapatılan veritabanları güvenli bir şekilde taşınabilir veya yeniden adlandırılabilir. Bir veritabanı temiz bir şekilde kapatılmadıysa, otomatik olarak güvenli bir şekilde taşınamaz veya yeniden adlandırılamaz.

Tek bir işlem günlüğü dosya dizisiyle birden çok veritabanı ilişkilendirilebilir.

Geçici Veritabanları

Geçici veritabanı temptable'lar için bir yedekleme deposu olarak kullanılır ve dizin oluştururken de kullanılır.

Ad ve konum JET_paramTempPathile yapılandırılır.

Temptable'lar JetOpenTempTable, JetOpenTempTable2, JetOpenTempTable3JetOpenTemporaryTableile oluşturulur. Bunlar ayrıca bazı API çağrıları tarafından oluşturulur ve şema bilgilerini (JetGetIndexInfogibi) döndürmek için kullanılır.

Harita Dosyalarını Temizle

Windows 10 Yıldönümü Güncelleştirmesi (istemci) ve Windows Server 2016 (sunucu) ile başlayarak, ESE kayıp yazma işlemlerine (veya kayıp temizlemelere) karşı ek bir koruma düzeyi 1 ekledi ve bu tür olayların çapraz işlem yeniden başlatmasını algılamasına olanak sağlıyor2. Bu özellik, meta verilerin "temizleme eşleme" dosyası olarak adlandırılan ayrı bir dosyada kalıcı olmasını gerektirir.

Her veritabanı dosyası için bir temizleme eşleme dosyası oluşturulur ve aynı dizinde bulunur. Dosya, veritabanı dosyasına benzer ancak farklı bir uzantıyla adlandırılır. Örneğin, istemci uygulaması tam yolu C:\MyDirectory\MyDabatase.edb olan bir veritabanı oluşturursa, buna karşılık gelen temizleme eşleme dosyası C:\MyDirectory\MyDabatase.jfm olur.

Bu geliştirme, veritabanı dosyalarının nasıl adlandırılması gerektiğine ilişkin iki gereksinim sunar:

• Aynı dizindeki iki veritabanı farklı uzantılara sahip aynı dosya adına sahip olmamalıdır. Örneğin: C:\MyDirectory\MyDabatase.db1 ve C:\MyDirectory\MyDabatase.db2.

• 2. Veritabanının .jfm uzantısı olmamalıdır.

Bir veritabanı dosyasını el ile kopyaladığınızda veya taşıdığınızda, buna karşılık gelen temizleme eşleme dosyası da sırasıyla aynı hedef dizine kopyalanmalıdır veya taşınmalıdır. Yeni bir veritabanı ekinin bulunduğu sırada bir temizleme eşleme dosyası yoksa (JetAttachDatabase aracılığıyla) sayfalar veritabanından okundukça yeni bir tane oluşturulur ve isteğe bağlı olarak yeniden doldurulur. Eşleşmeyen veritabanı ve temizleme eşleme dosyalarının karıştırılması ESE tarafından işlenir ve eşleşmeyen temizleme eşlemesinin silinip sıfırdan yeniden oluşturulmasını zorlar.

Temizleme eşleme dosyasının boyutu, ilişkili veritabanı dosyasıyla doğrudan orantılıdır ve yaklaşık olarak buna eşittir (bayt cinsinden tüm boyutlar, sonuç 8.192'nin sonraki katına yuvarlanmalıdır):

8,192 + ((<database file size> / <database page size>) / 4)

Örneğin: 32 KB sayfa boyutu kullanan 1,5 GB veritabanı için temizleme eşlemesinin yaklaşık boyutu 24.576 bayttır (veya 24 KB).

Veritabanı sayfaları temizlendıkça harita dosyasının temizlenmesi gerekir. İşlem günlüğü etkinleştirilirse (örneğin, JET_paramRecovery "açık" olarak ayarlanırsa, istemci uygulaması veritabanında değişiklikler yaptığında temizleme eşlemesi yenilenir. Ortalama olarak, tüm temizleme eşlemesi, oluşturulan işlem günlüklerinin her 20% JET_paramCheckpointDepthMax -worth (bayt cinsinden) için geçici olmayan medyaya bir kez yazılır. Yazma işlemlerinin sayısı, değişikliklerin veritabanı genelinde nasıl dağıtıldığına bağlıdır. Ancak en fazla, yaklaşık olarak (tüm boyutlar bayt cinsinden):

<flush map file size> / JET_paramMaxCoalesceWriteSize

İşlem günlüğü devre dışı bırakılırsa (örneğin, JET_paramRecovery "kapalı" olarak ayarlanırsa), temizleme eşlemesi yalnızca veritabanı açıkça temiz bir şekilde ayrıldığında (JetDetachDatabasearacılığıyla) veya ilişkili ESE örneğini sonlandırarak (JET_bitTermDirty geçirilmediği sürece JetTerm işlevlerinden herhangi biri aracılığıyla) örtük olarak temiz bir şekilde ayrılırsa yenilenir.

1 Kayıp yazma (veya kayıp temizleme), işletim sisteminden ESE veritabanı altyapısına başarıyla döndüren bir yazma işlemi olarak tanımlanır, ancak gerçek veriler hiçbir zaman geçici olmayan medyadaki veritabanı dosyasında kalıcı olmaz. Genellikle hatalı çalışan veya yanlış yapılandırılmış bir depolama yığını (yazılım veya donanım) neden olur. İstemci uygulamaları, veriler kayıp bir yazma olayının altında yer alan bir bölgede yer alıyorsa veritabanından veri okuma gerektiren ESE işlevlerinden JET_errReadLostFlushVerifyFailure bir hata alabilir.

2 Windows 8 (istemci) ve Windows Server 2012'den (sunucu) bu yana bir işlemin yaşam süresi içinde kayıp yazmaları algılama özelliği mevcuttur.