Fichiers de moteur de Stockage extensibles
S’applique à : Windows | serveur Windows
Fichiers de moteur de Stockage extensibles
Le moteur de Stockage extensible utilise les types de fichiers suivants :
Ce tableau contient une vue d’ensemble des noms de fichiers de données gérés par ESE. Pour Windows Vista et versions ultérieures, le paramètre JET_paramLegacyNames affecte les noms de fichiers utilisés.
| Étiquette | Value |
|---|---|
Fichiers journaux des transactions
Les fichiers journaux de transactions contiennent des opérations sur les fichiers de base de données. Ils contiennent suffisamment d’informations pour amener une base de données à un état logiquement cohérent après un arrêt inattendu du processus ou un arrêt du système.
Les noms des fichiers journaux dépendent d’un nom de base à trois lettres, qui peut être défini avec JET_paramBaseName. Les exemples ci-dessous utilisent un nom de base « edb », car il s’agit du nom de base par défaut. L’extension des fichiers journaux des transactions sera .log ou .jtx selon que le JET_bitESE98FileNames est défini dans le paramètre JET_paramLegacyFileNames. Pour plus d’informations, consultez Paramètres système du moteur extensible Stockage.
Les fichiers journaux de transactions sont nommés <basegeneration-number.log><>, en commençant par 1. Le numéro de génération du journal est au format hexadécimal. Par exemple, edb00001.log est le premier journal, et edb000ff.log est le 255e journal. Les fichiers journaux ont cinq chiffres hexadécimaux dans le nom du fichier journal, jusqu’au 1048576e fichier journal, auquel point les fichiers journaux commencent à être nommés au format 11.3 (par exemple, edb00100000.log). <base.log> est toujours le fichier journal en cours d’utilisation. Si le moteur de base de données n’est pas actif, la génération d’edb.log peut être identifiée à l’aide de la commande suivante : esentutl.exe -ml edb.log.
Bien que les fichiers journaux des transactions aient le . L’extension LOG généralement associée aux fichiers texte, les fichiers journaux des transactions sont au format binaire et ne doivent jamais être modifiés par un utilisateur. Les opérations de base de données sont d’abord écrites dans le journal. Les données peuvent être écrites dans le fichier de base de données ultérieurement ; peut-être immédiatement, potentiellement beaucoup plus tard. En cas de processus inattendu ou d’arrêt du système, les opérations sont toujours présentes dans les fichiers journaux, et les transactions incomplètes peuvent être restaurées. L’acte de relecture des fichiers journaux des transactions est appelé récupération réversible, et il est effectué automatiquement lorsque JetInit ou JetInit2 est appelé. La récupération réversible peut également être effectuée manuellement avec l’option « -r » du programme Esentutl.exe. L’acte de relecture des fichiers journaux des transactions sur une base de données restaurée à partir d’une sauvegarde est appelé récupération en dur.
Les fichiers journaux sont d’une taille fixe, personnalisable avec JET_paramLogFileSize. Lorsque le fichier journal actuel (autrement dit, edb.log) est rempli, il est renommé en <basegeneration-number.log>>< et un nouveau fichier journal des transactions est nécessaire dans le flux du journal des transactions.
Chaque instance de base de données dispose d’une séquence de fichiers journaux unique associée. Windows XP a introduit JetCreateInstance, ce qui permet d’utiliser plusieurs séquences de fichiers journaux de transactions par un seul processus. Toutefois, plusieurs séquences de fichiers journaux de transactions ne peuvent pas exister dans le même répertoire.
Les fichiers journaux des transactions ne doivent presque jamais être manipulés manuellement, renommés, déplacés ou supprimés, car une altération des données peut se produire.
Les fichiers journaux de transactions sont supprimés par le moteur de base de données pendant une sauvegarde complète (voir JetBackup, JetTruncateLog, JetTruncateLogInstance) ou pendant les opérations normales, si la journalisation circulaire est activée.
Une fois qu’un fichier journal des transactions est rempli, le moteur de base de données doit créer un fichier journal. La journalisation circulaire est un moyen par lequel les fichiers journaux peuvent être automatiquement nettoyés par le moteur de base de données lorsqu’ils ne sont plus nécessaires pour la récupération d’incident. Ce processus est une alternative à la suppression des fichiers journaux en tant que produit d’exécution d’une sauvegarde. La journalisation circulaire peut être contrôlée avec le paramètre système JET_paramCircularLog . Les fichiers journaux des transactions ne doivent pas être supprimés à l’aide d’une autre méthode.
Fichiers journaux des transactions temporaires
Lorsque edb.log se remplit, ESE doit créer un fichier. Le nouveau fichier transactionnel du journal est appelé fichier journal temporaire avant son utilisation par ESE.
Lorsqu’un fichier journal est créé et sa taille étendue, il est appelé <basetmp.log>. La création d’un fichier peut être une opération potentiellement coûteuse, ce qui permet à ESE de créer le fichier journal suivant de manière proactive en tant que tâche en arrière-plan.
Étant donné que le fichier journal des transactions temporaire est créé en prévision de la nécessité d’un nouveau fichier journal des transactions, il ne contient aucune information utile.
Fichiers journaux des transactions réservées
Les fichiers journaux des transactions réservés sont créés lorsque le moteur commence à autoriser les opérations importantes à journaliser pour obtenir un arrêt propre.
Windows Vista : Dans Windows Vista et versions ultérieures, les fichiers journaux des transactions réservées sont nommés <baseRESXXXXXXX.jrs>.
Windows Server 2003 : Dans Windows Server 2003 et versions antérieures, les fichiers journaux des transactions réservées sont nommés res1.log et res2.log.
Lorsque le moteur de base de données manque d’espace disque, il ne peut pas créer de fichier journal. La chose la plus sûre à faire est d’arrêter correctement, mais certaines opérations (telles que les opérations de restauration) doivent toujours être journalisées. La plupart des opérations de base de données échouent pendant cette phase.
Étant donné que les fichiers journaux des transactions réservés sont créés en prévision du besoin de fichiers journaux de transactions dans un scénario hors disque, ils ne contiennent aucune information utile.
fichiers de point de contrôle
Le fichier de point de contrôle stocke le point de contrôle pour une séquence de fichiers journaux de transactions particulière. Le fichier de point de contrôle est nommé <base.chk> ou <base.jcp>, selon que le JET_bitESE98FileNames est défini dans le paramètre JET_paramLegacyFileNames et que son emplacement est donné par JET_paramSystemPath.
Les opérations de base de données sont d’abord écrites dans les fichiers journaux, puis mises en cache en mémoire. À un moment donné, les opérations sont écrites dans le fichier de base de données, mais pour des raisons de performances, l’ordre dans lequel les opérations sont écrites dans le fichier de base de données peut ne pas correspondre à l’ordre dans lequel elles ont été enregistrées à l’origine. Les opérations écrites dans le fichier journal des transactions sont dans l’un des deux états suivants :
Écrit dans le fichier journal des transactions et le fichier de base de données.
Écrit dans le fichier journal des transactions et non encore écrit dans le fichier de base de données.
De nombreuses opérations de base de données peuvent être stockées dans un seul fichier journal des transactions. Un fichier journal donné peut se composer des éléments suivants :
Toutes les opérations écrites dans le fichier de base de données.
Aucune opération écrite dans le fichier de base de données
Combinaison d’opérations écrites dans le fichier de base de données et les opérations qui n’ont pas encore été écrites dans le fichier de base de données.
Le point de contrôle fait référence au point dans le temps dans le flux du journal des transactions où toutes les opérations antérieures au point de contrôle ont été écrites dans le fichier de base de données. Il n’existe aucune garantie sur les opérations qui se produisent après le point de contrôle; certains peuvent être en mémoire, et certains peuvent être écrits dans la base de données.
Étant donné que toutes les opérations dans les fichiers journaux avant le point de contrôle sont représentées dans le fichier de base de données, seuls les fichiers journaux des transactions après le point de contrôle sont nécessaires pour que la récupération réversible apporte une base de données particulière dans un état propre.
Fichiers de base de données
Le fichier de base de données contient le schéma de toutes les tables de la base de données, les enregistrements de toutes les tables de la base de données et les index sur les tables. Son emplacement est donné à l’aide de JetCreateDatabase, JetCreateDatabase2, JetAttachDatabase ou JetAttachDatabase2.
Une base de données est correctement arrêtée uniquement après un appel réussi à JetTerm ou JetTerm2.
Le programme Esentutl.exe peut détecter si une base de données est arrêtée correctement avec l’option « -mh ». Par exemple, « esentutl.exe -mh sample.edb » lit l’en-tête de base de données d’une base de données nommée sample.edb et imprime l’état de sample.edb. Il peut imprimer « State: Clean Shutdown » ou « State: Dirty Shutdown ».
Une base de données qui n’a pas été correctement arrêtée est dans un état d’arrêt incorrect. Avant Windows XP, cet état était appelé incohérent. Une base de données incorrecte (incohérente) peut être apportée à un état propre avec une récupération réversible. Une base de données endommagée n’est pas la même qu’une base de données incorrecte (« incohérente »).
Une base de données endommagée fait référence à une altération physique ou logique et ne peut pas être corrigée avec une récupération réversible. Les altérations physiques peuvent être des retournements de bits, qui seront fréquemment interceptés par les sommes de contrôle sur les pages de base de données. Une somme de contrôle ayant échoué dans un fichier de base de données se manifeste comme une erreur JET_errReadVerifyFailure.
Seuls les bases de données arrêtées proprement peuvent être déplacées ou renommées en toute sécurité. Si une base de données n’a pas été arrêtée correctement, elle ne peut pas être déplacée ou renommée automatiquement.
Plusieurs bases de données peuvent être associées à une séquence de fichiers journaux de transactions unique.
Bases de données temporaires
La base de données temporaire est utilisée comme magasin de stockage pour les temptables et elle est également utilisée lors de la création d’index.
Le nom et l’emplacement sont configurés avec JET_paramTempPath.
Les temptables sont créés avec JetOpenTempTable, JetOpenTempTable2, JetOpenTempTable3, JetOpenTemporaryTable. Ils sont également créés par certains appels d’API et utilisés pour retourner des informations de schéma (telles que JetGetIndexInfo).
Vider les fichiers map
À compter de la mise à jour anniversaire Windows 10 (client) et Windows Server 2016 (serveur), ESE a ajouté un niveau de protection supplémentaire contre les écritures perdues (ou vides perdues) 1, ce qui lui permet de détecter ces événements de re-initialisation inter-processus2. Cette fonctionnalité nécessite la persistance des métadonnées dans un fichier distinct appelé fichier « vider la carte ».
Un fichier map de vidage est créé pour chaque fichier de base de données et se trouve dans le même répertoire. Le fichier est nommé de la même façon que le fichier de base de données, mais avec une autre extension. Par exemple, si l’application cliente crée une base de données avec le chemin complet C:\MyDirectory\MyDabatase.edb, son fichier map de vidage correspondant est C:\MyDirectory\MyDabatase.jfm.
Cette amélioration présente deux exigences pour la façon dont les fichiers de base de données doivent être nommés :
Deux bases de données dans le même répertoire ne doivent pas avoir le même nom de fichier avec différentes extensions. Par exemple : C:\MyDirectory\MyDabatase.db1 et C:\MyDirectory\MyDabatase.db2.
2. Une base de données ne doit pas avoir d’extension .jfm.
Lorsque vous copiez ou déplacez manuellement un fichier de base de données, son fichier map de vidage correspondant doit également être, respectivement, copié ou déplacé vers le même répertoire de destination. Si un fichier de mappage vide n’est pas présent au moment d’une nouvelle pièce jointe de base de données (via JetAttachDatabase, un nouveau fichier sera créé et recréé à la demande lorsque les pages sont lues à partir de la base de données. Le mélange de fichiers de base de données et de mappage de vidage est géré par ESE et force la carte de vidage incompatible à supprimer et à recréer à partir de zéro.
La taille d’un fichier de mappage vide est directement proportionnelle à son fichier de base de données associé et approximativement égale à (toutes les tailles en octets, le résultat doit être arrondi au multiple suivant de 8 192) :
8,192 + ((<database file size> / <database page size>) / 4)
Par exemple : pour une base de données de 1,5 Go à l’aide d’une taille de page de 32 Ko, la taille approximative de la carte vide est de 24 576 octets (ou 24 Ko).
Le fichier map de vidage doit être actualisé lorsque les pages de base de données sont vidées. Si la journalisation transactionnelle est activée (par exemple, JET_paramRecovery définie sur « activé », la valeur par défaut), l’actualisation de la carte de vidage est effectuée lorsque l’application cliente apporte des modifications à la base de données. En moyenne, la carte de vidage entière est écrite sur le support non volatile une fois pour chaque 20 % de JET_paramCheckpointDepthMax -valeur (en octets) des journaux transactionnels générés. Le nombre d’opérations d’écriture dépend de la façon dont les modifications sont distribuées dans la base de données. Mais c’est au maximum, environ (toutes les tailles en octets) :
<flush map file size> / JET_paramMaxCoalesceWriteSize
Si la journalisation transactionnelle est désactivée (par exemple, JET_paramRecovery définie sur « désactivé »), la carte de vidage n’est actualisée qu’une seule fois lorsque la base de données est explicitement détachée (via JetDetachDatabase, ou détachée implicitement en terminant son instance ESE associée (via l’une des fonctions JetTerm , tant que JET_bitTermDirty n’est pas passée).
1 Une écriture perdue (ou vide) est définie comme une opération d’écriture qui retourne correctement du système d’exploitation au moteur de base de données ESE, mais les données réelles ne sont jamais conservées dans le fichier de base de données dans le média non volatile. Il est généralement dû à un dysfonctionnement ou à une pile de stockage mal configurée (logiciel ou matériel). Les applications clientes peuvent recevoir une erreur JET_errReadLostFlushVerifyFailure des fonctions ESE qui nécessitent la lecture des données de la base de données si les données se trouvent dans une région qui a subi un événement d’écriture perdu.
2 La possibilité de détecter les écritures perdues dans la durée de vie d’un processus a été présente depuis Windows 8 (client) et Windows Server 2012 (serveur).