Rozšiřitelné soubory modulu úložiště

platí pro: Windows | Windows Server

Rozšiřitelné soubory modulu úložiště

Rozšiřitelný modul úložiště používá následující typy souborů:

Tato tabulka obsahuje přehled názvů datových souborů, které spravuje ESE. V systému Windows Vista a novějších má nastavení JET_paramLegacyFileNames vliv na názvy souborů, které se používají.

Typ souboru Starší názvy (JET_bitESE98FileNames) Moderní názvy (výchozí)
Soubory transakčního protokolu <base>.log, <base>XXXXX.log <base.jtx>, <base>XXXXX.jtx
Dočasný transakční protokol <základní>tmp.log <base>tmp.jtx
Soubory protokolu rezervovaných transakcí res1.log, res2.log (Windows Server 2003 a starší) <base>RESXXXXX.jrs (Windows Vista a novější)
Soubory kontrolních bodů <base.chk> <base.jcp>
Databázové soubory Zadané uživatelem (např. .edb) Zadané uživatelem (např. .edb)
Dočasné databáze Uživatelem zadaný prostřednictvím JET_paramTempPath Uživatelem zadaný prostřednictvím JET_paramTempPath
Vyprázdnění souborů mapy N/A <database.jfm> (Windows 10 Anniversary Update a novější)

Soubory transakčního protokolu

Soubory transakčního protokolu obsahují operace s databázovými soubory. Obsahují dostatek informací, které po neočekávaném ukončení procesu nebo vypnutí systému přenesou databázi do logicky konzistentního stavu.

Názvy souborů protokolu jsou závislé na základním názvu se třemi písmeny, který lze nastavit pomocí JET_paramBaseName. Následující příklady používají základní název "edb", protože se jedná o výchozí základní název. Přípona souborů transakčního protokolu bude .log nebo .jtx v závislosti na tom, zda je JET_bitESE98FileNames nastavena v parametru JET_paramLegacyFileNames. Další informace naleznete v tématu rozšiřitelné systémové parametry modulu úložiště.

Soubory transakčního protokolu se nazývají <základní><>.log číslo generace počínaje číslem 1. Číslo generování protokolu je v šestnáctkovém formátu. Například edb00001.log je první protokol a edb000ff.log je 255. protokol. Soubory protokolu mají pět šestnáctkových číslic v názvu souboru protokolu až do 1048576. souboru protokolu, v němž se soubory protokolu začínají jmenovat ve formátu 11,3 (například edb00100000.log). <základní>.log je vždy používaný soubor protokolu. Pokud databázový stroj není aktivní, lze generování edb.log identifikovat pomocí následujícího příkazu: esentutl.exe -ml edb.log.

Ačkoli soubory transakčního protokolu mají . Rozšíření LOG běžně přidružené k textovým souborům, soubory transakčních protokolů jsou v binárním formátu a uživatel by ho nikdy neměl upravovat. Databázové operace se nejprve zapisují do protokolu. Data mohou být zapsána do souboru databáze později; možná okamžitě, potenciálně mnohem později. V případě neočekávaného procesu nebo ukončení systému se operace stále nacházejí v souborech protokolu a neúplné transakce je možné vrátit zpět. Přehrání souborů transakčního protokolu se nazývá obnovitelné obnovenía provádí se automaticky při JetInit nebo JetInit2 je volána. Obnovitelné obnovení lze provést také ručně pomocí možnosti -r programu Esentutl.exe. Přehrání souborů transakčního protokolu v databázi obnovené ze zálohy se nazývá pevného obnovení.

Soubory protokolu mají pevnou velikost, přizpůsobitelné pomocí JET_paramLogFileSize. Když se aktuální soubor protokolu (tj. edb.log) vyplní, přejmenuje se na <základní><číslo generování>.log a v datovém proudu transakčního protokolu se vyžaduje nový soubor protokolu transakcí.

Každá instance databáze má přidruženou jednu sekvenci souboru protokolu. Systém Windows XP zavedl JetCreateInstance, což umožňuje použití více sekvencí souborů transakčního protokolu jedním procesem. Ve stejném adresáři však nemůže existovat více sekvencí souborů transakčního protokolu.

Soubory transakčního protokolu by neměly být téměř nikdy ručně manipulovány, přejmenovány, přesunuty nebo odstraněny, protože poškození dat může mít za následek.

Soubory transakčního protokolu odstraní databázový stroj během úplného zálohování (viz JetBackup, JetTruncateLog, JetTruncateLogInstance) nebo během normálních operací, pokud je povolené cyklické protokolování.

Po vyplnění souboru transakčního protokolu musí databázový stroj vytvořit nový soubor protokolu. Cyklické protokolování je prostředek, pomocí kterého může databázový stroj automaticky vyčistit soubory protokolů, když už nejsou potřeba pro zotavení po havárii. Tento proces je alternativou k odebrání souborů protokolu jako produktu provedení zálohy. Cyklické protokolování lze řídit pomocí JET_paramCircularLog systémového parametru. Soubory transakčního protokolu by neměly být odstraněny pomocí žádné jiné metody.

