File del motore di archiviazione estendibile
Si applica a: Windows | Windows Server
File del motore di archiviazione estendibile
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 in modo logico dopo la chiusura di un processo imprevisto 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é corrisponde al nome di base predefinito. L'estensione per i file di log delle transazioni sarà con estensione log o jtx a seconda che il JET_bitESE98FileNames sia impostato nel parametro JET_paramLegacyFileNames. Per altre informazioni, vedere Extensible Storage Engine System Parameters.For more information, see Extensible Storage Engine System Parameters.
I file di log delle transazioni sono denominati <><base generation-number.log>, 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 quel punto i file di log iniziano a essere denominati in un formato 11.3 (ad esempio, edb00100000.log). <base.log> è 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 per prime 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 il rollback delle transazioni incomplete può essere eseguito. L'azione di riproduzione dei file di log delle transazioni è detta ripristino software e 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 è detta ripristino rigido.
I file di log sono di dimensioni fisse, personalizzabili con JET_paramLogFileSize. Quando il file di log corrente , ovvero edb.log, viene compilato, viene rinominato <><in base generation-number.log> e nel flusso del 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 parte di 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ò causare 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 utilizzando altri metodi.
File di log delle transazioni temporanei
Quando edb.log si 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 <tmp.log di base>. La creazione di un nuovo file può essere un'operazione potenzialmente costosa, pertanto 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 <>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 correttamente, 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 determinata 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 state originariamente registrate. 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 le 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 sono rappresentate nel file di database, solo i file di log delle transazioni dopo il checkpoint sono necessari per il ripristino software per portare un database specifico 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 sulle tabelle. La posizione viene assegnata usando JetCreateDatabase, JetCreateDatabase2, JetAttachDatabase o JetAttachDatabase2.
Un database viene arrestato correttamente solo dopo una chiamata 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 software. 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.
Solo i database arrestati in modo pulito possono essere spostati o rinominati in modo sicuro. 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 creati anche da alcune chiamate API e usate per restituire informazioni sullo schema, ad esempio JetGetIndexInfo.
Scarica file di mapping
A partire dall'aggiornamento dell'anniversario Windows 10 (client) e Windows Server 2016 (server), ESE ha aggiunto un livello aggiuntivo di protezione dalle scritture perse (o dagli scaricamenti persi) 1, consentendo di rilevare tali eventi di ri-inizializzazione interprocesso2. Questa funzionalità richiede la persistenza dei metadati in un file separato denominato file "flush map".
Viene creato un file di mapping di scaricamento per ogni file di database e si trova nella stessa directory. Il nome del file è simile 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 di 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, anche il file di mappa di scaricamento corrispondente deve essere copiato o spostato nella stessa directory di destinazione. Se un file di mapping scaricato 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.
Le dimensioni di un file di mapping 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, le dimensioni approssimative della mappa di scaricamento sono pari a 24.576 byte (o 24 KB).
Il file di mappa scaricamento deve essere aggiornato quando le pagine del database vengono scaricate. Se la registrazione transazionale è abilitata (ad esempio, JET_paramRecovery impostata su "on", l'impostazione predefinita), l'aggiornamento 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 una sola volta quando il database viene disconnesso in modo esplicito (tramite JetDetachDatabase o scollegato in modo implicito terminando l'istanza di ESE associata tramite una qualsiasi 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 è presente da Windows 8 (client) e Windows Server 2012 (server).