Fichiers du moteur de stockage extensibles
S’applique à : Windows | Windows Server
Fichiers du 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 a un impact sur les noms de fichiers utilisés.
| Étiquette | Valeur |
|---|---|
Fichiers journaux des transactions
Les fichiers journaux des 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 de stockage extensible.
Les fichiers journaux des transactions sont nommés <base><generation-number.log>, 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 cas les fichiers journaux commencent à être nommés au format 11.3 (par exemple, edb00100000.log). <base.log> est toujours le fichier journal actuellement utilisé. Si le moteur de base de données n’est pas actif, la génération de 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 . Extension LOG couramment 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 ultérieurement dans le fichier de base de données ; peut-être immédiatement, potentiellement beaucoup plus tard. En cas d’arrêt inattendu du processus ou du système, les opérations sont toujours présentes dans les fichiers journaux et les transactions incomplètes peuvent être restaurées. L’action de relecture des fichiers journaux des transactions est appelée récupération réversible, et elle est effectuée 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. Le fait de relire les fichiers journaux des transactions sur une base de données restaurée à partir d’une sauvegarde est appelé récupération matérielle.
Les fichiers journaux sont de taille fixe, personnalisables avec JET_paramLogFileSize. Lorsque le fichier journal actuel (c’est-à-dire <edb.log) est rempli, il est renommé en numéro> de génération de base.log><, et un nouveau fichier journal des transactions est nécessaire dans le flux du journal des transactions.
Une seule séquence de fichiers journaux est associée à chaque instance de base de données. Windows XP a introduit JetCreateInstance, permettant l’utilisation de 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, renommés, déplacés ou supprimés manuellement, car une altération des données peut en résulter.
Les fichiers journaux des transactions seront 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 sur incident. Ce processus est une alternative à la suppression des fichiers journaux en tant que sous-produit de l’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 de transactions de journal est appelé fichier journal des transactions temporaire avant son utilisation par ESE.
Lorsqu’un fichier journal est créé et que sa taille est étendue, il est appelé <tmp.log de base>. La création d’un fichier peut être une opération potentiellement coûteuse. Par conséquent, ESE crée 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 pas d’informations utiles.
Fichiers journaux des transactions réservés
Les fichiers journaux des transactions réservés sont créés lorsque le moteur démarre pour permettre la journalisation des opérations importantes afin d’obtenir un arrêt propre.
Windows Vista : Dans Windows Vista et versions ultérieures, les fichiers journaux des transactions réservés sont nommés <RESXXXXX.jrs de base>.
Windows Server 2003 : Dans Windows Server 2003 et versions antérieures, les fichiers journaux des transactions réservés 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 de s’arrêter proprement, 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 de la nécessité de fichiers journaux des transactions dans un scénario hors disque, ils ne contiennent pas d’informations utiles.
fichiers de point de contrôle
Le fichier de point de contrôle stocke le point de contrôle pour une séquence de fichier journal des 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 indiqué 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é journalisées à l’origine. Les opérations écrites dans le fichier journal des transactions seront 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 pas 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 d’opérations non encore é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 concernant les opérations qui se produisent après le point de contrôle ; certains peuvent être en mémoire et d’autres 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 place 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 indiqué à 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 s’afficher « État : Arrêt de nettoyage » ou « État : Arrêt incorrect ».
Une base de données qui n’a pas été correctement arrêtée est dans un état d’arrêt sale. Avant Windows XP, cet état était appelé incohérent. Une base de données sale (incohérente) peut être mise à l’état propre avec une récupération réversible. Une base de données endommagée n’est pas identique à une base de données sale (« 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 sont fréquemment interceptés par les sommes de contrôle sur les pages de la base de données. Une somme de contrôle ayant échoué dans un fichier de base de données se manifeste comme une erreur de JET_errReadVerifyFailure.
Seules les bases de données qui s’arrêtent correctement peuvent être déplacées ou renommées en toute sécurité. Si une base de données n’a pas été correctement arrêtée, elle ne peut pas être automatiquement déplacée ou renommée en toute sécurité.
Plusieurs bases de données peuvent être associées à une seule séquence de fichiers journaux des transactions.
Bases de données temporaires
La base de données temporaire est utilisée comme magasin de stockage pour les tables temporaires 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 tables temporaires sont créées 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).
Vidage des fichiers de carte
À 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 les vidages perdus) 1, ce qui lui permet de détecter ces événements de réinitialisation inter-processus2. Cette fonctionnalité nécessite la persistance des métadonnées dans un fichier distinct appelé fichier « carte de vidage ».
Un fichier de carte 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 manière 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 de carte vide correspondant est C:\MyDirectory\MyDabatase.jfm.
Cette amélioration introduit deux conditions requises pour le nom des fichiers de base de données :
Deux bases de données du même répertoire ne doivent pas avoir le même nom de fichier avec des extensions différentes. 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 de carte de vidage correspondant doit également être copié ou déplacé vers le même répertoire de destination. Si un fichier de carte de vidage n’est pas présent au moment de la nouvelle pièce jointe de base de données (via JetAttachDatabase), un nouveau fichier est créé et rempli à la demande à mesure que les pages sont lues à partir de la base de données. Le mélange de fichiers de base de données incompatibles et de carte de vidage est géré par ESE et force la suppression et la recréation de la carte de vidage incompatible.
La taille d’un fichier de carte de vidage 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 utilisant une taille de page de 32 Ko, la taille approximative de la carte de vidage est de 24 576 octets (ou 24 Ko).
Le fichier de carte de vidage doit être actualisé à mesure que les pages de base de données sont vidées. Si la journalisation transactionnelle est activée (par exemple, JET_paramRecovery définie sur « on », 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, l’intégralité de la carte de vidage est écrite sur le média 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 il est au plus, approximativement (toutes tailles en octets) :
<flush map file size> / JET_paramMaxCoalesceWriteSize
Si la journalisation transactionnelle est désactivée (par exemple, JET_paramRecovery définie sur « off »), la carte de vidage n’est actualisée qu’une seule fois lorsque la base de données est explicitement détachée proprement (via JetDetachDatabase, ou implicitement détachée proprement en mettant fin à son instance ESE associé (via l’une des fonctions JetTerm, tant que JET_bitTermDirty n’est pas passé).
1 Une écriture perdue (ou vidage perdu) est définie comme une opération d’écriture qui retourne correctement du système d’exploitation vers le 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 support 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 est présente depuis Windows 8 (client) et Windows Server 2012 (serveur).