Condividi tramite

File del motore di archiviazione estendibili

si applica a: Windows | Windows Server

File del motore di archiviazione estendibili

Il motore di archiviazione estendibile usa i tipi di file seguenti:

Questa tabella contiene una panoramica dei nomi di file di dati gestiti da ESE. Per Windows Vista e versioni successive, l'impostazione JET_paramLegacyNames influisce sui nomi di file usati.

Etichetta Valore

File di log delle transazioni

I file di log delle transazioni contengono operazioni sui file di database. Contengono informazioni sufficienti per portare un database a uno stato coerente logicamente dopo la chiusura imprevista del processo o l'arresto del sistema.

I nomi dei file di log dipendono da un nome di base a tre lettere, che può essere impostato con JET_paramBaseName. Gli esempi seguenti usano un nome di base "edb", perché è il nome di base predefinito. L'estensione per i file di log delle transazioni sarà .log o jtx a seconda che il JET_bitESE98FileNames sia impostato nel parametro JET_paramLegacyFileNames. Per altre informazioni, vedere parametri di sistema del motore di archiviazione estendibili.

I file di log delle transazioni sono denominati <>.log numero di generazione di base><, a partire da 1. Il numero di generazione del log è in formato esadecimale. Ad esempio, edb00001.log è il primo log e edb000ff.log è il 255° log. I file di log hanno cinque cifre esadecimali nel nome del file di log, fino al file di log 1048576th, a questo punto i file di log iniziano a essere denominati in un formato 11.3 (ad esempio, edb00100000.log). < >.log di base è sempre il file di log attualmente in uso. Se il motore di database non è attivo, è possibile identificare la generazione di edb.log usando il comando seguente: esentutl.exe -ml edb.log.

Anche se i file di log delle transazioni hanno . L'estensione LOG comunemente associata ai file di testo, i file di log delle transazioni sono in formato binario e non devono mai essere modificati da un utente. Le operazioni di database vengono scritte prima nel log. I dati possono essere scritti nel file di database in un secondo momento; possibilmente immediatamente, potenzialmente molto più tardi. In caso di interruzione imprevista del processo o del sistema, le operazioni sono ancora presenti nei file di log e è possibile eseguire il rollback delle transazioni incomplete. L'azione di riproduzione dei file di log delle transazioni viene chiamata ripristino softwaree viene eseguita automaticamente quando viene chiamato JetInit o JetInit2. Il ripristino software può essere eseguito manualmente anche con l'opzione "-r" del programma Esentutl.exe. L'azione di riproduzione dei file di log delle transazioni in un database ripristinato da un backup viene chiamata ripristino rigido.

I file di log sono di dimensioni fisse, personalizzabili con JET_paramLogFileSize. Quando viene compilato il file di log corrente, ovvero edb.log, viene rinominato in <>.log numero di generazione di base><e nel flusso di log delle transazioni è necessario un nuovo file di log delle transazioni.

A ogni istanza del database è associata una singola sequenza di file di log. Windows XP ha introdotto JetCreateInstance, consentendo l'uso di più sequenze di file di log delle transazioni da un singolo processo. Tuttavia, nella stessa directory non possono esistere più sequenze di file di log delle transazioni.

I file di log delle transazioni non devono essere quasi mai modificati manualmente, rinominati, spostati o eliminati perché il danneggiamento dei dati può comportare il danneggiamento dei dati.

I file di log delle transazioni verranno eliminati dal motore di database durante un backup completo (vedere JetBackup, JetTruncateLog, JetTruncateLogInstance) o durante le normali operazioni, se è abilitata la registrazione circolare.

Dopo aver compilato un file di log delle transazioni, il motore di database deve creare un nuovo file di log. La registrazione circolare è un mezzo per cui i file di log possono essere puliti automaticamente dal motore di database quando non sono più necessari per il ripristino di arresto anomalo del sistema. Questo processo è un'alternativa alla rimozione dei file di log come prodotto per l'esecuzione di un backup. La registrazione circolare può essere controllata con il parametro di sistema JET_paramCircularLog. I file di log delle transazioni non devono essere eliminati usando altri metodi.

File di log delle transazioni temporanei

Quando edb.log riempie, ESE deve creare un nuovo file. Il nuovo file di transazione di log è noto come file di log delle transazioni temporaneo prima dell'uso da parte di ESE.

Mentre viene creato un nuovo file di log e le relative dimensioni estese, verrà chiamato <base>tmp.log. La creazione di un nuovo file può essere un'operazione potenzialmente costosa, quindi ESE creerà il file di log successivo in modo proattivo come attività in background.

