Войти
Extensible Storage Engine (ESE ), также известный как JET Blue, это технология хранения данных ISAM (индексированный метод последовательного доступа) от Microsoft. ESE - это ядро Microsoft Exchange Server, Active Directory и Windows Search. Он также используется рядом компонентов Windows, включая клиент Windows Update и . Его цель - приложениям и извлекать данные с помощью индексированного и последовательного доступа.
ESE обеспечивает обновление и извлечение данных транзакций. Предоставляется механизм восстановления после сбоя, так что согласованность данных сохраняется даже в случае сбоя системы. Транзакции в ESE очень параллельны, что делает ESE подходящим для серверных приложений. ESE интеллектуально кэширует данные, чтобы обеспечить высокопроизводительный доступ к данным. Кроме того, ESE легкий, что делает его пригодным для вспомогательных приложений.
Среда выполнения ESE (ESENT.DLL) поставляется в каждом выпуске Windows, начиная с Windows 2000, с собственной версией x64 среды выполнения ESE, поставки с x64 версиями Windows XP и Windows Server 2003. Microsoft Exchange, вплоть до Exchange 2003 поставлялся только с 32-разрядной версией, поскольку это была единственная поддерживаемая платформа. Вместе с Exchange 2007 он поставляется с 64-разрядной версией.
База данных представляет собой как физическую, так и логическую группу данные. База данных ESE выглядит для Windows как один файл. Внутренняя база данных представляет собой набор из 2, 4, 8, 16 или 32 КБ страниц (параметры страницы 16 и 32 КБ доступны только в Windows 7 и Exchange 2010), используя в сбалансированном порядке Структура B -дерево. Эти страницы содержат метаданные для описания данных, данныеся в базе данных, других индексов. Эта информация перемешана в файле базы данных, но прилагаются усилия, чтобы данные использовались вместе, были сгруппированы вместе в базе данных. База данных ESE может содержать до 2 страниц или 16 терабайт данных для страниц размером 8 килобайт.
Базы данных ESE организованы в группы, называемые экземпляры. Многие приложения используют один экземпляр, но все приложения также могут использовать несколько экземпляров. Важность экземпляра заключается в том, что он связывает один серию журнала восстановления с одним или базами данных. В настоящее время к экземпляру ESE можно подключить до 6 пользовательских баз данных в любое время. Каждый отдельный процесс, использующий ESE, может иметь до 1024 экземпляров ESE.
База данных переносима в том смысле, что ее можно отсоединить от одного работающего экземпляра ESE, а затем присоединить к же или другому работающему экземпляру. В отсоединенном состоянии базы данных можно скопировать с помощью стандартных утилит Windows. База данных не может быть скопирована, пока она активно используется, поскольку ESE открывает файлы базы данных исключительно. База данных может находиться на любом устройстве, поддерживаемом Windows для ввода-вывода с прямым адресом.
Таблица - это однородный набор записей, в каждой записи имеет одинаковый набор столбцов. Каждая таблица идентифицирует себя именем таблицы, область действия которой является локальной по отношению к базе данных, в которой она содержится. Объем дискового пространства, выделенного для таблицы в базе данных, определяется параметром, заданным при создании таблицы с помощью операции CreateTable. Таблицы автоматически растут в ответ на создание данных.
Таблицы один или несколько индексов. Для данных записи быть хотя бы один кластеризованный индекс. Когда приложение не определяет кластерный индекс, используется искусственный индекс, который упорядочивает и выполняет записи в хронологическом порядке вставки записей. Индексы стабильного порядкового номера индексов. Кластерные индексы в ESE также должны быть первичными, что означает, что ключ должен быть уникальным.
Кластерные и некластеризованные индексы представлены с помощью B + деревьев. Если операция вызывает переполнение страницы, страница разделяется: выделяется новая страница, которая связывается между двумя ранее соседними страницами. Эта новая страница физически не примыкает к своим логическим соседям, доступ к ней не столь эффективен. ESE имеет функцию-сжатие, которая повторно уплотняет данные. Если ожидается, что таблица будет часто обновляться, можно зарезервировать место для будущих вставок, указав плотность страницы при создании таблицы или индекс. Это позволяет избежать или отложить операции разделения.
Запись - это связанный набор значений столбца. Записи вставляются и обновляются с помощью операций обновления и могут быть удалены с помощью операций удаления. Столбцы устанавливаются и извлекаются с помощью операций SetColumns и RetrieveColumns соответственно. Максимальный размер записи составляет 8110 байт для страниц размером 8 килобайт, за исключением столбцов с регулярными значениями. Типы столбцов LongText и LongBinary не вносят существенного вклада в это ограничение размера, и записи могут содержать данные, значительно превышающие размер страницы базы данных, когда данные хранятся в столбцах с постоянными значениями. Когда в записи хранится ссылка на длинное значение, требуются только 9 байтов записываемых данных. Эти длинные значения могут сами по себе иметь размер до 2 гигабайт (ГБ).
Записи обычно единообразны, поскольку каждая запись имеет набор значений для одного и того же набора столбцов. В ESE также можно определить много столбцов для таблицы, но при этом любая заданная запись будет содержать только небольшое количество значений столбца, отличных от NULL. В этом смысле таблица также может быть коллекцией разнородных записей.
ESE поддерживает диапазон значений столбцов размером от 1 бита до 2 ГБ. Выбор правильного типа столбца важен, потому что тип столбца многие его свойства, включая его порядок для индексов. ESE следующие следующие типы данных:
| Имя | Описание |
|---|---|
| Бит | троичное значение (NULL, 0 или 1) |
| Байт без знака | 1-байтовое целое число без знака |
| Короткое | 2-байтовое целое число со знаком |
| Беззнаковое короткое | 2-байтовое целое число без знака |
| Длинное | 4-байтовое целое число со знаком |
| Беззнаковое целое | 4-байтовое целое без знака |
| LongLong | 8-байтовое целое число со знаком |
| UnsignedLongLong | 8-байтовое целое число без знака |
| Валюта | 8-байтовое целое число со знаком |
| IEEE Single | 4-байтовое число с плавающей запятой |
| IEEE Double | 8-байтовое число с плавающей запятой |
| DateTime | 8-байтовое время-дата (целая дата, дробное время) |
| GUID | 16-байтовый уникальный идентификатор |
| двоичный | Двоичная строка, длина <= 255 bytes |
| Текст | Строка ANSI или Unicode, длина <= 255 bytes |
| Длинное двоично е | Большая двоичная строка, длина < 2 GB |
| Длинный текст | Большая строка ANSI или Unicode, длина < 2 GB |
Каждая таблица ESE может до определения 127 столбцов фиксированной длины, 128 столбцов длины и 64 993 столбцов с тегами.
Для данной таблицы столбцы попадают в одну из двух категорий: те, которые встречаются ровно один раз в каждой из записей, возможно, с размещенными значениями NULL; и те, которые встречаются редко или могут встречаться несколько раз в одной записи. Фиксированные и переменные столбцы к первой категории, а столбцы с тегами - ко второй. Внутреннее представление двух категорий столбцов отличается, и важно понимать компромиссы между категориями столбцов. Фиксированные и переменные столбцы обычно представлены в каждой записи, даже если вхождение имеет значение NULL. К этому столбцам можно быстро обратиться с помощью таблицы смещений. Вхождения столбца с тегами предшествуют указатору столбца, и столбец определяется путем двоичного поиска наборецов с тегами.
Типы столбцов Long Text и Long Binary предоставляют собой большие двоичные объекты. Они хранятся в отдельном дереве B + из кластерного индекса с ключомного значения id и байтового с длинного ущерба. ESE поддерживает добавление, перезапись диапазона байтов и установку размера для этих столбцов. Кроме того, в ESE есть функция хранения экземпляров одного экземпляра, в которой есть несколько файлов, которые могут ссылаться на один и тот же большой двоичный объект. Максимальный размер значения столбца Длинный текст или Длинный двоичный формат составляет 2 ГБ.
Столбцы версии автоматически увеличиваются ESE каждый раз, когда запись, содержащая этот столбец, изменяется с помощью операции обновления. Этот столбец не может быть установлен, но доступен только для чтения. Приложения столб версии включают использование определения обновления копии данной записи в памяти. Если значение в записи таблицы больше, чем значение в кэшированной копии, то известно, что кэшированная копия копииарела. Столбцы версии должны иметь тип Long.
Столбцы с автоматическим приращением автоматически устанавливаются ESE таким образом, чтобы значение, содержащееся в столбце, было уникальным для каждой записи в таблице. Эти столбцы, как и столбцы версии, не могут быть установлены приложением. Столбцы с автоматическим приращением доступны только для чтения и автоматически устанавливаются, когда новая запись вставляется в таблицу с помощью операций обновления. Значение в столбце остается постоянным в течение всего срока существования записи, и для каждой таблицы используется один столбец с автоматическим устройством. Столбцы с автоматическим приращением могут иметь тип Long или Currency.
Столбцы условного депонирования можно изменить с помощью операции EscrowUpdate. Депонированные обновления представить собой числовые дельта-операции. Столбцы условного депонирования должны иметь тип Long. Примеры числовых дельта-операций, включая добавление 2 к значению или вычитание 1 из значений. ESE отслеживает изменение значения, а не конечное значение обновления. Каждый из нескольких сеансов может иметь незавершенные изменения, внесенные через EscrowUpdate в одно и то же значение, поскольку ESE может определить фактическое конечное значение независимо от того, какие транзакции фиксируются, а какие откатываются. Это позволяет нескольким пользователям одновременно обновлять столбец, внося числовые изменения дельты. При желании ядра базы данных может стирать записи с нулевым значением столбца. Обычно такой столбец условного депонирования используется для счетчика ссылок: многие потоки увеличивают / уменьшают значение без блокировок, и когда счетчик нуля нуля, запись автоматически удаляется.
Индекс - это постоянное упорядочение записей в таблице. Индексы используются как для последовательного доступа к строкам в определенном порядке, так и для прямой навигации по алгоритмам на основе индексированных столбцов. Порядок, определяемый индексом, описывается в виде массива столбцов в порядке приоритета. Этот массив столбцов также называется индексным ключом. Каждый столбец называется сегментом сегмент. Каждый сегмент упорядочивающего взгляда может быть другим, либо нисходящим с точки зрения зрения. Для таблицы может быть определено любое количество индексов. ESE предоставляет богатый набор функций индексации.
Один индекс может быть указан как кластеризованный или первичный индекс. В ESE кластеризованный индекс должен быть уникальным и называется первичным индексом. Другие индексы описываются как некластеризованные или вторичные индексы. Первичные индексы отличаются от вторичных индексов тем, что индекс является самой записью, а не логическим указателем на запись. Вторичные индексы имеют первичные ключи на своих конечных точках для логической связи с записью в первичном индексе. Другими словами, таблица физически кластеризована в порядке первичного индекса. Получение данных неиндексированных записей в порядке первичного индекса обычно намного быстрее, чем в порядке вторичного индекса. Это связано с тем, что один доступ к сообщению внести в память несколько записей, к которому будет осуществлен доступ близко к другу во времени. Один и тот же доступ к диску позволяет выполнять несколько операций доступа к качеству. Однако вставка записи в середину индекса, как определено порядком первичного индекса, может быть намного медленнее, чем добавление ее в конец индекса. При проектировании таблицы необходимо выполнить частоту обновления с учетом шаблонов поиска. Если для таблицы не определен первичный индекс, создается неявный первичный индекс, называемый индексом ключа базы данных (DBK). DBK - это просто уникальный возрастающий номер, увеличивающийся каждый раз при вставке записи. В результате физический порядок записей в индексе DBK - это хронологический порядок вставки, и новые записи всегда добавляются в конец таблицы. Если приложение желает сгруппировать данные по неуникальному индексу, это возможно, добавив столбец автоинкремента в конец определения неуникального индекса.
Индексы могут быть по многозначным столбцам. В этих индексах может существовать несколько записей для позиций с значениями для индексированного столбца. Столбцы с используемыми значениями индексироваться вместе с столбцами с одним значением. Когда два или более столбца с размещенными значениями индексируются вместе, то свойство с указанными значениями учитывается только для первого столбца с указанными значениями в индексе. Столбцы с более низким приоритетом обрабатываются как однозначные.
Индексы также могут быть как разреженные. В разреженных индексах нет хотя бы одной записи для каждой записи в таблице. Есть несколько вариантов разреженного индекса. Существуют опции для исключения записей изексов, когда весь ключ индекса равен NULL, когда любой сегмент ключа равен NULL или когда только первый сегмент ключа равен NULL. Индексы также могут иметь условные столбцы. Эти столбцы никогда не появляются в индексе, но могут привести к тому, что запись не будет индексироваться, если условный столбец имеет значение NULL или не NULL.
Индексы также могут быть определены для включения одной записи для каждой подстроки текстового или длинного текстового столбца. Эти индексы называются индексами кортежей. Они используются для ускорения запросов с помощью предикатов сопоставления подстрок. Индексы кортежей можно определить только для текстовых столбцов. Например, если значение текстового столбца - «I love JET Blue», а индекс настроен так, чтобы иметь минимальный размер кортежа 4 символа и максимальную длину кортежа 10 символов, то следующие подстроки будут проиндексированы:
| «Я люблю JET». «люблю JET». «люблю JET B». «ove JET Bl». «ve JET Blu». «e JET Blue». «JET Blue». «JET Blue». «ET Blue». «T Blue». «Blue». «Blue». |
Даже если индексы кортежей могут быть очень большими, они могут значительно ускорить запросы формы: найти все записи, содержащие «JET Blue». Их можно использовать для подстрок, длиннее максимальной длины кортежа, путем деления подстроки поиска на строки поиска с максимальной длиной кортежа и пересечения результатов. Их можно использовать для точных совпадений строк, равных максимальной длине кортежа или коротких, равных минимальной длине кортежа, без пересечения индексов. Дополнительные сведения о выполнении пересечения индексов в ESE см. В разделе Пересечение индексов. Индексы кортежей не могут ускорить запросы, в которых строка поиска короче минимальной длины кортежа.
Транзакция - это логическая единица обработки, ограниченная операциями BeginTransaction и CommitTransaction, или откатом. Все обновления, выполняемые во время транзакции, являются атомарными; они либо все появляются в базе данных одновременно, либо не появляются ни одного. Любые последующие обновления другими транзакциями невидимы для транзакции. Однако транзакция может обновлять только данные, которые за это время не изменились; иначе операция сразу же завершится неудачно, не дожидаясь. Транзакциям только для чтения никогда не нужно ждать, а транзакции обновления могут мешать только транзакциям обновления друг друга. Транзакции, которые завершаются откатом или отказом системы, не оставляют следов в базе данных. Как правило, при откате состояние данных восстанавливается до того, что было до BeginTransaction.
Транзакции могут иметь до 7 уровней вложенности, при этом один дополнительный уровень зарезервирован для внутреннего использования ESE. Это означает, что часть транзакции может быть отменена без необходимости отката всей транзакции; CommitTransaction вложенной транзакции просто означает успех одной фазы обработки, а внешняя транзакция все еще может завершиться неудачей. Изменения фиксируются в базе данных только тогда, когда фиксируется самая внешняя транзакция. Это известно как фиксация на уровне транзакции 0. Когда транзакция фиксируется на уровне транзакции 0, данные, описывающие транзакцию, синхронно записываются в журнал, чтобы гарантировать, что транзакция будет завершена даже в случаепоследующего сбоя системы. Синхронная очистка журнала транзакций ESE долговечными. Однако в некоторых случаях приложение желает заказать обновления, но не сразу гарантирует, что изменения будут внесены. Здесь приложения могут фиксировать изменения с помощью JET_bitIndexLazyFlush.
ESE поддерживает механизм управления параллелизмом, называемый многовариантным. При многовариантном сеансе транзакции запрашивается согласованное представление всей базы данных, как это было в момент начала транзакции. Единственные обновления, с которым он сталкивается, - это сделанные им. Таким образом, каждая транзакция работает так, как если бы это была единственная активная транзакция, запущенная в системе, за исключением случаев ошибок записи. Механизм позволяет вносить изменения в систему чтения данных, которые уже были обновлены в других транзакциях, многоверсионное управление по себе не сериализуемых транзакций. Тем не менее, сериализуемость может быть достигнута при желании простого использования явных блокировок чтения записей для блокировки данных чтения, на основаны обновлений. Блокировки чтения и записи могут быть явно запрошены с помощью операции GetLock.
Кроме того, ESE поддерживает расширенную функцию управления параллелизмом, известную как блокировку условного депонирования. Блокировка депонирования - это условное условное обновление, при котором числовое значение изменяется относительным образом, то есть добавление вычитания другого числового значения. Обновления условного депонирования не конфликтуют даже с другими одновременными обновлениями условного депонирования в той же базе данных. Это возможно, независимо от того, зарегистрированы ли провозглашенные операции коммутируемыми. В результате они не мешают совместным транзакциям обновления. Эта функция часто используется для поддерживаемых агрегатов.
ESE также расширяет семантику транзакции от операций манипулирования данными до операций определения данных. Можно индексировать в таблице одновременно и транзакции, обновлять одну и ту же таблицу без каких-либо транзакций. Позже, когда эти транзакции завершены, вновь созданный индекс сообщений для всех транзакций и содержит записи для обновлений записей, сделанных другими транзакциями, которые не смогли определить индекс, когда имели место обновления. Операции определения данных со всеми функциями, ожидаемыми от механизма транзакций для обновления записей. Таким образом поддерживаются следующие операции определения данных: AddColumn, DeleteColumn, CreateIndex, DeleteIndex, CreateTable и DeleteTable.
Курсор - это логический указатель внутри индекса таблицы. Курсор может быть установлен на записи перед первой записью. Если курсор находится до или после записи, текущая запись нет. Можно link несколько курсоров в одном индексе таблицы. Многие операции с этим и столбцами основаны на позиции курсора. Положение курсора можно перемещать последовательно с помощью операций перемещения или с помощью индекса с операциями поиска. Курсоры также можно переместить в дробную позицию внутри индекса. Таким образом, курсор можно быстро переместить в положение ползунка. Эта операция выполняется с той же скоростью, что и операция поиска. Доступ к промежуточным данным запрещен.
Каждый курсор имеет буфер копирование для создания новой записи или изменения существующей записи, столбец за столбцом. Это изменить внутренний буфер, содержимое которого можно с помощью операций SetColumns. Модификации буфера копирования не изменяют автоматически сохраненные данные. Содержимое текущей записи можно скопировать в буфер копирования с помощью операции PrepareUpdate, а операции обновления сохраняют содержимое буфера копирования как запись. Буфер копирование неявно очищается при фиксации или откате транзакции, а также при операциях навигации. RetrieveColumns может быть одна для извлечения данных столбца либо из записи, либо из буфера копирования, если он существует.
Приложения ESE неизменно запрашивают свои данные. В этом разделе документа описываются функции и методы приложений для написания логики обработки запросов в ESE.
ESE предоставляет возможность сортировки в виде временных таблиц. Приложение вставляет записи данных в процесс сортировки по одной записи за раз, а затем извлекает их по одной записи в отсортированном. Сортировка выполняется между последней вставкой записи и получением первой записи. Временные приведенные набор программ для частичных и полных наборов результатов. Эти таблицы могут предлагать те же функции, что и базовые таблицы, включая возможность последовательного или прямого перехода к строкам с использованием ключей, соответствующих определению сортировки. Временные таблицы также могут обновляться для вычислений сложных агрегатов. Простые агрегаты могут быть вычислены автоматически с помощью функций аналогичной сортировки, когда желаемый агрегат является естественным результатом процесса сортировки.
Получение данных столбца непосредственно из вторичных индексов - важная оптимизация производительности. Столбцы могут быть непосредственно из вторичных индексов, без доступа к параметрам данных, с помощью флага RetrieveFromIndex в операции RetrieveColumns. При навигации по индексу гораздо эффективнее извлекать столбцы из вторичного индекса, чем из записи. Если данные столбца получены из записи, то дополнительная навигация для поиска записи по первичному ключу. Это может привести к дополнительным обращениям к диску. Когда индекс внутренние внутренние столбцы, он называется покрывающим индексом. Обратите внимание, что столбцы могут быть получены аналогичным образом с помощью JET_bitRetrieveFromPrimaryBookmark.
Ключи хранятся в нормализованной форме, которая во многих случаях может быть денормализована до исходного значения столбца. Нормализация не всегда обратима. Например, нельзя денормализовать тип столбцов «Текст» и «Длинный текст». Кроме того, ключи индекса могут быть усечены, если данные столбца очень длинные. В случаях, когда столбцы не могут быть получены напрямую из вторичных индексов, всегда можно получить доступ к записи для получения необходимых данных.
Запросы часто включают комбинацию ограничений на данные. Эффективным средством обработки ограничения использования доступного индекса. Однако, если запрос включает несколько ограничений, приложения часто обрабатывают ограничения, просматривая полный диапазон наиболее ограничительного предиката, удовлетворяемого одним индексом. Любой оставленный предикат, называемый остаточным предикатом, обрабатывается путем применения предиката к самой записи. Это простой метод, но его недостаток состоит в том, что для переноса записей в память для применения остаточного предиката может потребоваться много обращений к диску.
Пересечение индексов - важный механизм запросов, в котором используется несколько индексов вместе для более эффективной обработки сложного ограничения. Вместо использования только одного диапазона индексов по нескольким индексам объединяются, что приводит к большему количеству записей, к которому можно применить любой остаточный предикат. ESE упрощает это, предоставляя операцию IntersectIndexes. Эта использует серию диапазонов индексов для индексов из той же таблицы и возвращает временную таблицу первичных ключей, которую можно использовать для перехода к параметрам таблицы, удовлетворяющим всем предикатам индекс.
Объединение - это обычная операция в нормализованном дизайне таблиц, при которой логически связанные данные объединяются для использования в приложении. Соединения могут быть дорогостоящими операциями, потому что для переноса связанных данных в память может потребоваться много обращений к данным. В некоторых случаях эти усилия можно оптимизировать, определив одну базовую таблицу, содержащую данные для двух или более логических таблиц. Набор столбцов таблицы таблицы - это объединение наборов столбцов этих логических таблиц. Столбцы с тегами делают это благодаря хорошей обработке как многозначных, так и разреженных данных. Связанные данные хранятся вместе в одной записи. Этот процесс можно расширить до большого количества логических таблиц, поскольку ESE может поддерживать до 64 993 столбцов с. Индексы для определения многозначных столбцов, все еще возможно индексировать «внутренние» таблицы. Однако существуют некоторые ограничения, и приложениям следует использовать предварительное предварительное соединение, прежде чем использовать этот метод.
Функция ведения журнала и восстановления ESE поддерживает гарантированную целостность и согласованность данных в случае сбоя системы. Ведение журнала - это процесс избыточной записи обновления базы данных в файле журнала. Структура журнала очень устойчива к сбоям системы. Восстановление - это процесс использования этого журнала для восстановления баз данных до согласованного состояния после сбоя системы.
Операции транзакций регистрируются, и журнал сбрасывается на диск во время каждой фиксации на уровне 0. Это позволяет восстановление процесса повторять обновления, сделанные транзакциями, которые фиксируются на уровне транзакции 0, и отменять изменения, сделанные транзакциями, которые не зафиксировал уровень транзакции 0. Этот тип схемы восстановления часто называют схемой восстановления «с повтором транзакций». Журналы можно хранить до тех пор, пока данные не будут безопасно скопированы с помощью резервного копирования, ниже, или журналы можно повторно использовать циклически, как только они больше не нужны для восстановления после сбоя системы. Циклическое ведение журнала сводит к минимуму объема дискового пространства, необходимого для журнала, но влияет на возможность восстановления состояния данных в сбоя носителя.
Ведение журнала также играет роль в защите данных от сбоя носителя. ESE поддерживает резервное копирование в режиме онлайн, при котором происходит одно или несколько основных операций вместе с журналом таким образом. Базы данных могут продолжать запрашиваться и обновляться во время резервного копирования. Резервная копия называется «нечеткой резервной копией», потому что процесс восстановления должен запускаться как часть восстановления резервной копии для восстановления согласованного набора баз данных. Поддерживается как потоковое, так и теневое резервное копирование.
Потоковое резервное копирование - это требуемый метод резервного копирования, при копиях которого требуется всех файлов базы данных и необходимых файлов журналов в процессе резервного копирования. Копии файлов могут быть сохранены непосредственно на ленту или могут быть сделаны на любом другом устройстве хранения. При потоковом резервном копировании требуется никакой стабилизации активности. Как база данных, так и файлы создаются суммированием, чтобы проверить отсутствие повреждений данных в наборе данных во время процесса резервного копирования. Потоковые резервные копии также могут быть инкрементными. Инкрементные резервные копии - это те самые последние резервные копии, которые хранятся вместе с предыдущими резервными копиями.
Теневое копирование резервное копирование - это новый высокоскоростной метод резервного копирования. Резервное копирование теневых копий выполняется быстрее, поскольку копия создается после короткого периода приостановки приложения. При обновлениях данных виртуальная копия материализуется. В некоторых случаях аппаратная поддержка резервных копий теневых копий означает, что фактическое сохранение виртуальных копий не требуется. Резервные копии теневых копий всегда являются полными.
Восстановление можно использовать для применения одной резервной копии или применения комбинации одной резервной копии с одним или использованием инкрементными резервными копиями. Восстановление резервной копии может быть выполнено в любой системе, поддерживающей исходное приложение. Это не обязательно должна быть одна и та же машина или даже конфигурация машины. Расположение файлов можно изменить в процессе восстановления.
При создании базы данных ESENT размер физического сектора диска сохраняется вместе с базой данных. Ожидается, что размер физического сектора останется неизменным между сеансами; в противном случае выдается сообщение об ошибке. Когда физический диск клонируется или восстанавливается из образа диска на диск, который использует другой размер физического сектора (Advanced Format Drives), ESENT сообщает об ошибках.
Это известная проблема, и Microsoft предлагает оперативные исправления. Для Windows Vista или Windows Server 2008 см. KB2470478. Для Windows 7 или Windows Server 2008 R2 см. KB982018.
JET Blue изначально был разработан Microsoft как предполагаемое обновление для ядра базы данных JET Red в Microsoft Access, но никогда не использовался в этой роли. Вместо этого он стал использоваться Exchange Server, Active Directory, службой репликации файлов (FRS), Security Редактор конфигурации, службы сертификации, Служба имен в Интернете Windows (WINS) и множество других служб, приложений и компонентов Windows Microsoft. В течение лет это был частный API, используемый только Microsoft, но с ним он стал опубликованным API, которым можно пользоваться каждый.
Работа над механизмом доступа к данным (DAE) началась в марте 1989 года, когда Аллен Рейтер присоединился к Microsoft. В течение года группа из четырех разработчиков на Аллена, чтобы в степени завершить ISAM. У Microsoft уже был BC7 ISAM (JET Red), но он начал над механизмом доступа к данным (DAE) для создания более надежного механизма базы данных в качестве входа в область новой архитектуры клиент-сервер. Весной 1990 года команды BC7 ISAM и DAE объединились, чтобы создать компанию Joint Engine Technology (JET); отвечает за создание двух движков v1 (JET Red ) и v2 (JET Blue), которые соответствуют одной спецификации API (JET API). DAE стала JET Blue за цвет флага Израиля. BC7 ISAM JET Красный за цвет стал флага России. Хотя JET Blue и JET Red были написаны в соответствии с той же спецификацией API, они не разделяли никакого кода ISAM. Оба они поддерживали общий обработчик запросов QJET, который позже вместе с BC7 ISAM стал синонимом JET Red.
JET Blue впервые был выпущен в 1994 году как ISAM для WINS, DHCP и ныне несуществующих служб RPL в Windows NT 3.5. В 1996 году он снова появился в качестве механизма хранения для Microsoft Exchange. Дополнительные службы Windows выбрали JET Blue в качестве технологии хранения, и к 2000 году каждую версию Windows начала поставляться с JET Blue. JET Blue использовался Active Directory и стал частью специального набора кода Windows, называемого Trusted Computing Base (TCB). Количество приложений Microsoft, использующих JET Blue, продолжает расти, и в 2005 году опубликован опубликованный JET Blue API, чтобы облегчить постоянно растущим использование приложений и служб как в Windows, так и за ее пределами.
В записи веб-блога Microsoft Exchange утверждает, что разработчики, внесли свой вклад в JET Blue, включая Чина Ляо, Стивена Хехта, Мэтью Беллью, Иана Хосе, Эдварда «Эдди» Гилберта, Кеннета Кин Лам, Баласубраманиана Шрирама, Джонатана Лима, Эндрю Гудселл, Лаурион Берчалл, Андрей Маринеску, Адам Фоксман, Иван Триндев, Спенсер Лоу и Бретт Ширли.
Хотя они имеют общее происхождение, между JET Red и ESE есть огромные различия.