Dočasné soubory protokolu transakcí

Když se edb.log vyplní, musí ESE vytvořit nový soubor. Nový soubor transakce protokolu se označuje jako dočasný soubor protokolu transakcí před použitím ESE.

Zatímco se vytvoří nový soubor protokolu a jeho velikost se rozšíří, bude se volat <základní>tmp.log. Vytvoření nového souboru může být potenciálně nákladná operace, takže ESE vytvoří další soubor protokolu proaktivně jako úlohu na pozadí.

Vzhledem k tomu, že dočasný soubor protokolu transakcí je vytvořen v očekávání potřeby nového souboru transakčního protokolu, neobsahuje žádné užitečné informace.

Soubory protokolu rezervovaných transakcí

Soubory protokolu rezervovaných transakcí se vytvoří, když modul začne umožňovat protokolování důležitých operací pro získání čistého vypnutí.

Windows Vista: V systému Windows Vista a novější jsou soubory protokolu rezervovaných transakcí pojmenovány <základní>RESXXXXX.jrs.

Windows Server 2003: v systému Windows Server 2003 a starších verzích mají soubory protokolu rezervovaných transakcí název res1.log a res2.log.

Když databázový stroj vyčerpá místo na disku, nemůže vytvořit nový soubor protokolu. Nejbezpečnější věcí, kterou je potřeba udělat, je čistě vypnout, ale některé operace (například operace vrácení zpět) musí být stále protokolovány. Většina databázových operací v této fázi selže.

Vzhledem k tomu, že soubory protokolu rezervovaných transakcí jsou vytvořeny v očekávání potřeby souborů transakčních protokolů ve scénáři mimo disk, neobsahují žádné užitečné informace.

Soubory kontrolních bodů

Soubor kontrolního bodu ukládá kontrolní bod pro určitou posloupnost souborů protokolu transakcí. Soubor kontrolního bodu má název <base>.chk nebo <base>.jcp v závislosti na tom, jestli je JET_bitESE98FileNames nastaven v parametru JET_paramLegacyFileNames a jeho umístění je dáno JET_paramSystemPath.

Databázové operace se nejprve zapisují do souborů protokolu a pak se ukládají do mezipaměti. V některém pozdějším okamžiku se operace zapisují do souboru databáze, ale z důvodů výkonu nemusí pořadí zápisu operací do souboru databáze odpovídat pořadí, ve kterém byly původně protokolovány. Operace zapsané do souboru transakčního protokolu budou v jednom ze dvou stavů:

  • Zapsáno do souboru transakčního protokolu a databázového souboru.

  • Zapsáno do souboru transakčního protokolu a ještě není zapsáno do souboru databáze.

Mnoho databázových operací může být uloženo v jednom souboru transakčního protokolu. Daný soubor protokolu se může skládat z následujících položek:

  • Všechny operace zapsané do souboru databáze.

  • Do souboru databáze nejsou zapsány žádné operace.

  • Kombinace operací zapsaných do souboru databáze a operací, které ještě nejsou zapsány do souboru databáze.

Kontrolní bod odkazuje na bod v čase datového proudu transakčního protokolu, kde byly všechny operace před kontrolním bodem zapsány do souboru databáze. Neexistuje žádná záruka týkající se operací, ke kterým dochází po kontrolním bodu; některé můžou být v paměti a některé můžou být zapsány do databáze.

Vzhledem k tomu, že všechny operace v souborech protokolu před kontrolním bodem jsou reprezentovány v databázovém souboru, jsou po kontrolním bodu potřeba pouze soubory transakčního protokolu, aby bylo možné obnovit obnovit konkrétní databázi do čistého stavu.

Databázové soubory

Soubor databáze obsahuje schéma pro všechny tabulky v databázi, záznamy pro všechny tabulky v databázi a indexy nad tabulkami. Jeho umístění je dáno pomocí JetCreateDatabase, JetCreateDatabase2, JetAttachDatabasenebo JetAttachDatabase2.

Databáze je čistě vypnuta až po úspěšném volání JetTerm nebo JetTerm2.

Program Esentutl.exe dokáže zjistit, jestli je databáze vypnutá čistě s možností "-mh". Například "esentutl.exe -mh sample.edb" přečte hlavičku databáze s názvem sample.edb a vypíše stav sample.edb. Může se vytisknout Stav: Čisté vypnutí nebo Stav: Špinavé vypnutí.

Databáze, která nebyla čistě vypnuta, je ve stavu zašpiněného vypnutí. Před systémem Windows XP byl tento stav volána nekonzistentní. Nečistá (nekonzistentní) databáze se dá převést do čistého stavu s využitím obnovitelného obnovení. Poškozená databáze není stejná jako zašpiněná (nekonzistentní) databáze.

Poškozená databáze odkazuje na fyzické nebo logické poškození a nelze ji opravit pomocí obnovitelného obnovení. Fyzické poškození může být bit překlopení, které budou často zachyceny kontrolními součty na stránkách databáze. Neúspěšný kontrolní součet v souboru databáze se manifestuje jako JET_errReadVerifyFailure chyba.

