Dela via

Utökningsbara lagringsmotorfiler

gäller för: Windows | Windows Server

Utökningsbara lagringsmotorfiler

Extensible Storage Engine använder följande typer av filer:

Den här tabellen innehåller en översikt över de datafilnamn som hanteras av ESE. För Windows Vista och senare påverkar inställningen JET_paramLegacyFileNames filnamnen som används.

Filtyp Äldre namn (JET_bitESE98FileNames) Moderna namn (standard)
Transaktionsloggfiler <bas>.log, <bas>XXXXX.log <base.jtx>, <base>XXXXX.jtx
Temporär transaktionslogg <bas>tmp.log <base>tmp.jtx
Reserverade transaktionsloggfiler res1.log, res2.log (Windows Server 2003 och tidigare) <base>RESXXXXX.jrs (Windows Vista och senare)
Kontrollpunktsfiler <base.chk> <base.jcp>
Databasfiler Användardefinerad (t.ex. .edb) Användardefinerad (t.ex. .edb)
Tillfälliga databaser Användaren har angetts via JET_paramTempPath Användaren har angetts via JET_paramTempPath
Rensa mappningsfiler N/A <database.jfm> (Windows 10 Anniversary Update och senare)

Transaktionsloggfiler

Transaktionsloggfiler innehåller åtgärder på databasfiler. De innehåller tillräckligt med information för att föra en databas till ett logiskt konsekvent tillstånd efter en oväntad processavslutning eller systemavstängning.

Namnen på loggfilerna är beroende av ett basnamn med tre bokstäver som kan anges med JET_paramBaseName. I exemplen nedan används basnamnet "edb", eftersom det är standardbasnamnet. Tillägget för transaktionsloggfilerna är antingen .log eller .jtx beroende på om JET_bitESE98FileNames anges i parametern JET_paramLegacyFileNames. Mer information finns i Utökningsbara systemparametrar för lagringsmotorn.

Transaktionsloggfiler namnges <bas><generationsnummer>.log, från och med 1. Logggenereringsnumret är i hexadecimalt format. Till exempel är edb00001.log den första loggen och edb000ff.log är den 255:e loggen. Loggfilerna har fem hexadecimala siffror i loggfilens namn fram till den 1048576:e loggfilen, då loggfilerna börjar namnges i ett 11,3-format (till exempel edb00100000.log). <grundläggande>.log är alltid loggfilen som används för närvarande. Om databasmotorn inte är aktiv kan genereringen av edb.log identifieras med hjälp av följande kommando: esentutl.exe -ml edb.log.

Även om transaktionsloggfilerna har . LOG-tillägget är ofta associerat med textfiler, transaktionsloggfiler är i binärt format och bör aldrig redigeras av en användare. Databasåtgärder skrivs först till loggen. Data kan skrivas till databasfilen senare. möjligen omedelbart, potentiellt mycket senare. I händelse av oväntad process eller systemavslut finns åtgärderna fortfarande i loggfilerna och ofullständiga transaktioner kan återställas. Åtgärden att spela upp transaktionsloggfiler kallas mjuk återställning, och det görs automatiskt när JetInit eller JetInit2 anropas. Mjuk återställning kan också utföras manuellt med alternativet "-r" i Esentutl.exe-programmet. Åtgärden att spela upp transaktionsloggfiler på en databas som återställs från en säkerhetskopia kallas hård återställning.

Loggfiler har en fast storlek som kan anpassas med JET_paramLogFileSize. När den aktuella loggfilen (d.v.s. edb.log) fylls i byter den namn till <bas><generationsnummer>.log och en ny transaktionsloggfil behövs i transaktionsloggströmmen.

Varje databasinstans har en enda loggfilsekvens associerad med den. Windows XP introducerade JetCreateInstance, vilket gör att flera transaktionsloggfilsekvenser kan användas av en enda process. Flera transaktionsloggfilsekvenser kan dock inte finnas i samma katalog.

Transaktionsloggfiler bör nästan aldrig manipuleras manuellt, byta namn, flyttas eller tas bort eftersom skadade data kan uppstå.

Transaktionsloggfiler tas bort av databasmotorn under en fullständig säkerhetskopiering (se JetBackup, JetTruncateLog, JetTruncateLogInstance), eller under normala åtgärder, om cirkulär loggning är aktiverat.

När en transaktionsloggfil har fyllts i måste databasmotorn skapa en ny loggfil. Cirkulär loggning är ett sätt på vilket loggfiler automatiskt kan rensas av databasmotorn när de inte längre krävs för kraschåterställning. Den här processen är ett alternativ till att ta bort loggfiler som en biprodukt för att utföra en säkerhetskopia. Cirkulär loggning kan styras med JET_paramCircularLog-systemparametern. Transaktionsloggfiler bör inte tas bort med någon annan metod.

