Moteur de stockage extensible

Extensible Storage Engine ( ESE ), également connu sous le nom de JET Blue , est une technologie de stockage de données ISAM (méthode d'accès séquentiel indexé) de Microsoft . ESE est le cœur de Microsoft Exchange Server , d'Active Directory et de Windows Search . Il est également utilisé par un certain nombre de composants Windows, notamment le client Windows Update et le centre d'aide et de support . Son objectif est de permettre aux applications de stocker et de récupérer des données via un accès indexé et séquentiel.

ESE permet la mise à jour et la récupération des données traitées . Un mécanisme de récupération en cas de panne est fourni afin que la cohérence des données soit maintenue même en cas de panne du système. Les transactions dans ESE sont hautement simultanées, ce qui le rend adapté aux applications serveur. ESE met en cache les données de manière intelligente pour garantir un accès haute performance aux données. De plus, ESE est léger, ce qui le rend adapté aux applications auxiliaires.

Le runtime ESE (ESENT.DLL) est fourni avec toutes les versions de Windows depuis Windows 2000 , avec une version x64 native du runtime ESE fournie avec les versions x64 de Windows XP et Windows Server 2003. Jusqu'à Exchange 2003 , Microsoft Exchange était fourni uniquement avec l'édition 32 bits, car c'était la seule plate-forme prise en charge. Avec Exchange 2007 , il est fourni avec l'édition 64 bits.

Une base de données est à la fois un regroupement physique et logique de données. Une base de données ESE ressemble à un fichier unique pour Windows. En interne, la base de données est un ensemble de pages de 2, 4, 8, 16 ou 32 Ko (les options de page de 16 et 32 ​​Ko ne sont disponibles que dans Windows 7 et Exchange 2010), organisées dans une structure d'arbre B équilibrée . Ces pages contiennent des métadonnées pour décrire les données contenues dans la base de données, les données elles-mêmes, des index pour conserver les ordres intéressants des données et d'autres informations. Ces informations sont mélangées dans le fichier de base de données, mais des efforts sont faits pour garder les données utilisées ensemble regroupées dans la base de données. Une base de données ESE peut contenir jusqu'à 2 ³² pages, ou 16 téraoctets de données, pour des pages de 8 kilo-octets .

Les bases de données ESE sont organisées en groupes appelés instances. La plupart des applications utilisent une seule instance, mais toutes les applications peuvent également utiliser plusieurs instances. L'importance de l'instance réside dans le fait qu'elle associe une seule série de journaux de récupération à une ou plusieurs bases de données. Actuellement, jusqu'à 6 bases de données utilisateur peuvent être attachées à une instance ESE à tout moment. Chaque processus distinct utilisant ESE peut avoir jusqu'à 1 024 instances ESE.

Une base de données est portable dans le sens où elle peut être détachée d'une instance ESE en cours d'exécution et rattachée ultérieurement à la même instance ou à une autre instance en cours d'exécution. Lorsqu'elle est détachée, une base de données peut être copiée à l'aide des utilitaires Windows standard. La base de données ne peut pas être copiée lorsqu'elle est activement utilisée, car ESE ouvre exclusivement les fichiers de base de données. Une base de données peut résider physiquement sur n'importe quel périphérique pris en charge pour les opérations d'E/S directement adressables par Windows.

Une table est un ensemble homogène d'enregistrements, où chaque enregistrement possède le même ensemble de colonnes. Chaque table est identifiée par un nom de table, dont la portée est locale à la base de données dans laquelle la table est contenue. La quantité d'espace disque allouée à une table dans une base de données est déterminée par un paramètre donné lors de la création de la table avec l'opération CreateTable. Les tables s'agrandissent automatiquement en réponse à la création de données.

Les tables ont un ou plusieurs index. Il doit y avoir au moins un index groupé pour les données d'enregistrement. Lorsqu'aucun index groupé n'est défini par l'application, un index artificiel est utilisé pour classer et regrouper les enregistrements selon l'ordre chronologique d'insertion des enregistrements. Les index sont définis pour conserver les ordres de données intéressants et permettre à la fois un accès séquentiel aux enregistrements dans l'ordre d'index et un accès direct aux enregistrements par valeurs de colonne d'index. Les index groupés dans ESE doivent également être primaires, ce qui signifie que la clé d'index doit être unique.

Les index groupés et non groupés sont représentés à l'aide d'arbres B+ . Si une opération d'insertion ou de mise à jour provoque le débordement d'une page, la page est divisée : une nouvelle page est allouée et est logiquement enchaînée entre les deux pages précédemment adjacentes. Étant donné que cette nouvelle page n'est pas physiquement adjacente à ses voisines logiques, l'accès à celle-ci n'est pas aussi efficace. ESE dispose d'une fonction de compactage en ligne qui recompacte les données. Si une table doit être fréquemment mise à jour, de l'espace peut être réservé pour les insertions futures en spécifiant une densité de page appropriée lors de la création d'une table ou d'un index. Cela permet d'éviter ou de reporter les opérations de fractionnement.

Un enregistrement est un ensemble associé de valeurs de colonne. Les enregistrements sont insérés et mis à jour via des opérations de mise à jour et peuvent être supprimés via des opérations de suppression. Les colonnes sont définies et récupérées via les opérations SetColumns et RetrieveColumns, respectivement. La taille maximale d'un enregistrement est de 8 110 octets pour des pages de 8 kilo-octets, à l'exception des colonnes de valeurs longues. Les types de colonnes LongText et LongBinary ne contribuent pas de manière significative à cette limitation de taille, et les enregistrements peuvent contenir des données bien plus volumineuses qu'une taille de page de base de données lorsque les données sont stockées dans des colonnes de valeurs longues. Lorsqu'une référence de valeur longue est stockée dans un enregistrement, seuls 9 octets de données dans l'enregistrement sont nécessaires. Ces valeurs longues peuvent elles-mêmes atteindre une taille de 2 gigaoctets (Go).

Les enregistrements sont généralement uniformes dans le sens où chaque enregistrement possède un ensemble de valeurs pour le même ensemble de colonnes. Dans ESE, il est également possible de définir de nombreuses colonnes pour une table, tout en faisant en sorte qu'un enregistrement donné ne contienne qu'un petit nombre de valeurs de colonne non NULL. Dans ce sens, une table peut également être une collection d'enregistrements hétérogènes.

ESE prend en charge une large gamme de valeurs de colonnes, dont la taille varie de 1 bit à 2 Go. Il est important de choisir le bon type de colonne, car le type d'une colonne détermine de nombreuses de ses propriétés, notamment son ordre pour les index. Les types de données suivants sont pris en charge par ESE :

Chaque table ESE peut définir jusqu'à 127 colonnes de longueur fixe, 128 colonnes de longueur variable et 64 993 colonnes balisées.

• Les colonnes fixes sont essentiellement des colonnes qui occupent la même quantité d'espace dans chaque enregistrement, quelle que soit leur valeur. Les colonnes fixes occupent 1 bit pour représenter la nullité de la valeur de la colonne et une quantité fixe d'espace dans chaque enregistrement dans lequel cette colonne, ou une colonne fixe définie ultérieurement, est définie.
• Les colonnes variables sont essentiellement des colonnes qui occupent une quantité variable d'espace dans chaque enregistrement dans lequel elles sont définies, en fonction de la taille de la valeur de colonne particulière. Les colonnes variables occupent 2 octets pour déterminer la valeur NULL et la taille, et une quantité variable d'espace dans chaque enregistrement dans lequel cette colonne est définie.
• Les colonnes balisées sont des colonnes qui n'occupent aucun espace si elles ne sont pas définies dans un enregistrement. Elles peuvent être à valeur unique, mais peuvent également être à valeurs multiples. La même colonne balisée peut avoir plusieurs valeurs dans un seul enregistrement. Lorsque des colonnes balisées sont définies dans un enregistrement, chaque instance d'une colonne balisée occupe environ 4 octets d'espace en plus de la taille de la valeur d'instance de colonne balisée. Lorsque le nombre d'instances d'une seule colonne balisée est important, la surcharge par instance de colonne balisée est d'environ 2 octets. Les colonnes balisées sont idéales pour les colonnes éparses, car elles n'occupent aucun espace si elles ne sont pas définies. Si une colonne balisée à valeurs multiples est indexée, l'index contiendra une entrée pour l'enregistrement pour chaque valeur de la colonne balisée.

Pour une table donnée, les colonnes appartiennent à l'une des deux catégories suivantes : celles qui apparaissent exactement une fois dans chacun des enregistrements, avec éventuellement quelques valeurs NULL ; et celles qui apparaissent rarement ou qui peuvent avoir plusieurs occurrences dans un seul enregistrement. Les colonnes fixes et variables appartiennent à la première catégorie, tandis que les colonnes étiquetées appartiennent à la seconde. La représentation interne des deux catégories de colonnes est différente et il est important de comprendre les compromis entre les catégories de colonnes. Les colonnes fixes et variables sont généralement représentées dans chaque enregistrement, même lorsque l'occurrence a une valeur NULL. Ces colonnes peuvent être rapidement traitées via une table de décalage. Les occurrences de colonnes étiquetées sont précédées d'un identifiant de colonne et la colonne est localisée par une recherche binaire dans l'ensemble des colonnes étiquetées.

Les types de colonnes Long Text et Long Binary sont des objets binaires volumineux. Ils sont stockés dans un arbre B+ distinct de l'index groupé indexé par l'ID de valeur longue et le décalage d'octet. ESE prend en charge l'ajout, le remplacement de plage d'octets et la définition de taille pour ces colonnes. ESE dispose également d'une fonction de stockage d'instance unique où plusieurs enregistrements peuvent référencer le même objet binaire volumineux, comme si chaque enregistrement avait sa propre copie des informations, c'est-à-dire sans conflits de verrouillage entre enregistrements. La taille maximale d'une valeur de colonne Long Text ou Long Binary est de 2 Go.

Les colonnes de version sont automatiquement incrémentées par ESE chaque fois qu'un enregistrement contenant cette colonne est modifié via une opération de mise à jour. Cette colonne ne peut pas être définie par l'application, mais peut uniquement être lue. Les applications des colonnes de version incluent l'utilisation pour déterminer si une copie en mémoire d'un enregistrement donné doit être actualisée. Si la valeur d'un enregistrement de table est supérieure à la valeur d'une copie en cache, la copie en cache est réputée obsolète. Les colonnes de version doivent être de type Long.

Les colonnes d'incrémentation automatique sont définies automatiquement par ESE de telle sorte que la valeur contenue dans la colonne soit unique pour chaque enregistrement de la table. Ces colonnes, comme les colonnes de version, ne peuvent pas être définies par l'application. Les colonnes d'incrémentation automatique sont en lecture seule et sont définies automatiquement lorsqu'un nouvel enregistrement est inséré dans une table via une opération de mise à jour. La valeur de la colonne reste constante pendant toute la durée de vie de l'enregistrement et une seule colonne d'incrémentation automatique est autorisée par table. Les colonnes d'incrémentation automatique peuvent être de type Long ou de type Devise.

Les colonnes de dépôt peuvent être modifiées via une opération EscrowUpdate. Les mises à jour de dépôt sont des opérations delta numériques. Les colonnes de dépôt doivent être de type Long. Les exemples d'opérations delta numériques incluent l'ajout de 2 à une valeur ou la soustraction de 1 d'une valeur. ESE suit la modification d'une valeur plutôt que la valeur finale d'une mise à jour. Plusieurs sessions peuvent chacune avoir des modifications en suspens apportées via EscrowUpdate à la même valeur, car ESE peut déterminer la valeur finale réelle, quelles que soient les transactions validées et les transactions annulées. Cela permet à plusieurs utilisateurs de mettre à jour simultanément une colonne en effectuant des modifications delta numériques. En option, le moteur de base de données peut effacer les enregistrements avec une valeur nulle de la colonne. Une utilisation courante pour une telle colonne de dépôt est le compteur de référence : de nombreux threads incrémentent/décrémentent la valeur sans verrous, et lorsque le compteur atteint zéro, l'enregistrement est automatiquement supprimé.

Un index est un classement persistant des enregistrements d'une table. Les index sont utilisés à la fois pour l'accès séquentiel aux lignes dans l'ordre défini et pour la navigation directe dans les enregistrements en fonction des valeurs des colonnes indexées. L'ordre défini par un index est décrit en termes de tableau de colonnes, dans l'ordre de priorité. Ce tableau de colonnes est également appelé clé d'index. Chaque colonne est appelée segment d'index. Chaque segment d'index peut être ascendant ou descendant, en termes de contribution au classement. N'importe quel nombre d'index peut être défini pour une table. ESE fournit un ensemble complet de fonctionnalités d'indexation.

Un index peut être spécifié comme index groupé ou index primaire. Dans ESE, l'index groupé doit être unique et est appelé index primaire. Les autres index sont décrits comme des index non groupés ou index secondaires. Les index primaires sont différents des index secondaires dans la mesure où l'entrée d'index est l'enregistrement lui-même et non un pointeur logique vers l'enregistrement. Les index secondaires ont des clés primaires à leurs feuilles pour établir un lien logique vers l'enregistrement dans l'index primaire. En d'autres termes, la table est physiquement groupée dans l'ordre de l'index primaire. La récupération des données d'enregistrement non indexées dans l'ordre de l'index primaire est généralement beaucoup plus rapide que dans l'ordre de l'index secondaire. Cela est dû au fait qu'un seul accès au disque peut mettre en mémoire plusieurs enregistrements qui seront consultés à des intervalles rapprochés dans le temps. Le même accès au disque satisfait plusieurs opérations d'accès aux enregistrements. Cependant, l'insertion d'un enregistrement au milieu d'un index, tel que déterminé par l'ordre de l'index primaire, peut être beaucoup plus lente que son ajout à la fin d'un index. La fréquence de mise à jour doit être soigneusement prise en compte par rapport aux modèles de récupération lors de la conception de la table. Si aucun index primaire n'est défini pour une table, un index primaire implicite, appelé index de clé de base de données (DBK), est créé. Le DBK est simplement un numéro unique croissant incrémenté à chaque insertion d'un enregistrement. Par conséquent, l'ordre physique des enregistrements dans un index DBK est l'ordre d'insertion chronologique et les nouveaux enregistrements sont toujours ajoutés à la fin de la table. Si une application souhaite regrouper des données sur un index non unique, cela est possible en ajoutant une colonne d'auto-incrémentation à la fin de la définition d'index non unique.

Les index peuvent être définis sur des colonnes à valeurs multiples. Plusieurs entrées peuvent exister dans ces index pour les enregistrements avec plusieurs valeurs pour la colonne indexée. Les colonnes à valeurs multiples peuvent être indexées conjointement avec des colonnes à valeur unique. Lorsque deux ou plusieurs colonnes à valeurs multiples sont indexées ensemble, la propriété à valeurs multiples n'est respectée que pour la première colonne à valeurs multiples de l'index. Les colonnes de priorité inférieure sont traitées comme si elles étaient à valeur unique.

Les index peuvent également être définis comme étant clairsemés. Les index clairsemés ne comportent pas au moins une entrée pour chaque enregistrement de la table. Il existe un certain nombre d'options pour définir un index clairsemé. Des options existent pour exclure des enregistrements des index lorsqu'une clé d'index entière est NULL, lorsqu'un segment de clé est NULL ou lorsque seul le premier segment de clé est NULL. Les index peuvent également avoir des colonnes conditionnelles. Ces colonnes n'apparaissent jamais dans un index mais peuvent empêcher l'indexation d'un enregistrement lorsque la colonne conditionnelle est NULL ou non NULL.

Les index peuvent également être définis pour inclure une entrée pour chaque sous-chaîne d'une colonne Texte ou Texte long. Ces index sont appelés index de tuple. Ils sont utilisés pour accélérer les requêtes avec des prédicats de correspondance de sous-chaîne. Les index de tuple ne peuvent être définis que pour les colonnes Texte. Par exemple, si une valeur de colonne Texte est « J'aime JET Blue » et que l'index est configuré pour avoir une taille de tuple minimale de 4 caractères et une longueur de tuple maximale de 10 caractères, les sous-chaînes suivantes seront indexées :

Même si les index de tuple peuvent être très volumineux, ils peuvent considérablement accélérer les requêtes du type : rechercher tous les enregistrements contenant « JET Blue » . Ils peuvent être utilisés pour les sous-chaînes plus longues que la longueur maximale du tuple en divisant la sous-chaîne de recherche en chaînes de recherche de longueur maximale du tuple et en intersectant les résultats. Ils peuvent être utilisés pour des correspondances exactes pour des chaînes aussi longues que la longueur maximale du tuple ou aussi courtes que la longueur minimale du tuple, sans intersection d'index. Pour plus d'informations sur l'exécution de l'intersection d'index dans ESE, voir Intersection d'index. Les index de tuple ne peuvent pas accélérer les requêtes lorsque la chaîne de recherche est plus courte que la longueur minimale du tuple.

Une transaction est une unité logique de traitement délimitée par les opérations BeginTransaction et CommitTransaction, ou Rollback. Toutes les mises à jour effectuées au cours d'une transaction sont atomiques ; soit elles apparaissent toutes dans la base de données en même temps, soit aucune n'apparaît. Toutes les mises à jour ultérieures effectuées par d'autres transactions sont invisibles pour une transaction. Cependant, une transaction ne peut mettre à jour que les données qui n'ont pas changé entre-temps ; sinon, l'opération échoue immédiatement sans attente. Les transactions en lecture seule n'ont jamais besoin d'attendre, et les transactions de mise à jour ne peuvent interférer qu'avec une autre transaction de mise à jour. Les transactions qui sont terminées par Rollback, ou par une panne système, ne laissent aucune trace sur la base de données. En général, l'état des données est restauré lors du Rollback à ce qu'il était avant BeginTransaction.

Les transactions peuvent être imbriquées jusqu'à 7 niveaux, avec un niveau supplémentaire réservé à l'utilisation interne d'ESE. Cela signifie qu'une partie d'une transaction peut être annulée, sans qu'il soit nécessaire d'annuler la transaction entière ; une CommitTransaction d'une transaction imbriquée signifie simplement le succès d'une phase de traitement, et la transaction externe peut encore échouer. Les modifications ne sont validées dans la base de données que lorsque la transaction la plus externe est validée. C'est ce qu'on appelle la validation au niveau de transaction 0. Lorsque la transaction est validée au niveau de transaction 0, les données décrivant la transaction sont vidées de manière synchrone dans le journal pour garantir que la transaction sera terminée même en cas de panne ultérieure du système. Le vidage synchrone du journal rend les transactions ESE durables. Cependant, dans certains cas, les applications souhaitent ordonner leurs mises à jour, mais ne garantissent pas immédiatement que les modifications seront effectuées. Ici, les applications peuvent valider les modifications avec JET_bitIndexLazyFlush.

ESE prend en charge un mécanisme de contrôle de concurrence appelé multiversioning. Dans le cadre du multiversioning, chaque transaction interroge une vue cohérente de l'ensemble de la base de données telle qu'elle était au moment du démarrage de la transaction. Les seules mises à jour qu'elle rencontre sont celles qu'elle a effectuées. De cette manière, chaque transaction fonctionne comme si elle était la seule transaction active en cours d'exécution sur le système, sauf en cas de conflits d'écriture. Étant donné qu'une transaction peut apporter des modifications en fonction de données lues qui ont déjà été mises à jour dans une autre transaction, le multiversioning en lui-même ne garantit pas des transactions sérialisables . Cependant, la sérialisabilité peut être obtenue si nécessaire en utilisant simplement des verrous de lecture d'enregistrement explicites pour verrouiller les données de lecture sur lesquelles les mises à jour sont basées. Les verrous de lecture et d'écriture peuvent être explicitement demandés avec l'opération GetLock.

De plus, une fonctionnalité avancée de contrôle de concurrence appelée verrouillage d'entiercement est prise en charge par ESE. Le verrouillage d'entiercement est une mise à jour extrêmement simultanée où une valeur numérique est modifiée de manière relative, c'est-à-dire en ajoutant ou en soustrayant une autre valeur numérique. Les mises à jour d'entiercement ne sont pas conflictuelles, même avec d'autres mises à jour d'entiercement simultanées sur la même donnée. Cela est possible car les opérations prises en charge sont commutables et peuvent être validées ou annulées indépendamment. Par conséquent, elles n'interfèrent pas avec les transactions de mise à jour simultanées. Cette fonctionnalité est souvent utilisée pour les agrégations maintenues.

ESE étend également la sémantique des transactions des opérations de manipulation de données aux opérations de définition de données. Il est possible d'ajouter un index à une table et de faire en sorte que des transactions exécutées simultanément mettent à jour la même table sans aucun conflit de verrouillage de transaction. Plus tard, lorsque ces transactions sont terminées, l'index nouvellement créé est disponible pour toutes les transactions et comporte des entrées pour les mises à jour d'enregistrement effectuées par d'autres transactions qui n'ont pas pu percevoir la présence de l'index lorsque les mises à jour ont eu lieu. Les opérations de définition de données peuvent être effectuées avec toutes les fonctionnalités attendues du mécanisme de transaction pour les mises à jour d'enregistrement. Les opérations de définition de données prises en charge de cette manière incluent AddColumn, DeleteColumn, CreateIndex, DeleteIndex, CreateTable et DeleteTable.

Un curseur est un pointeur logique dans un index de table. Le curseur peut être positionné sur un enregistrement, avant le premier enregistrement, après le dernier enregistrement ou même entre des enregistrements. Si un curseur est positionné avant ou après un enregistrement, il n'y a pas d'enregistrement en cours. Il est possible d'avoir plusieurs curseurs dans le même index de table. De nombreuses opérations sur les enregistrements et les colonnes sont basées sur la position du curseur. La position du curseur peut être déplacée séquentiellement par des opérations de déplacement ou directement à l'aide des touches d'index avec les opérations de recherche. Les curseurs peuvent également être déplacés vers une position fractionnaire dans un index. De cette façon, le curseur peut être rapidement déplacé vers une position de barre de défilement. Cette opération est effectuée à la même vitesse qu'une opération de recherche. Aucune donnée intermédiaire ne doit être consultée.

Chaque curseur possède un tampon de copie afin de créer un nouvel enregistrement ou de modifier un enregistrement existant, colonne par colonne. Il s'agit d'un tampon interne dont le contenu peut être modifié à l'aide des opérations SetColumns. Les modifications du tampon de copie ne modifient pas automatiquement les données stockées. Le contenu de l'enregistrement en cours peut être copié dans le tampon de copie à l'aide de l'opération PrepareUpdate, et les opérations Update stockent le contenu du tampon de copie sous forme d'enregistrement. Le tampon de copie est implicitement vidé lors d'une validation ou d'une restauration de transaction, ainsi que lors des opérations de navigation. RetrieveColumns peut être utilisé pour récupérer les données de colonne soit à partir de l'enregistrement, soit à partir du tampon de copie, s'il en existe un.

Les applications ESE interrogent invariablement leurs données. Cette section du document décrit les fonctionnalités et les techniques permettant aux applications d'écrire une logique de traitement de requêtes sur ESE.

ESE fournit une fonction de tri sous la forme de tables temporaires. L'application insère les enregistrements de données dans le processus de tri, un enregistrement à la fois, puis les récupère un enregistrement à la fois dans l'ordre trié. Le tri est en fait effectué entre la dernière insertion d'enregistrement et la première récupération d'enregistrement. Les tables temporaires peuvent également être utilisées pour des ensembles de résultats partiels et complets. Ces tables peuvent offrir les mêmes fonctionnalités que les tables de base, notamment la possibilité de naviguer de manière séquentielle ou directement vers les lignes à l'aide de clés d'index correspondant à la définition de tri. Les tables temporaires peuvent également être mises à jour pour le calcul d'agrégats complexes. Les agrégats simples peuvent être calculés automatiquement avec une fonctionnalité similaire au tri où l'agrégat souhaité est un résultat naturel du processus de tri.

La récupération des données de colonne directement à partir d'index secondaires est une optimisation importante des performances. Les colonnes peuvent être récupérées directement à partir d'index secondaires, sans accéder aux enregistrements de données, via l'indicateur RetrieveFromIndex sur l'opération RetrieveColumns. Il est beaucoup plus efficace de récupérer des colonnes à partir d'un index secondaire que de l'enregistrement, lors de la navigation par l'index. Si les données de colonne ont été récupérées à partir de l'enregistrement, une navigation supplémentaire est nécessaire pour localiser l'enregistrement par la clé primaire. Cela peut entraîner des accès supplémentaires au disque. Lorsqu'un index fournit toutes les colonnes nécessaires, il est appelé index de couverture. Notez que les colonnes définies dans l'index primaire de la table se trouvent également dans les index secondaires et peuvent être récupérées de la même manière à l'aide de JET_bitRetrieveFromPrimaryBookmark.

Les clés d'index sont stockées sous une forme normalisée qui peut, dans de nombreux cas, être dénormalisée à la valeur de colonne d'origine. La normalisation n'est pas toujours réversible. Par exemple, les types de colonnes Texte et Texte long ne peuvent pas être dénormalisés. De plus, les clés d'index peuvent être tronquées lorsque les données de colonne sont très longues. Dans les cas où les colonnes ne peuvent pas être récupérées directement à partir d'index secondaires, l'enregistrement est toujours accessible pour récupérer les données nécessaires.

Les requêtes impliquent souvent une combinaison de restrictions sur les données. Un moyen efficace de traiter une restriction consiste à utiliser un index disponible. Cependant, si une requête implique plusieurs restrictions, les applications traitent souvent les restrictions en parcourant toute la plage d'index du prédicat le plus restrictif satisfait par un seul index. Tout prédicat restant, appelé prédicat résiduel, est traité en appliquant le prédicat à l'enregistrement lui-même. Il s'agit d'une méthode simple, mais elle présente l'inconvénient de devoir potentiellement effectuer de nombreux accès au disque pour mettre les enregistrements en mémoire afin d'appliquer le prédicat résiduel.

L'intersection d'index est un mécanisme de requête important dans lequel plusieurs index sont utilisés ensemble pour traiter plus efficacement une restriction complexe. Au lieu d'utiliser un seul index, les plages d'index sur plusieurs index sont combinées pour générer un nombre beaucoup plus petit d'enregistrements sur lesquels un prédicat résiduel peut être appliqué. ESE facilite cette opération en fournissant une opération IntersectIndexes. Cette opération accepte une série de plages d'index sur des index de la même table et renvoie une table temporaire de clés primaires qui peuvent être utilisées pour naviguer vers les enregistrements de la table de base qui satisfont tous les prédicats d'index.

Une jointure est une opération courante sur une conception de table normalisée, où des données logiquement liées sont rassemblées pour être utilisées dans une application. Les jointures peuvent être des opérations coûteuses car de nombreux accès aux données peuvent être nécessaires pour mettre les données liées en mémoire. Cet effort peut être optimisé dans certains cas en définissant une table de base unique qui contient les données de deux ou plusieurs tables logiques. L'ensemble de colonnes de la table de base est l'union des ensembles de colonnes de ces tables logiques. Les colonnes balisées rendent cela possible en raison de leur bonne gestion des données à valeurs multiples et à valeurs éparses. Étant donné que les données liées sont stockées ensemble dans le même enregistrement, elles sont consultées ensemble, ce qui minimise le nombre d'accès au disque pour effectuer la jointure. Ce processus peut être étendu à un grand nombre de tables logiques car ESE peut prendre en charge jusqu'à 64 993 colonnes balisées. Étant donné que les index peuvent être définis sur des colonnes à valeurs multiples, il est toujours possible d'indexer des tables « intérieures ». Cependant, certaines limitations existent et les applications doivent envisager soigneusement la pré-jointure avant d'utiliser cette technique.

La fonction de journalisation et de récupération d'ESE garantit l'intégrité et la cohérence des données en cas de panne du système. La journalisation est le processus d'enregistrement redondant des opérations de mise à jour de la base de données dans un fichier journal. La structure du fichier journal est très résistante aux pannes du système. La récupération est le processus d'utilisation de ce journal pour restaurer les bases de données à un état cohérent après une panne du système.

Les opérations de transaction sont enregistrées et le journal est vidé sur le disque à chaque validation au niveau de transaction 0. Cela permet au processus de récupération de rétablir les mises à jour effectuées par les transactions validées au niveau de transaction 0 et d'annuler les modifications apportées par les transactions qui ne se sont pas validées au niveau de transaction 0. Ce type de schéma de récupération est souvent appelé schéma de récupération « roll-forward/roll-backward ». Les journaux peuvent être conservés jusqu'à ce que les données soient copiées en toute sécurité via un processus de sauvegarde décrit ci-dessous, ou les journaux peuvent être réutilisés de manière circulaire dès qu'ils ne sont plus nécessaires à la récupération après une panne du système. La journalisation circulaire minimise la quantité d'espace disque nécessaire pour le journal, mais a des implications sur la capacité à recréer un état de données en cas de défaillance du support.

La journalisation et la récupération jouent également un rôle dans la protection des données contre les pannes de support. ESE prend en charge la sauvegarde en ligne où une ou plusieurs bases de données sont copiées, ainsi que les fichiers journaux, d'une manière qui n'affecte pas les opérations de base de données. Les bases de données peuvent continuer à être interrogées et mises à jour pendant la sauvegarde. La sauvegarde est appelée « sauvegarde floue » car le processus de récupération doit être exécuté dans le cadre de la restauration de sauvegarde pour restaurer un ensemble cohérent de bases de données. La sauvegarde en continu et la sauvegarde par copie fantôme sont toutes deux prises en charge.

La sauvegarde en continu est une méthode de sauvegarde dans laquelle des copies de tous les fichiers de base de données souhaités et des fichiers journaux nécessaires sont effectuées pendant le processus de sauvegarde. Les copies de fichiers peuvent être enregistrées directement sur bande ou sur tout autre périphérique de stockage. Aucune interruption d'activité de quelque nature que ce soit n'est requise avec les sauvegardes en continu. La base de données et les fichiers journaux sont tous deux contrôlés pour garantir qu'aucune corruption de données n'existe dans l'ensemble de données pendant le processus de sauvegarde. Les sauvegardes en continu peuvent également être des sauvegardes incrémentielles. Les sauvegardes incrémentielles sont celles dans lesquelles seuls les fichiers journaux sont copiés et qui peuvent être restaurées avec une sauvegarde complète précédente pour ramener toutes les bases de données à un état récent.

Les sauvegardes par cliché instantané sont une nouvelle méthode de sauvegarde à grande vitesse. Elles sont beaucoup plus rapides car la copie est virtuellement effectuée après une brève période de mise en veille d'une application. Au fur et à mesure que les mises à jour des données sont effectuées, la copie virtuelle est matérialisée. Dans certains cas, la prise en charge matérielle des sauvegardes par cliché instantané signifie que l'enregistrement des copies virtuelles n'est pas nécessaire. Les sauvegardes par cliché instantané sont toujours des sauvegardes complètes.

La restauration peut être utilisée pour appliquer une sauvegarde unique ou une combinaison d'une sauvegarde complète unique et d'une ou plusieurs sauvegardes incrémentielles. De plus, tous les fichiers journaux existants peuvent également être relus pour recréer un ensemble de données complet jusqu'à la dernière transaction enregistrée comme validée au niveau de transaction 0. La restauration d'une sauvegarde peut être effectuée sur n'importe quel système capable de prendre en charge l'application d'origine. Il n'est pas nécessaire que ce soit la même machine, ni même la même configuration de machine. L'emplacement des fichiers peut être modifié dans le cadre du processus de restauration.

Lorsqu'une base de données ESENT est créée, la taille du secteur du disque physique est stockée avec la base de données. La taille du secteur physique doit rester cohérente entre les sessions ; dans le cas contraire, une erreur est signalée. Lorsqu'un lecteur physique est cloné ou restauré à partir d'une image de lecteur vers un lecteur qui utilise une taille de secteur physique différente ( lecteurs au format avancé ), ESENT signale des erreurs.

Il s'agit d'un problème connu et Microsoft propose des correctifs. Pour Windows Vista ou Windows Server 2008, consultez l'article KB2470478. Pour Windows 7 ou Windows Server 2008 R2, consultez l'article KB982018.

JET Blue a été développé à l'origine par Microsoft comme une mise à niveau potentielle du moteur de base de données JET Red dans Microsoft Access , mais n'a jamais été utilisé dans ce rôle. Au lieu de cela, il a été utilisé par Exchange Server, Active Directory, File Replication Service (FRS), Security Configuration Editor, Certificate Services, Windows Internet Name Service (WINS) et une multitude d'autres services, applications et composants Windows Microsoft. Pendant des années, il s'agissait d'une API privée utilisée uniquement par Microsoft, mais elle est depuis devenue une API publiée que tout le monde peut utiliser.

Les travaux sur Data Access Engine (DAE) ont commencé en mars 1989, lorsque Allen Reiter a rejoint Microsoft. Au cours de l'année suivante, une équipe de quatre développeurs a travaillé pour Allen pour terminer en grande partie l'ISAM. Microsoft disposait déjà de l'ISAM BC7 (JET Red), mais a commencé l'effort Data Access Engine (DAE) pour construire un moteur de base de données plus robuste comme entrée dans le nouveau domaine de l'architecture client-serveur. Au printemps 1990, les équipes BC7 ISAM et DAE ont été fusionnées pour devenir l'effort Joint Engine Technology (JET) ; responsable de la production de deux moteurs, un v1 ( JET Red ) et un v2 (JET Blue) qui seraient conformes à la même spécification API (JET API). DAE est devenu JET Blue pour la couleur du drapeau d'Israël. BC7 ISAM est devenu JET Red pour la couleur du drapeau de la Russie. Bien que JET Blue et JET Red aient été écrits selon la même spécification API, ils ne partageaient aucun code ISAM. Ils prenaient tous deux en charge un processeur de requête commun, QJET, qui plus tard, avec l'ISAM BC7, est devenu synonyme de JET Red.

JET Blue a été commercialisé pour la première fois en 1994 en tant que module ISAM pour WINS, DHCP et les services RPL aujourd'hui disparus de Windows NT 3.5. Il a été à nouveau commercialisé en tant que moteur de stockage pour Microsoft Exchange en 1996. D'autres services Windows ont choisi JET Blue comme technologie de stockage et en 2000, toutes les versions de Windows ont commencé à être livrées avec JET Blue. JET Blue était utilisé par Active Directory et faisait partie d'un ensemble spécial de codes Windows appelé Trusted Computing Base (TCB). Le nombre d'applications Microsoft utilisant JET Blue continue de croître et l'API JET Blue a été publiée en 2005 pour faciliter l'utilisation par un nombre toujours croissant d'applications et de services à la fois dans et au-delà de Windows.

Une entrée du blog Web Microsoft Exchange indique que les développeurs qui ont contribué à JET Blue incluent Cheen Liao, Stephen Hecht, Matthew Bellew, Ian Jose, Edward « Eddie » Gilbert, Kenneth Kin Lum, Balasubramanian Sriram, Jonathan Liem, Andrew Goodsell, Laurion Burchall, Andrei Marinescu, Adam Foxman, Ivan Trindev, Spencer Low et Brett Shirley.

En janvier 2021, Microsoft a rendu le code source d'ESE open source. Il a été publié sur GitHub avec la licence permissive MIT .

Bien qu'ils partagent une lignée commune, il existe de grandes différences entre JET Red et ESE.

• JET Red est une technologie de partage de fichiers, tandis qu'ESE est conçu pour être intégré dans une application serveur et ne partage pas de fichiers.
• JET Red fait de son mieux pour récupérer les fichiers, tandis qu'ESE dispose d'une journalisation en écriture anticipée et d'une isolation des instantanés pour une récupération garantie après incident.
• JET Red avant la version 4.0 prend en charge uniquement le verrouillage au niveau de la page, tandis qu'ESE et JET Red version 4.0 prennent en charge le verrouillage au niveau de l'enregistrement.
• JET Red prend en charge une grande variété d'interfaces de requête, notamment ODBC et OLE DB . ESE n'est pas fourni avec un moteur de requête, mais s'appuie plutôt sur les applications pour écrire leurs propres requêtes sous forme de code C ISAM.
• JET Red a une taille de fichier de base de données maximale de 2 Gio , tandis qu'ESE a une taille de fichier de base de données maximale de 8 Tio avec des pages de 4 Kio et de 16 Tio avec des pages de 8 Kio.