Poiché il file di log delle transazioni temporaneo viene creato in previsione della necessità di un nuovo file di log delle transazioni, non contiene informazioni utili.

File di log delle transazioni riservati

I file di log delle transazioni riservati vengono creati all'avvio del motore per consentire la registrazione di operazioni importanti per ottenere un arresto pulito.

Windows Vista: in Windows Vista e versioni successive, i file di log delle transazioni riservati sono denominati <base>RESXXXXX.jrs.

Windows Server 2003: in Windows Server 2003 e versioni precedenti, i file di log delle transazioni riservati sono denominati res1.log e res2.log.

Quando il motore di database esaurisce lo spazio su disco, non può creare un nuovo file di log. La cosa più sicura da fare è arrestare in modo pulito, ma alcune operazioni (ad esempio le operazioni di rollback) devono comunque essere registrate. La maggior parte delle operazioni di database avrà esito negativo durante questa fase.

Poiché i file di log delle transazioni riservati vengono creati in previsione della necessità di file di log delle transazioni in uno scenario out-of-disk, non contengono informazioni utili.

File del checkpoint

Il file del checkpoint archivia il checkpoint per una particolare sequenza di file di log delle transazioni. Il file del checkpoint è denominato <base>.chk o <base>.jcp, a seconda che il JET_bitESE98FileNames sia impostato nel parametro JET_paramLegacyFileNames e il relativo percorso venga assegnato da JET_paramSystemPath.

Le operazioni di database vengono prima scritte nei file di log e quindi memorizzate nella cache in memoria. A un certo punto, le operazioni vengono scritte nel file di database, ma per motivi di prestazioni, l'ordine in cui le operazioni vengono scritte nel file di database potrebbe non corrispondere all'ordine in cui sono stati originariamente registrati. Le operazioni scritte nel file di log delle transazioni saranno in uno dei due stati seguenti:

  • Scritto nel file di log delle transazioni e nel file di database.

  • Scritto nel file di log delle transazioni e non ancora scritto nel file di database.

Molte operazioni di database possono essere archiviate in un singolo file di log delle transazioni. Un determinato file di log può essere costituito dagli elementi seguenti:

  • Tutte le operazioni scritte nel file di database.

  • Nessuna operazione scritta nel file di database

  • Combinazione di operazioni scritte nel file di database e operazioni non ancora scritte nel file di database.

Il checkpoint fa riferimento al punto nel tempo nel flusso del log delle transazioni in cui tutte le operazioni precedenti al checkpoint sono state scritte nel file di database. Non esiste alcuna garanzia sulle operazioni che si verificano dopo il checkpoint; alcuni potrebbero essere in memoria e alcuni potrebbero essere scritti nel database.

Poiché tutte le operazioni nei file di log precedenti al checkpoint vengono rappresentate nel file di database, solo i file di log delle transazioni dopo il checkpoint sono necessari per il ripristino software per portare un determinato database in uno stato pulito.

File di database

Il file di database contiene lo schema per tutte le tabelle del database, i record per tutte le tabelle del database e gli indici delle tabelle. La posizione viene assegnata usando JetCreateDatabase, JetCreateDatabase2, JetAttachDatabaseo JetAttachDatabase2.

Un database viene arrestato correttamente solo dopo una chiamata riuscita a JetTerm o JetTerm2.

Il programma Esentutl.exe può rilevare se un database viene arrestato correttamente con l'opzione "-mh". Ad esempio, "esentutl.exe -mh sample.edb" leggerà l'intestazione del database di un database denominato sample.edb e visualizzerà lo stato di sample.edb. Può stampare "State: Clean Shutdown" o "State: Dirty Shutdown".

Un database che non è stato arrestato correttamente è in uno stato di arresto dirty. Prima di Windows XP, questo stato è stato chiamato incoerente. Un database dirty (incoerente) può essere portato a uno stato pulito con ripristino flessibile. Un database danneggiato non corrisponde a un database dirty ("incoerente").

Un database danneggiato fa riferimento a un danneggiamento fisico o logico e non può essere corretto con il ripristino software. I danneggiamenti fisici possono essere capovolgimenti di bit, che vengono spesso rilevati dai checksum nelle pagine del database. Un checksum non riuscito in un file di database si manifesta come errore JET_errReadVerifyFailure.

È possibile spostare o rinominare in modo sicuro solo i database arrestati in modo pulito. Se un database non è stato arrestato correttamente, non può essere spostato o rinominato automaticamente.

