Moteur de stockage extensible 1400598 29979531 2008-05-25T14:42:01Z Romanc19s 26084 orthographe : "appeLée" avec un seul L /* Les index */ {{Voir homonymes|ESE}} Le '''moteur de stockage extensible''' de Windows ('''Extensible Storage Engine''' ou ESE), connu aussi sous le nom de '''JET Blue''', est une méthode d'accès [[séquentiel indexé]] c'est-à-dire une technologie permettant le stockage de données. C'est le moteur de base de données utilisé par les produits tels qu'[[Microsoft Exchange Server|Exchange Server]], [[Active Directory]], [[Microsoft SQL Server|SQL Server]]. Il repose sur les principes connus sous l'acronyme [[Propriétés ACID|ACID]] des Systèmes de gestion de [[Base de données relationnelle|bases de données relationelles]]. ESE permet aux applications d'avoir un état consistent de données via un système de mises à jour et de récupérations qui se passent sous forme de transactions. <br>Les transactions dans ESE sont hautement concurrentes ce qui rend ESE utilisable pour des applications pour serveur. ESE met en mémoire cache des données de façon intelligente pour y permettre un accès à haute performance. Un mécanisme de recouvrement des données après un [[Crash (informatique)|plantage du système]] est fourni afin que les données soient sauvegardées. De plus, ESE est un logiciel léger ce qui le rend utilisable pour des applications auxiliaires. ==Base de données== Une base de donnée est à la fois un regroupement physique et logique de données. Une base de données ESE prend la forme d'un unique fichier pour Windows. En interne la base de données est une collection de pages de 2, 4 ou 8 kOctet. Ces pages contiennent des méta-données pour décrire les données contenues au sein des bases de données, les données elles-mêmes, des index pour persist ordres intéressants des données, et d'autres informations. Cette information est intermélée au sein du fichier de la base de données mais des efforts sont faits pour garder data used together clustered together within the database. Une base de données ESE peut contenir jusqu'à 2^31 pages, ou 16 Téra-octets de données, pour des pages de taille de 8 k-octets. Les bases de données ESE sont organisées en groupes appelés instances. La plupart des applications utilise une seule instance, mais toutes les applications peuvent aussi utiliser de multiples instances. L'importance de l'instance est qu'elle associe une single recovery log series avec une ou plus base de données. Actuellement, jusqu'à 6 bases de données utilisateur peuvent être attachées à une instance ESE à tout moment. Chaque processus utilisant ESE peut avoir jusqu'à 1024 instances ESE. Une base de données est portable du fait qu'elle peut être détachée d'une instance ESE en cours pour être attachée ensuite à la même instance ou à une instance différente. Pendant qu'elle est détachée, une base de données peut être copiée en utilisant des utilitaires Windows standards. La base de donnée ne peut pas être copiée pendant qu'elle utilisée activement puisque ESE ouvre les fichiers de bases de données de façon exclusive. Une base de données peut physiquement résider sur n'importe quel dispositif ayant un support pour les opérations d'entrée/sortie adressables directement par Windows. ==Tables== Une [[Table (base de données)|table]] est une collection homogène d'enregistrements, où chaque enregistrement possède le même nombre 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 de disque allouée à une table au sein d'une base de données est déterminée par un paramètre donné lorsque la table est créée avec l'opération CreateTable. Les tables croissent automatiquement en réponse à la création de données (enregistrement). Les tables ont un ou plus index. Il doit y avoir au moins un index de cluster pour les données d'enregistrement. Lorsqu'il n'y a pas d'index de cluster défini par l'application, un index artificiel est utilisé qui ordonne et groupe les enregistrements par ordre chronologique d'insertion d'enregistrement. Les index sont définis pour faire persister des ordres intéressants parmi les données, et permettent des accès séquentiels aux enregistrements dans l'ordre de l'index, et des accès directs aux enregistrements par valeurs des index des colonnes. Des index en cluster dans ESE doivent aussi être primaires, ce qui signifie que la clé de l'index doit être unique. Les index en cluster et ceux qui ne le sont pas sont représentés en utilisant des arbres B+. Si une opération d'insertion ou de mise à jour cause un dépassement de page, la page sera coupée en deux : une nouvelle page est alors allouée et est logiquement chainée entre les deux pages précédemment adjacentes. Du fait que cette nouvelle page n'est pas physiquement adjacente à ses voisines logiques, les accès à elle n'est pas aussi efficace. ESE possède une caractéristique de compactage en-ligne qui re-compacte les données. Si une table doit être fréquemment mise à jour, de l'espace peut lui être réservé pour des insertions futures en spécifiant une densité de page appropriée lors de la création d'une page ou d'un index. Ceci permet d'éviter les opérations de coupage de page ou permet de les remettre à un moment ultérieur. ==Enregistrements et colonnes== Un enregistrement est un ensemble associé de valeurs de colonnes. Les enregistrements sont insérés et mis à jour via des opérations "update" et peuvent être supprimés via des opérations "Delete". Les colonnes sont fixées et lues via les opérations "SetColumns" et "RetrieveColumns", respectivement. La taille maximale d'un enregistrement est de 8110 octets pour des pages de 8k-octets avec l'exception des colonnes à longue valeurs. Les types des colonnes "LongText" et "LongBinary" ne contribuent pas significativement à la limitation en taille, et des enregistrements peuvent contenir des données d'une taille bien plus large qu'une taille de page de base de données si ces données sont stockées dans des colonnes de type "Long value". Lorsqu'une référence "long value" est stockée dans un enregistrement, il n'y a besoin que de 9 octets de données requis. Ces données "long values" peuvent elles-mêmes faire jusqu'à 2G-octets en taille. Les enregistrements sont typiquement uniformes dans le fait que chaque enregistrement a un ensemble de valeurs pour le même ensemble de colonnes. Dans ESE, il est aussi possible de définir un grand nombre de colonnes pour une table, et de n'en avoir que quelques unes de remplies de valeurs non nulles pour certains enregistrements. De même, une table peut aussi être une collection d'enregistrements hétérogènes. ESE offre le support pour un large panel de valeurs de colonnes, allant en taille du bit seul jusqu'à des valeurs de 2G-octets. Faire le choix des rtpes de colonnes corrects est important parce que le type de la colonne détermine beaucoup de ses propriétés, incluant son ordonnancement pour les index. Voici la liste des types ayant un support dans ESE : '''Types de colonnes''' {| border="1" cellspacing="0" cellpadding="5" ! Nom ! Description |- | Bit | valeur ternaire (NULL, 0, ou 1) |- | Octet non signé | entier non signé sur 1 octet |- | court ("Short") | entier signé codé sur 2 octets |- | Court non signé | entier non signé sur 2 octets |- | Long | entier signé sur 4 octets |- | Long non signé | entier non signé sur 4 octets |- | Long Long | entier signé sur 8 octets |- | Monnaie | entier signé sur 8 octets |- | IEEE Single | Nombre à virgule flottante sur 4 octets |- | IEEE Double | Nombre à virgule flottante sur 8 octets |- | Temps / Date | Date ou temps codé sur 8 octets (date intégrale, temps fractionel) |- | GUID | identifiant unique sur 16 octets |- | Binaire | chaîne binaire, de longueur <= 255 octets |- | Texte | chaîne de caractère ANSI ou Unicode de longueur <= 255 octets |- | Binaire long | Chaîne binaire de grande taille de longueur < 2 G-octets |- | Texte long | Chaîne de caractères de grande taille ANSI ou Unicode de longueur < 2G-octets |} '''Colonnes fixes, variables et marquées''' <br>Chaque table ESE peut définir jusqu'à 127 colonnes de longueur fixe, 128 colonnes à longueur variable et 64.993 colonnes marquées. <br>Les colonnes fixes sont essentiellement des colonnes qui prennent la même quantité de mémoire pour chaque enregistrement, quelle que soit leur valeur. Les colonnes fixes utilisent 1 bit pour représenter une valeur nulle (NULL) et une quantité de mémoire fixe pour chaque enregistrement. <br>Les colonnes variables sont essentiellement des colonnes qui utilisent une quantité de mémoire variable pour chaque enregistrement dans laquel elles sont définies; cet espace de mémoire dépend de la taille de la valeur de cette colonne particulière. Les colonnes variables utilisent 2 octets pour déterminer une valeur nulle (NULL), et une quantité d'espace mémoire varaiable pour chaque enregistrement dans lequel cette colonne est définie. Les colonnes marquées sont des colonnes qui ne prennent aucune place en mémoire si elles ne contiennet aucun enregistrement. Elles peuvent être à valeur unique ou être à valeur multiples. La même colonnes marquée peut contenir des valeurs multiples dans un seul enregistrement! Lorsque des colonnes marquées sont définies dans un enregistrement, chaque instance d'une colonne marquée prend approximativement 4 octets d'espace mémoire en plus de la taille de la valeur de l'instance de la colonne marquée. Lorsque le nombre d'instances d'une seule colonne marquée est important, l'entête de chaque instance de colonne marquée fait approximativement 2 octets. Les colonnes marquées sont idéales pour des colonnes rares parce qu'elles n'occupent aucune place en mémoire si elles ne sont pas définies. Si une colonne marquée à valeur multiple est indexée, l'index ne contiendra qu'une seul entrée pour l'enregistrement pour chaque valeur de la colonne marquée. <!--- Pour une table donnée, les colonnes sont de l'une de ces deux catégories : celles which either occur exactly once in each of the records, with possibly a few NULL values; and those which occur rarely, or which may have multiple occurrences in a single record. Fixed and variable columns belong to the former category, while tagged columns belong to the latter. The internal representation of the two column categories is different, and it is important to understand the trade offs between the column categories. Fixed and variable columns are typically represented in every record, even when the occurrence has a NULL value. These columns can be quickly addressed via an offset table. Tagged column occurrences are preceded by a column identifier and the column is located by binary searching the set of tagged columns. '''Long Values''' Column types of Long Text and Long Binary are large binary objects. They are stored in separate B+tree from the clustered index keyed by long value id and byte offset. ESE supports append, byte range overwrite, and set size for these columns. Also, ESE has a single instance store feature where multiple records may reference the same large binary object, as though each record had its own copy of the information, i.e. without inter-record locking conflicts. The maximum size of a Long Text or Long Binary column value is 2GBytes. '''Version, Auto-increment and Escrow Columns''' Version columns are automatically incremented by ESE each time a record containing this column is modified via an Update operation. This column cannot be set by the application, but can only be read. Applications of version columns include being used to determine if an in-memory copy of a given record needs to be refreshed. If the value in a table record is greater than the value in a cached copy then the cached copy is known to be out of date. Version columns must be of type Long. Auto increment columns are automatically set by ESE such that the value contained in the column is unique for every record in the table. These columns, like version columns, cannot be set by the application. Auto increment columns are read only, and are automatically set when a new record is inserted into a table via an Update operation. The value in the column remains constant for the life of the record, and only one auto increment column is allowed per table. Auto increment columns may be of type Long or type Currency . Escrow columns can be modified via an EscrowUpdate operation. Escrowed updates are numeric delta operations. Escrow columns must be of type Long. Examples of numeric delta operations include adding 2 to a value or subtracting 1 from a value. ESE tracks the change in a value rather than the end value of an update. Multiple sessions may each have outstanding changes made via EscrowUpdate to the same value because ESE can determine the actual end value regardless of which transactions commit and which transactions rollback. This allows multiple users to concurrently update a column by making numeric delta changes. ---> ==Les index== Un index est un ordonnemencement destiné à persister au sein des enregistrements dans une table. Les index sont utilisés pour des accès séquentiels aux rangées de données dans l'ordre défini, et pour la navigation directe au sein des enregistrements basée sur les valeurs indexées des colonnes. L'ordre défini par un index est décrit en termes d'un tableau de colonnes, dans l'ordre de précédence. ce tableau de colonnes est également appelé la clé d'index. chaque colonne est appelée un segment d'index. Chaque segment d'index peut être classé en ordre de tri croissant ou décroissant, en termes de son ordonnancement. On peut définir autant d'index que l'on veut pour une table. ESE fournit un ensemble riche de caractéristiques d'indexation. <!--- '''Clustered Indexes''' One index may be specified as the clustered, or primary, index. In ESE, the clustered index must be unique and is referred to as the primary index. Other indexes are described as non-clustered, or secondary, indexes . Primary indexes are different from secondary indexes in that the index entry is the record itself, and not a logical pointer to the record. Secondary indexes have primary keys at their leaves to logically link to the record in the primary index. In other words, the table is physically clustered in primary index order. Retrieval of non-indexed record data in primary index order is generally much faster than in secondary index order. This is because a single disk access can bring into memory multiple records that will be access close together in time. The same disk access satisfies multiple record access operations. However, the insertion of a record into the middle of an index, as determined by the primary index order, may be very much slower than appending it to the end of an index. Update frequency must be carefully considered against retrieval patterns when performing table design. If no primary index is defined for a table, then an implicit primary index, called a database key (DBK) index is created. The DBK is simply a unique ascending number incremented each time a record is inserted. As a result, the physical order of records in a DBK index is chronological insertion order, and new records are always added at the end of the table. If an application wishes to cluster data on a non-unique index, this is possible by adding an autoincrement column to the end of the non-unique index definition. '''Indexing Over Multi-valued Columns''' Indexes can be defined over multi-valued columns. Multiple entries may exist in these indexes for records with multiple values for the indexed column. Multi-valued columns may be indexed in conjunction with single valued columns. When two or more multi-valued columns are indexed together, then the multi-valued property is only honored for the first multi-value column in the index. Lower precedence columns are treated as though they were single valued. '''Sparse Indexes''' Indexes can also be defined to be sparse. Sparse indexes do not have at least one entry for each record in the table. There are a number of options in defining a sparse index. Options exist to exclude records from indexes when an entire index key is NULL, when any key segment is NULL or when just the first key segment is NULL. Indexes can also have conditional columns. These columns never appear within an index but can cause a record not to be indexed when the conditional column is either NULL or non-NULL. '''Tuple Indexes''' Indexes can also be defined to include one entry for each sub-string of a Text or Long Text column. These indexes are called tuple indexes. They are used to speed queries with sub-string matching predicates. Tuple indexes can only be defined for Text columns. For example, if a Text column value is “I love JET Blue”, and the index is configured to have a minimum tuple size of 4 characters and a maximum tuple length of 10 characters, then the following sub-strings will be indexed: “I love JET” “ love JET ” “love JET B” “ove JET Bl” “ve JET Blu” “e JET Blue” “ JET Blue” “JET Blue” “ET Blue” “T Blue” “ Blue” “Blue” As you can see, tuple indexes tend to be very large. However, these indexes can dramatically speed queries of the form: find all records containing “JET Blue”. They can be used for sub-strings longer than the maximum tuple length by dividing the search sub-string into maximum tuple length search strings and intersecting the results. They can be used for exact matches for strings as long as the maximum tuple length or as short as the minimum tuple length, with no index intersection. For more information on performing index intersection in ESE see Index Intersection. Tuple indexes cannot speed queries where the search string is shorter than the minimum tuple length. ---> ==Transactions== Une transaction est une unité logique de traitement délimitée par des opérations BeginTransaction, CommitTransaction, ou Rollback. <!--- All updates performed during a transaction are atomic; they either all appear in the database at the same time or none appear. Any subsequent updates by other transactions are invisible to a transaction. However, a transaction can update only data that has not changed in the meantime; else the operation fails at once without waiting. Read-only transactions never need to wait, and update transactions can interfere only with one another updating transaction. Transactions which are terminated by Rollback, or by a system crash, leave no trace on the database. In general, the data state is restored on Rollback to what it was prior to BeginTransaction. Transactions may be nested up to 7 levels, with one additional level reserved for ESE internal use. This means that a part of a transaction may be rolled back, without need to roll back the entire transaction; a CommitTransaction of a nested transaction merely signifies the success of one phase of processing, and the outer transaction may yet fail. Changes are committed to the database only when the outermost transaction is committed. This is known as committing to transaction level 0. When the transaction commits to transaction level 0, data describing the transaction is synchronously flushed to the log to ensure that the transaction will be completed even in the event of a subsequent system crash. Synchronously flushing the log makes ESE transactions durable. However, in some cases application wish to order their updates, but not immediately guarantee that changes will be done. Here, applications can commit changes with JET_bitIndexLazyFlush. ESE supports a concurrency control mechanism called multi-versioning. In multi-versioning, every transaction queries a consistent view of the entire database as it was at the time the transaction started. The only updates it encounters are those made by it. In this way, each transaction operates as though it was the only active transaction running on the system, except in the case of write conflicts. Since a transaction may make changes based on data read that has already been updated in another transaction, multi-versioning by itself does not guarantee serializabile transactions. However, serializability can be achieved when desired by simply using explicit record read locks to lock read data that updates are based upon. Both read and write locks may be explicitly requested with the GetLock operation. In addition, an advanced concurrency control feature known as escrow locking is supported by ESE. Escrow locking is an extremely concurrent update where a numeric value is changed in a relative fashion, i.e. by adding or subtracting another numeric value. Escrow updates are non-conflicting even with other concurrent escrow updates to the same datum. This is possible because the operations supported are commutable and can be independently committed or rolled back. As a result, they do not interfere with concurrent update transactions. This feature is often used for maintained aggregations. ESE also extends transaction semantics from data manipulation operations to data definition operations. It is possible to add an index to a table and have concurrently running transactions update the same table without any transaction lock contention whatsoever. Later, when these transactions are complete, the newly created index is available to all transactions and has entries for record updates made by other transactions that could not perceive the presence of the index when the updates took place. Data definition operations may be performed with all the features expected of the transaction mechanism for record updates. Data definition operations supported in this fashion include AddColumn, DeleteColumn, CreateIndex, DeleteIndex, CreateTable and DeleteTable. ---> ==Navigation par curseur et tampon de Copier== Un curseur est un pointeur logique au sein de l'index de la 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 de enregistrement en cours. Il est possible d'avoir de multiple curseurs dans le même index de table. De nombreuse opérations sur les colonnes ou sur les enregistrement sont basées sur la position du curseur. La position du curseur peut être déplacée de façon séquentiellement par des opérations Move ("déplace") ou directement en utilisant des clés d'index avec des opération Seek ("Cherche"). Les curseurs peuvent aussi être déplacés à une position fractionelle au sein d'un index. De cette manière, le curseur peut être déplacé rapidement à une position de barre latérale. Cette opération est accomplie à la même vitesse qu'une opération Seek. Aucune donnée intervenante ne doit être accèdee. <!--- Each cursor has a copy buffer in order to create a new record, or modify an existing record, column by column. This is an internal buffer whose contents can be changed with SetColumns operations. Modifications of the copy buffer do not automatically change the stored data. The contents of the current record can be copied into the copy buffer using the PrepareUpdate operation, and Update operations store the contents of the copy buffer as a record. The copy buffer is implicitly cleared on a transaction commit or rollback, as well as on navigation operations. RetrieveColumns may be used to retrieve column data either from the record or from the copy buffer, if one exists. ---> ==Traitement de requêtes== Les applicatons ESE effectuent invariablement des requêtes dans leur données. <!--- '''Sorts and Temporary Tables''' ESE provides a sort capability in the form of temporary tables. The application inserts data records into the sort process one record at a time, and then retrieves them one record at a time in sorted order. Sorting is actually performed between the last record insertion and the first record retrieval. Temporary tables can be used for partial and complete result sets as well. These tables can offer the same features as base tables including the ability to navigate sequentially or directly to rows using index keys matching the sort definition. Temporary tables can also be updatable for computation of complex aggregates. Simple aggregates can be computed automatically with a feature similar to sorting where the desired aggregate is a natural result of the sort process. '''Covering Indexes''' Retrieving column data directly from secondary indexes is an important performance optimization. Columns may be retrieved directly from secondary indexes, without accessing the data records, via the RetrieveFromIndex flag on the RetrieveColumns operation. It is much more efficient to retrieve columns from a secondary index, than from the record, when navigating by the index. If the column data were retrieved from the record, then an additional navigation is necessary to locate the record by the primary key. This may result in additional disk accesses. When an index provides all columns needed then it is called a covering index. Note that columns defined in the table primary index are also found in secondary indexes and can be similarly retrieved using JET_bitRetrieveFromPrimaryBookmark. Index keys are stored in normalized form which can be, in many cases, denormalized to the original column value. Normalization is not always reversible. For example, Text and Long Text column types cannot be denormalized . In addition, index keys may be truncated when column data is very long. In cases where columns cannot be retrieved directly from secondary indexes, the record can always be accessed to retrieve the necessary data. '''Index Intersection''' Queries often involve a combination of restrictions on data. An efficient means of processing a restriction is to use an available index. However, if a query involves multiple restrictions then applications often process the restrictions by walking the full index range of the most restrictive predicate satisfied by a single index. Any remaining predicate, called the residual predicate, is processed by applying the predicate to the record itself. This is a simple method but has the disdavantage of potentially having to perform many disk accesses to bring records into memory to apply the residual predicate. Index intersection is an important query mechanism in which multiple indexes are used together to more efficiently process a complex restriction. Instead using only a single index, index ranges on multiple indexes are combined to result in a much smaller number of records on which any residual predicate can be applied. ESE makes this easy by supplying an IntersectIndexes operation. This operation accepts a series of index ranges on indexes from the same table and returns a temporary table of primary keys that can be used to navigate to the base table records that satisfy all index predicates. '''Pre-joined Tables''' A join is a common operation on a normalized table design, where logically related data is brought back together for use in an application. Joins can be expensive operations because many data accesses may be needed to bring related data into memory. This effort can be optimized in some cases by defining a single base table that contains data for two or more logical tables. The column set of the base table is the union of the column sets of these logical tables. Tagged columns make this possible because of their good handling of both multi-valued and sparse valued data. Since related data is stored together in the same record, it is accessed together thereby minimizing the number of disk accesses to perform the join. This process can be extended to a large number of logical tables as ESE can support up to 64,993 tagged columns. Since indexes can be defined over multi-valued columns, it is still possible to index ‘interior’ tables. However, some limitations exist and applications should consider pre-joining carefully before employing this technique. ---> ==Mise en journal et récupération après un plantage== Les caractéristiques de mise en journal et de récupération après plantage de ESE garantissent l'intégrité des données et la consistence dans le cas où se produit un crash du système. La mise en journal est le processus d'enregistrement redondant des opérations de mise à jour de la base de données dans un fichier log. La structure du fichier log est très robuste contre l'éventualité d'un plantage du système. La récupération est l'utilisation de ce fichier log pour restaurer la base de données en en état après qu'un crash du système a eu lieu. <!--- Transaction operations are logged and the log is flushed to disk during each commit to transaction level 0. This allows the recovery process to redo updates made by transactions which commit to transaction level 0, and undo changes made by transactions which did not commit to transaction level 0. This type of recovery scheme is often referred to as a ‘roll-forward/roll-backward’ recovery scheme. Logs can be retained until the data is safely copied via a backup process described below, or logs can be reused in a circular fashion as soon as they are no longer needed for recovery from system crash. Circular logging minimizes the amount of disk space needed for the log but has implications on the ability to recreate a data state in the event of a media failure. ==Backup and Restore== Logging and recovery also play a role in protecting data from media failure. ESE supports on-line backup where one or more databases are copied, along with log files in a manner that does not affect database operations. Databases can continue to be queried and updated while the backup is being made. The backup is referred to as a ‘fuzzy backup’ because the recovery process must be run as part of backup restoration to restore a consistent set of databases. Both streaming and shadow copy backup are supported. Streaming backup is a backup method where copies of all desired database files and the necessary log files are made during the backup process. File copies may be saved directly to tape or can be made to any other storage device. No quiescing of activity of any kind is required with streamed backups. Both the database and log files are check summed to ensure that no data corruptions exist within the data set during the backup process. Streaming backups may also be incremental backups. Incremental backups are ones in which only the log files are copied and which can be restored along with a previous full backup to bring all databases to a recent state. Shadow copy backups are a new high speed backup method. Shadow copy backups are dramatically faster because the copy is virtually made after a brief period of quiescing an application. As subsequent updates are made to the data, the virtual copy is materialized. In some cases, hardware support for shadow copy backups means that actually saving the virtual copies is unnecessary. Shadow copy backups are always full backups. Restore can be used to apply a single backup, or it can be used to apply a combination of a single full backup with one or more incremental backups. Further, any existing log files can be replayed as well to recreate an entire data set all the way up to the last transaction logged as committed to transaction level 0. Restoration of a backup can be made to any system capable of supporting the original application. It need not be the same machine, or even the same machine configuration. Location of files can be changed as part of the restoration process. ---> ==Historique== JET Blue a été conçu à l'origine par Microsoft en tant que mise à jour prospective pour le [[Microsoft Jet Database Engine]] (JET Red), moteur de base de données de [[Microsoft Access]], mais n'a jamais été utilisé pour remplir ce rôle. A la place, il a été utilisé par Exchange Server, Active Directory, et une série d'autres services et applications Microsoft. Pendant des années, c'était une API privée utilisée par Microsoft seulement, puis devint une API publiée que tout le monde put utiliser. <!--- Work began on Data Access Engine (DAE) in March of 1989 when Allen Reiter joined Microsoft. Over the next year a team of four developers worked for Allen to largely complete the ISAM. Microsoft already had the BC7 ISAM (JET Red) but began the Data Access Engine (DAE) effort to build a more robust database engine as an entry in the then new client-server architecture realm. In the spring of 1990, BC7 ISAM and DAE teams were joined to become the Joint Engine Technology (JET) effort; responsible for producing two engines a v1 (JET Red) and a v2 (JET Blue) that would conform to the same API specification (JET API). DAE became JET Blue for the color of the flag of Israel. BC7 ISAM became JET Red for the color of the flag of Russia. While JET Blue and JET Red were written to the same API specification, they shared no ISAM code whatsoever. They did both support a common query processor, QJET, which later together with the BC7 ISAM became synonymous with JET Red. JET Blue first shipped in 1994 as an ISAM for WINS, DHCP, and the now defunct RPL services in Windows NT 3.5. It shipped again as the storage engine for Microsoft Exchange in 1996. Additional Windows services chose JET Blue as their storage technology and by 2000 every version of Windows began to ship with JET Blue. JET Blue was used by Active Directory and became part of a special set of Windows code called the Trusted Computing Base (TCB). The number of Microsoft applications using JET Blue continues to grow and the JET Blue API was published in 2005 to facilitate usage by an ever increasing number of applications and services both within and beyond Windows. Developers who have contributed towards the success of JET Blue include Cheen Liao, Stephen Hecht, Matthew Bellew, Ian Jose, Balasubramanian Sriram, Jonathan Liem, Andrew Goodsell, Laurion Burchall, Andrei Marinescu, and Brett Shirley. ---> ==Futur== [[Windows Mail]] et Desktop Search dans [[Microsoft Windows Vista|Windows Vista]] utiliseront aussi ESE pour enregistrer des index et des informations sur la propriété respectivement. <!--- In Windows the ESE API has shipped in every Windows release since 2000. In Exchange the ESE API has only shipped [[32-bit]], because this is the only supported platform for the Exchange product, even though Windows XP x64 Edition had a native x64 ESE a few years ago. With [[E12]] the ESE engine will ship natively 64-bit. This is in stark contrast to the JET Red database engine, which likely will never be ported to [[64-bit]]. ==Comparison to JET Red== While they share a common lineage, there are vast differences between JET Red and ESE. * JET Red is a file sharing technology, while ESE is designed to be embedded in a server application, and does not share files. * JET Red makes best effort file recovery, while ESE has write ahead logging and snapshot isolation for guaranteed crash recovery. * JET Red before version 4.0 supports only page level locking, while ESE and JET Red version 4.0 supports record level locking. * JET Red supports a wide variety of query interfaces, including [[ODBC]] and [[OLE DB]]. ESE does not ship with a query engine but instead relies on applications to write their own queries as [[C (programming language)|C]] ISAM code. * JET Red has a maximum database file size of 2[[Gigabyte|GB]], while ESE has a maximum database file size of 8[[Terabyte|TB]] with 4kByte pages, and 16[[Terabyte|TB]] with 8kByte pages. ---> ==Références== * http://www.msexchange.org/pages/article_p.asp?id=807 * http://www.techgalaxy.net/Docs/Exchange/Exchange%202000%20Acronyms%20and%20Terminology.htm * http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ese/ese/portal.asp * http://www.messagingtalk.org/content/227.html {{Portail sécurité informatique}} [[Catégorie:Active Directory]] [[en:Extensible Storage Engine]]