Databáze je možné bezpečně přesouvat nebo přejmenovávat pouze čistě. Pokud databáze nebyla čistě vypnuta, nelze ji automaticky bezpečně přesunout ani přejmenovat.

K jedné sekvenci souboru transakčního protokolu může být přidruženo více databází.

Dočasné databáze

Dočasná databáze se používá jako záložní úložiště pro dočasné tabulky a používá se také při vytváření indexů.

Název a umístění se konfiguruje s JET_paramTempPath.

Šablony se vytvářejí pomocí tabulky JetOpenTempTable, JetOpenTempTable2, JetOpenTempTable3, JetOpenTemporaryTable. Vytvářejí se také pomocí některých volání rozhraní API a používají se k vrácení informací o schématu (například JetGetIndexInfo).

Vyprázdnění souborů mapy

Počínaje verzí Windows 10 Anniversary Update (klient) a Windows Server 2016 (server) přidala služba ESE další úroveň ochrany proti ztraceným zápisům (nebo ztraceným vyprázdněním) 1, což umožňuje detekovat takové události opětovné inicializace mezi procesy2. Tato funkce vyžaduje zachování metadat do samostatného souboru označovaného jako "vyprázdnění map" souboru.

Pro každý soubor databáze se vytvoří jeden soubor mapy vyprázdnění a nachází se ve stejném adresáři. Soubor se jmenuje podobně jako soubor databáze, ale s jinou příponou. Pokud například klientská aplikace vytvoří databázi s úplnou cestou C:\MyDirectory\MyDabatase.edb, jeho odpovídající soubor mapování vyprázdnění je C:\MyDirectory\MyDabatase.jfm.

Toto vylepšení přináší dva požadavky na pojmenování databázových souborů:

  • Dvě databáze ve stejném adresáři nesmí mít stejný název souboru s různými rozšířeními. Například: C:\MyDirectory\MyDabatase.db1 a C:\MyDirectory\MyDabatase.db2.

  • 2. Databáze nesmí mít příponu .jfm.

Když ručně zkopírujete nebo přesunete soubor databáze, měl by se také zkopírovat nebo přesunout odpovídající soubor mapování vyprázdnění do stejného cílového adresáře. Pokud soubor mapy vyprázdnění není v době nové přílohy databáze (prostřednictvím JetAttachDatabase, vytvoří se nový soubor a znovu naplní na vyžádání, protože se stránky čtou z databáze. ESE zpracovává kombinování neshod databáze a vyprázdnění souborů mapování a vynutí odstranění a opětovné vytvoření neodpovídající mapy vyprázdnění.

Velikost souboru s vyprázdněním mapy je přímo úměrná přidruženému databázovému souboru a přibližně rovna (všechny velikosti v bajtech musí být zaokrouhleny nahoru na další násobek 8 192):

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

Příklad: Pro databázi o velikosti 1,5 GB s velikostí stránky 32 kB je přibližná velikost mapy vyprázdnění 24 576 bajtů (nebo 24 kB).

Soubor mapy vyprázdnění je potřeba aktualizovat, protože se vyprázdní databázové stránky. Pokud je povolené transakční protokolování (například JET_paramRecovery nastaveno na zapnuto, výchozí), aktualizace mapy vyprázdnění se provádí, protože klientská aplikace provádí úpravy databáze. V průměru se celá mapa vyprázdnění zapisuje do nestálého média jednou za každých 20% JET_paramCheckpointDepthMax -worth (v bajtech) vygenerovaných transakčních protokolů. Počet operací zápisu závisí na tom, jak jsou změny distribuovány v celé databázi. Ale je to nanejvýš přibližně (všechny velikosti v bajtech):

<flush map file size> / JET_paramMaxCoalesceWriteSize

Pokud je transakční protokolování zakázané (například JET_paramRecovery nastaveno na "vypnuto"), mapování vyprázdnění se aktualizuje pouze jednou, když je databáze explicitně odpojena (prostřednictvím JetDetachDatabase, nebo implicitně odpojí čistě ukončením přidružené instance ESE (prostřednictvím některé z JetTerm funkcí, pokud JET_bitTermDirty se nepředá).

1 Ztracený zápis (nebo ztracené vyprázdnění) je definován jako operace zápisu, která se úspěšně vrací z operačního systému do databázového stroje ESE, ale skutečná data se nikdy neuchovávají v databázovém souboru v nestálém médiu. Obvykle je způsoben chybnou nebo chybnou konfigurací zásobníku úložiště (softwaru nebo hardwaru). Klientské aplikace můžou obdržet chybu JET_errReadLostFlushVerifyFailure z funkcí ESE, které vyžadují čtení dat z databáze, pokud jsou data umístěná v oblasti, u které došlo ke ztrátě události zápisu.

2 Schopnost detekovat ztracené zápisy v průběhu životnosti procesu byla přítomna od windows 8 (klienta) a Windows Serveru 2012 (server).

  • Last updated on