Temporära transaktionsloggfiler

När edb.log fylls måste ESE skapa en ny fil. Den nya loggtransaktionsfilen kallas för en tillfällig transaktionsloggfil innan den används av ESE.

När en ny loggfil skapas och dess storlek utökas kallas den <bas>tmp.log. Att skapa en ny fil kan vara en potentiellt kostsam åtgärd, så ESE skapar nästa loggfil proaktivt som en bakgrundsaktivitet.

Eftersom den tillfälliga transaktionsloggfilen skapas i väntan på behov av en ny transaktionsloggfil innehåller den ingen användbar information.

Reserverade transaktionsloggfiler

De reserverade transaktionsloggfilerna skapas när motorn börjar tillåta att viktiga åtgärder loggas för att få en ren avstängning.

Windows Vista: I Windows Vista och senare namnges de reserverade transaktionsloggfilerna <bas>RESXXXXX.jrs.

Windows Server 2003: I Windows Server 2003 och tidigare heter De reserverade transaktionsloggfilerna res1.log och res2.log.

När databasmotorn får slut på diskutrymme kan den inte skapa en ny loggfil. Det säkraste är att stänga av rent, men vissa åtgärder (till exempel återställningsåtgärder) måste fortfarande loggas. De flesta databasåtgärder misslyckas under den här fasen.

Eftersom de reserverade transaktionsloggfilerna skapas i väntan på behov av transaktionsloggfiler i ett scenario utan disk innehåller de ingen användbar information.

Kontrollpunktsfiler

Kontrollpunktsfilen lagrar kontrollpunkten för en viss transaktionsloggfilsekvens. Kontrollpunktsfilen heter <base>.chk eller <base>.jcp, beroende på om JET_bitESE98FileNames anges i parametern JET_paramLegacyFileNames och dess plats anges av JET_paramSystemPath.

Databasåtgärder skrivs först till loggfilerna och cachelagras sedan i minnet. Vid ett senare tillfälle skrivs åtgärderna till databasfilen, men av prestandaskäl kanske inte ordningen i vilken åtgärder skrivs till databasfilen matchar den ordning i vilken de ursprungligen loggades. Åtgärder som skrivs till transaktionsloggfilen är i något av två tillstånd:

  • Skrivs till transaktionsloggfilen och databasfilen.

  • Skrivs till transaktionsloggfilen och har ännu inte skrivits till databasfilen.

Många databasåtgärder kan lagras i en enda transaktionsloggfil. En viss loggfil kan bestå av följande objekt:

  • Alla åtgärder som skrivits till databasfilen.

  • Inga åtgärder har skrivits till databasfilen

  • En blandning av åtgärder som skrivits till databasfilen och åtgärder som ännu inte skrivits till databasfilen.

Kontrollpunkten refererar till tidpunkten i transaktionsloggströmmen där alla åtgärder före kontrollpunkten har skrivits till databasfilen. Det finns ingen garanti för de åtgärder som inträffar efter kontrollpunkten. vissa kan finnas i minnet och vissa kan skrivas till databasen.

Eftersom alla åtgärder i loggfilerna före kontrollpunkten representeras i databasfilen är det bara transaktionsloggfilerna efter kontrollpunkten som behövs för mjuk återställning för att få en viss databas i ett rent tillstånd.

Databasfiler

Databasfilen innehåller schemat för alla tabeller i databasen, posterna för alla tabeller i databasen och indexen över tabellerna. Platsen anges med hjälp av JetCreateDatabase, JetCreateDatabase2, JetAttachDatabaseeller JetAttachDatabase2.

En databas stängs endast av efter ett lyckat anrop till JetTerm eller JetTerm2.

Det Esentutl.exe programmet kan identifiera om en databas stängs av med alternativet "-mh". "esentutl.exe -mh sample.edb" läser till exempel databasrubriken för en databas med namnet sample.edb och skriver ut tillståndet för sample.edb. Det kan skriva ut "State: Clean Shutdown" eller "State: Dirty Shutdown".

En databas som inte har stängts av är i ett felaktigt avstängningstillstånd. Före Windows XP kallades det här tillståndet inkonsekvent. En felaktig (inkonsekvent) databas kan tas till ett rent tillstånd med mjuk återställning. En skadad databas är inte samma sak som en smutsig ("inkonsekvent") databas.