È possibile associare più database a una singola sequenza di file di log delle transazioni.

Database temporanei

Il database temporaneo viene usato come archivio di backup per i tentabili e viene usato anche durante la creazione di indici.

Il nome e il percorso sono configurati con JET_paramTempPath.

I tentabili vengono creati con JetOpenTempTable, JetOpenTempTable2, JetOpenTempTable3, JetOpenTemporaryTable. Vengono create anche da alcune chiamate API e usate per restituire informazioni sullo schema, ad esempio JetGetIndexInfo).

Scaricare i file di mapping

A partire dall'aggiornamento dell'anniversario di Windows 10 (client) e Windows Server 2016 (server), ESE ha aggiunto un ulteriore livello di protezione dalle scritture perse (o dagli scaricamenti persi) 1, consentendo di rilevare tali eventi di reinizializzazione tra processi2. Questa funzionalità richiede la persistenza dei metadati in un file separato denominato file "flush map".

Viene creato un file di mappa di scaricamento per ogni file di database e si trova nella stessa directory. Il file è denominato in modo analogo al file di database, ma con un'estensione diversa. Ad esempio, se l'applicazione client crea un database con il percorso completo C:\MyDirectory\MyDabatase.edb, il file della mappa di scaricamento corrispondente è C:\MyDirectory\MyDabatase.jfm.

Questo miglioramento introduce due requisiti per il modo in cui i file di database devono essere denominati:

  • Due database nella stessa directory non devono avere lo stesso nome file con estensioni diverse. Ad esempio: C:\MyDirectory\MyDabatase.db1 e C:\MyDirectory\MyDabatase.db2.

  • 2. Un database non deve avere un'estensione .jfm.

Quando si copia o si sposta manualmente un file di database, il file della mappa di scaricamento corrispondente deve anche essere copiato o spostato nella stessa directory di destinazione. Se un file di mapping di scaricamento non è presente al momento di un nuovo allegato di database (tramite JetAttachDatabase, ne verrà creato uno nuovo e popolato nuovamente su richiesta man mano che le pagine vengono lette dal database. La combinazione di file di mapping non corrispondenti e scaricamento viene gestita da ESE e forza l'eliminazione e la ricreazione della mappa di scaricamento non corrispondente da zero.

Le dimensioni di un file di mappa di scaricamento sono direttamente proporzionali al file di database associato e approssimativamente uguali a (tutte le dimensioni in byte, il risultato deve essere arrotondato al multiplo successivo di 8.192):

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

Ad esempio: per un database da 1,5 GB con dimensioni di pagina da 32 KB, la dimensione approssimativa della mappa di scaricamento è di 24.576 byte (o 24 KB).

Il file della mappa di scaricamento deve essere aggiornato quando le pagine del database vengono scaricate. Se la registrazione transazionale è abilitata( ad esempio, JET_paramRecovery impostata su "on", l'aggiornamento predefinito della mappa di scaricamento viene eseguito quando l'applicazione client apporta modifiche al database. In media, l'intera mappa di scaricamento viene scritta nel supporto non volatile una volta per ogni 20% di JET_paramCheckpointDepthMax -worth (in byte) di log transazionali generati. Il numero di operazioni di scrittura dipende dal modo in cui vengono distribuite nel database le modifiche. Ma è al massimo, approssimativamente (tutte le dimensioni in byte):

<flush map file size> / JET_paramMaxCoalesceWriteSize

Se la registrazione transazionale è disabilitata (ad esempio, JET_paramRecovery impostata su "off"), la mappa di scaricamento viene aggiornata solo una volta quando il database viene scollegato in modo esplicito (tramite JetDetachDatabaseo scollegato in modo implicito terminando l'istanza ESE associata (tramite una delle funzioni JetTerm, purché non venga passato JET_bitTermDirty).

1 Una scrittura persa (o scaricamento perso) viene definita come operazione di scrittura che restituisce correttamente dal sistema operativo al motore di database ESE, ma i dati effettivi non vengono mai salvati in modo permanente nel file di database nel supporto non volatile. In genere è causato da un malfunzionamento o da uno stack di archiviazione non configurato correttamente (software o hardware). Le applicazioni client possono ricevere un errore di JET_errReadLostFlushVerifyFailure dalle funzioni ESE che richiedono la lettura dei dati dal database se i dati si trovano in un'area che ha subito un evento di scrittura perso.

2 La possibilità di rilevare le scritture perse all'interno della durata di un processo è stata presente a partire da Windows 8 (client) e Windows Server 2012 (server).