En skadad databas refererar till en fysisk eller logisk skada och kan inte åtgärdas med mjuk återställning. Fysiska skador kan vara bitvändningar, som ofta fångas av kontrollsummorna på databassidorna. En misslyckad kontrollsumma i en databasfil visas som ett JET_errReadVerifyFailure fel.

Det går bara att stänga av databaser på ett säkert sätt eller byta namn på dem. Om en databas inte stängdes av korrekt kan den inte flyttas eller byta namn automatiskt.

Flera databaser kan associeras med en enda transaktionsloggfilsekvens.

Tillfälliga databaser

Den tillfälliga databasen används som ett stödarkiv för frestande funktioner och används även när index skapas.

Namnet och platsen har konfigurerats med JET_paramTempPath.

Temptables skapas med JetOpenTempTable, JetOpenTempTable2, JetOpenTempTable3, JetOpenTemporaryTable. De skapas också av vissa API-anrop och används för att returnera schemainformation (till exempel JetGetIndexInfo).

Rensa mappningsfiler

Från och med Windows 10 Anniversary Update (klient) och Windows Server 2016 (server) har ESE lagt till ytterligare en skyddsnivå mot förlorade skrivningar (eller förlorade tömningar) 1, så att den kan identifiera sådana händelser korsprocessinitiering2. Den här funktionen kräver bevarade metadata till en separat fil som kallas för en "flush map"-fil.

En tömningsmappningsfil skapas för varje databasfil och finns i samma katalog. Filen heter på samma sätt som databasfilen, men med ett annat tillägg. Om klientprogrammet till exempel skapar en databas med den fullständiga sökvägen C:\MyDirectory\MyDabatase.edb är motsvarande tömningsmappningsfil C:\MyDirectory\MyDabatase.jfm.

Den här förbättringen introducerar två krav för hur databasfiler måste namnges:

  • Två databaser i samma katalog får inte ha samma filnamn med olika tillägg. Exempel: C:\MyDirectory\MyDabatase.db1 och C:\MyDirectory\MyDabatase.db2.

  • 2. En databas får inte ha ett .jfm-tillägg.

När du kopierar eller flyttar en databasfil manuellt bör motsvarande tömningsmappningsfil också kopieras eller flyttas till samma målkatalog. Om en tömningsmappningsfil inte finns vid tidpunkten för en ny databasbilaga (via JetAttachDatabaseskapas en ny och fylls på nytt på begäran när sidor läse in från databasen. Blandning av matchande databas- och tömningsmappningsfiler hanteras av ESE och tvingar den felmatchade tömningskartan att tas bort och återskapas från grunden.

Storleken på en tömningsmappningsfil är direkt proportionell mot dess associerade databasfil och ungefär lika med (alla storlekar i byte, resultatet måste avrundas upp till nästa multipel av 8 192):

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

Till exempel: för en 1,5 GB databas med en sidstorlek på 32 KB är den ungefärliga storleken på tömningskartan 24 576 byte (eller 24 KB).

Tömningsmappningsfilen måste uppdateras när databassidorna töms. Om transaktionsloggning är aktiverat (till exempel JET_paramRecovery inställt på "på", utförs standarduppdateringen av tömningskartan när klientprogrammet gör ändringar i databasen. I genomsnitt skrivs hela tömningskartan till det icke-flyktiga mediet en gång per 20% av JET_paramCheckpointDepthMax -worth (i byte) av transaktionsloggar som genereras. Antalet skrivåtgärder beror på hur distribuerade ändringarna är i databasen. Men det är som mest ungefär (alla storlekar i byte):

<flush map file size> / JET_paramMaxCoalesceWriteSize

Om transaktionsloggning är inaktiverad (till exempel JET_paramRecovery inställd på "off" uppdateras tömningskartan bara en gång när databasen uttryckligen kopplas från (via JetDetachDatabaseeller kopplas från implicit genom att dess associerade ESE-instans avslutas (via någon av JetTerm- funktioner, så länge JET_bitTermDirty inte skickas).

1 En förlorad skrivning (eller förlorad tömning) definieras som en skrivåtgärd som returneras från operativsystemet till ESE-databasmotorn, men de faktiska data sparas aldrig i databasfilen i det icke-flyktiga mediet. Det orsakas vanligtvis av en felaktig eller felkonfigurerad lagringsstack (programvara eller maskinvara). Klientprogram kan få ett JET_errReadLostFlushVerifyFailure fel från ESE-funktioner som kräver läsning av data från databasen om data finns i en region som genomgick en förlorad skrivhändelse.

2 Möjligheten att identifiera förlorade skrivningar under en processs livslängd har funnits sedan Windows 8 (klient) och Windows Server 2012 (server).