Расширяемый механизм хранения - Extensible Storage Engine

Расширяемый механизм хранения (ESE), также известный как JET Синий, является ISAM (индексированный метод последовательного доступа) технология хранения данных от Microsoft. ESE - это ядро Сервер Microsoft Exchange, Active Directory, и Поиск Windows. Он также используется рядом компонентов Windows, включая Центр обновления Windows клиент и Центр помощи и поддержки. Его цель - позволить приложениям сохранять и извлекать данные с помощью индексированного и последовательного доступа.

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),^[1] организован в сбалансированном B-дерево структура.^[2] Эти страницы содержат метаданные для описания данных, содержащихся в базе данных, самих данных, индексов для сохранения интересных порядков данных и другой информации. Эта информация перемешана в файле базы данных, но прилагаются усилия, чтобы данные, используемые вместе, были сгруппированы вместе в базе данных. База данных ESE может содержать до 2³² страниц, или 16 терабайты данных,^[3] для 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 поддерживает следующие типы данных:

Типы столбцов

Фиксированные, переменные и помеченные столбцы

Каждая таблица ESE может определять до 127 столбцов фиксированной длины, 128 столбцов переменной длины и 64 993 столбца с тегами.

• Фиксированные столбцы - это, по сути, столбцы, которые занимают одинаковое количество места в каждой записи, независимо от их значения. Фиксированные столбцы занимают 1 бит, чтобы представить NULL для значения столбца, и фиксированный объем пространства в каждой записи, в которой установлен этот столбец или определенный позже фиксированный столбец.
• Переменные столбцы - это, по сути, столбцы, которые занимают разное пространство в каждой записи, в которой они установлены, в зависимости от размера конкретного значения столбца. Переменные столбцы занимают 2 байта для определения NULLity и размера, а также переменный объем пространства в каждой записи, в которой установлен этот столбец.
• Столбцы с тегами - это столбцы, которые не занимают места, если они не заданы в записи. Они могут быть однозначными, но могут быть и многозначными. Один и тот же помеченный столбец может иметь несколько значений в одной записи. Когда в записи заданы столбцы с тегами, каждый экземпляр столбца с тегами занимает примерно 4 байта в дополнение к размеру значения экземпляра столбца с тегами. Когда количество экземпляров одного столбца с тегами велико, накладные расходы на каждый экземпляр столбца с тегами составляют примерно 2 байта. Столбцы с тегами идеально подходят для разреженных столбцов, потому что они не занимают места, если не заданы. Если индексируется столбец с тегами с несколькими значениями, индекс будет содержать одну запись для записи для каждого значения столбца с тегами.

Для данной таблицы столбцы попадают в одну из двух категорий: те, которые встречаются ровно один раз в каждой из записей, возможно, с несколькими значениями 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.

Индексы кортежей

Индексы также могут быть определены для включения одной записи для каждой подстроки текстового или длинного текстового столбца. Эти индексы называются индексами кортежей. Они используются для ускорения запросов с предикатами сопоставления подстрок. Индексы кортежей можно определить только для текстовых столбцов. Например, если значение текстового столбца «Я люблю JET Blue», а индекс настроен так, чтобы иметь минимальный размер кортежа из 4 символов и максимальную длину кортежа из 10 символов, тогда будут проиндексированы следующие подстроки:

Несмотря на то, что индексы кортежей могут быть очень большими, они могут значительно ускорить запросы формы: найти все записи, содержащие «JET Blue». Их можно использовать для подстрок, длиннее максимальной длины кортежа, путем деления подстроки поиска на строки поиска с максимальной длиной кортежа и пересечения результатов. Их можно использовать для точных совпадений строк, равных максимальной длине кортежа, или таких же коротких, как минимальная длина кортежа, без пересечения индексов. Для получения дополнительной информации о выполнении пересечения индексов в ESE см. Индекс пересечения. Индексы кортежей не могут ускорить запросы, в которых строка поиска короче минимальной длины кортежа.

Сделки

Транзакция - это логическая единица обработки, ограниченная операциями BeginTransaction и CommitTransaction или Rollback. Все обновления, выполняемые во время транзакции, атомарны; они либо все появляются в базе данных одновременно, либо не появляются ни одного. Любые последующие обновления другими транзакциями невидимы для транзакции. Однако транзакция может обновлять только те данные, которые за это время не изменились; иначе операция завершится неудачей, не дожидаясь. Транзакциям только для чтения никогда не нужно ждать, а транзакции обновления могут мешать только транзакциям обновления друг друга. Транзакции, которые завершаются откатом или отказом системы, не оставляют следов в базе данных. Как правило, при откате состояние данных восстанавливается до того, что было до BeginTransaction.

Транзакции могут иметь до 7 уровней вложенности, при этом один дополнительный уровень зарезервирован для внутреннего использования ESE. Это означает, что часть транзакции может быть отменена без необходимости отката всей транзакции; CommitTransaction вложенной транзакции просто означает успех одной фазы обработки, а внешняя транзакция все еще может завершиться неудачей. Изменения фиксируются в базе данных только тогда, когда фиксируется самая внешняя транзакция. Это называется фиксацией на уровне транзакции 0. Когда транзакция фиксируется на уровне транзакции 0, данные, описывающие транзакцию, синхронно записываются в журнал, чтобы гарантировать, что транзакция будет завершена даже в случае последующего сбоя системы. Синхронная очистка журнала делает транзакции ESE долговечными. Однако в некоторых случаях приложение желает заказать их обновления, но не сразу гарантирует, что изменения будут внесены. Здесь приложения могут фиксировать изменения с помощью JET_bitIndexLazyFlush.

ESE поддерживает механизм управления параллелизмом, называемый многовариантным управлением. При многовариантном управлении каждая транзакция запрашивает согласованное представление всей базы данных, как это было в момент начала транзакции. Единственные обновления, с которыми он сталкивается, - это сделанные им. Таким образом, каждая транзакция работает так, как если бы это была единственная активная транзакция, запущенная в системе, за исключением случаев конфликтов записи. Поскольку транзакция может вносить изменения на основе чтения данных, которые уже были обновлены в другой транзакции, многоверсионное управление само по себе не гарантирует сериализуемый транзакции. Тем не мение, сериализуемость при желании может быть достигнуто путем простого использования явных блокировок чтения записей для блокировки данных чтения, на которых основаны обновления. Блокировки чтения и записи могут быть явно запрошены с помощью операции GetLock.

Кроме того, ESE поддерживает расширенную функцию управления параллелизмом, известную как блокировка условного депонирования. Блокировка условного депонирования - это чрезвычайно одновременное обновление, при котором числовое значение изменяется относительным образом, то есть путем добавления или вычитания другого числового значения. Обновления условного депонирования не конфликтуют даже с другими одновременными обновлениями условного депонирования в той же базе данных. Это возможно, потому что поддерживаемые операции коммутируемы и могут быть независимо зафиксированы или отменены. В результате они не мешают одновременным транзакциям обновления. Эта функция часто используется для поддерживаемых агрегатов.

ESE также расширяет семантику транзакций от операций манипулирования данными до операций определения данных. Можно добавить индекс к таблице и одновременно выполняющие транзакции обновлять одну и ту же таблицу без каких-либо конфликтов блокировки транзакций. Позже, когда эти транзакции завершены, вновь созданный индекс доступен для всех транзакций и содержит записи для обновлений записей, сделанных другими транзакциями, которые не могли определить наличие индекса, когда обновления имели место. Операции определения данных могут выполняться со всеми функциями, ожидаемыми от механизма транзакций для обновления записей. Таким образом поддерживаются следующие операции определения данных: AddColumn, DeleteColumn, CreateIndex, DeleteIndex, CreateTable и DeleteTable.

Курсорная навигация и буфер копирования

Курсор - это логический указатель в индексе таблицы. Курсор может быть установлен на записи перед первой записью, после последней записи или даже между записями. Если курсор находится до или после записи, текущей записи нет. Можно разместить несколько курсоров в одном индексе таблицы. Многие операции с записями и столбцами основаны на позиции курсора. Положение курсора можно перемещать последовательно с помощью операций перемещения или напрямую с помощью клавиш индекса с операциями поиска. Курсоры также можно переместить в дробную позицию внутри индекса. Таким образом, курсор можно быстро переместить в положение ползунка. Эта операция выполняется с той же скоростью, что и операция поиска. Доступ к промежуточным данным запрещен.

Каждый курсор имеет буфер копирования для создания новой записи или изменения существующей записи, столбец за столбцом. Это внутренний буфер, содержимое которого можно изменить с помощью операций SetColumns. Модификации буфера копирования не изменяют автоматически сохраненные данные. Содержимое текущей записи может быть скопировано в буфер копирования с помощью операции PrepareUpdate, а операции обновления сохраняют содержимое буфера копирования как запись. Буфер копирования неявно очищается при фиксации или откате транзакции, а также при операциях навигации. RetrieveColumns может использоваться для извлечения данных столбца либо из записи, либо из буфера копирования, если он существует.

Обработка запросов

Приложения ESE неизменно запрашивают свои данные. В этом разделе документа описываются функции и методы приложений для написания логики обработки запросов в ESE.

Сортировки и временные таблицы

ESE предоставляет возможность сортировки в виде временных таблиц. Приложение вставляет записи данных в процесс сортировки по одной записи за раз, а затем извлекает их по одной записи в отсортированном порядке. Сортировка фактически выполняется между последней вставкой записи и получением первой записи. Временные таблицы также могут использоваться для частичных и полных наборов результатов. Эти таблицы могут предлагать те же функции, что и базовые таблицы, включая возможность последовательного или прямого перехода к строкам с использованием ключей индекса, соответствующих определению сортировки. Временные таблицы также можно обновлять для вычисления сложных агрегатов. Простые агрегаты могут быть вычислены автоматически с помощью функции, аналогичной сортировке, когда желаемый агрегат является естественным результатом процесса сортировки.

Индексы покрытия

Получение данных столбца непосредственно из вторичных индексов - важная оптимизация производительности. Столбцы могут быть получены непосредственно из вторичных индексов, без доступа к записям данных, с помощью флага RetrieveFromIndex в операции RetrieveColumns. При навигации по индексу гораздо эффективнее извлекать столбцы из вторичного индекса, чем из записи. Если данные столбца были получены из записи, то необходима дополнительная навигация, чтобы найти запись по первичному ключу. Это может привести к дополнительным обращениям к диску. Когда индекс содержит все необходимые столбцы, он называется покрывающим индексом. Обратите внимание, что столбцы, определенные в первичном индексе таблицы, также находятся во вторичных индексах и могут быть получены аналогичным образом с помощью JET_bitRetrieveFromPrimaryBookmark.

Ключи индекса хранятся в нормализованной форме, которая во многих случаях может быть денормализована до исходного значения столбца. Нормализация не всегда обратима. Например, нельзя денормализовать типы столбцов «Текст» и «Длинный текст». Кроме того, ключи индекса могут быть усечены, если данные столбца очень длинные. В случаях, когда столбцы не могут быть получены напрямую из вторичных индексов, всегда можно получить доступ к записи для получения необходимых данных.

Индекс пересечения

Запросы часто включают комбинацию ограничений на данные. Эффективным средством обработки ограничения является использование доступного индекса. Однако, если запрос включает несколько ограничений, приложения часто обрабатывают ограничения, просматривая полный диапазон индексов наиболее ограничительного предиката, удовлетворяемого одним индексом. Любой оставшийся предикат, называемый остаточным предикатом, обрабатывается путем применения предиката к самой записи. Это простой метод, но его недостаток состоит в том, что для переноса записей в память для применения остаточного предиката может потребоваться много обращений к диску.

Пересечение индексов - важный механизм запросов, в котором несколько индексов используются вместе для более эффективной обработки сложного ограничения. Вместо использования только одного индекса диапазоны индексов по нескольким индексам объединяются, что приводит к гораздо меньшему количеству записей, к которым можно применить любой остаточный предикат. ESE упрощает это, предоставляя операцию IntersectIndexes. Эта операция принимает серию диапазонов индексов для индексов из той же таблицы и возвращает временную таблицу первичных ключей, которую можно использовать для перехода к записям базовой таблицы, удовлетворяющим всем предикатам индекса.

Предварительно соединенные таблицы

Соединение - это обычная операция для нормализованного дизайна таблицы, когда логически связанные данные собираются вместе для использования в приложении. Соединения могут быть дорогостоящими операциями, потому что для переноса связанных данных в память может потребоваться много обращений к данным. В некоторых случаях эти усилия можно оптимизировать, определив одну базовую таблицу, содержащую данные для двух или более логических таблиц. Набор столбцов базовой таблицы - это объединение наборов столбцов этих логических таблиц. Столбцы с тегами делают это возможным благодаря хорошей обработке как многозначных, так и разреженных данных. Поскольку связанные данные хранятся вместе в одной записи, доступ к ним осуществляется вместе, что сводит к минимуму количество обращений к диску для выполнения соединения. Этот процесс можно расширить до большого количества логических таблиц, поскольку ESE может поддерживать до 64 993 столбцов с тегами. Поскольку индексы могут быть определены для многозначных столбцов, все еще возможно индексировать «внутренние» таблицы. Однако существуют некоторые ограничения, и приложениям следует тщательно рассмотреть предварительное соединение, прежде чем использовать этот метод.

Ведение журнала и восстановление после сбоя

Функция ведения журнала и восстановления ESE поддерживает гарантированную целостность и согласованность данных в случае сбоя системы. Ведение журнала - это процесс избыточной записи операций обновления базы данных в файл журнала. Структура файла журнала очень устойчива к сбоям системы. Восстановление - это процесс использования этого журнала для восстановления баз данных до согласованного состояния после сбоя системы.

Операции транзакций регистрируются, и журнал сбрасывается на диск во время каждой фиксации на уровне транзакции 0. Это позволяет процессу восстановления повторять обновления, сделанные транзакциями, которые фиксируются на уровне транзакции 0, и отменять изменения, сделанные транзакциями, которые не были зафиксированы на уровне транзакции. 0. Этот тип схемы восстановления часто называют схемой восстановления «с повтором / откатом назад». Журналы могут храниться до тех пор, пока данные не будут безопасно скопированы с помощью процесса резервного копирования, описанного ниже, или журналы можно повторно использовать циклически, как только они больше не нужны для восстановления после сбоя системы. Циклическое ведение журнала сводит к минимуму объем дискового пространства, необходимого для журнала, но влияет на возможность воссоздания состояния данных в случае сбоя носителя.

Резервное копирование и восстановление

Ведение журнала и восстановление также играют роль в защите данных от сбоя носителя. ESE поддерживает резервное копирование в режиме онлайн, при котором копируются одна или несколько баз данных вместе с файлами журнала таким образом, чтобы это не влияло на операции с базой данных. Базы данных могут продолжать запрашиваться и обновляться во время резервного копирования. Резервная копия называется «нечеткой резервной копией», потому что процесс восстановления должен запускаться как часть восстановления резервной копии для восстановления согласованного набора баз данных. Поддерживаются как потоковое, так и теневое резервное копирование.

Потоковое резервное копирование - это метод резервного копирования, при котором копии всех необходимых файлов базы данных и необходимых файлов журналов создаются в процессе резервного копирования. Копии файлов могут быть сохранены непосредственно на ленту или могут быть сделаны на любом другом устройстве хранения. При потоковом резервном копировании не требуется никакой стабилизации активности. Как база данных, так и файлы журнала проверяются суммированием, чтобы гарантировать отсутствие повреждений данных в наборе данных во время процесса резервного копирования. Потоковые резервные копии также могут быть инкрементными. Инкрементные резервные копии - это те, в которых копируются только файлы журнала и которые можно восстановить вместе с предыдущей полной резервной копией, чтобы привести все базы данных в последнее состояние.

Теневая копия резервное копирование - это новый высокоскоростной метод резервного копирования. Резервное копирование теневых копий происходит значительно быстрее, потому что копия фактически создается после короткого периода приостановки приложения. По мере последующих обновлений данных виртуальная копия материализуется. В некоторых случаях аппаратная поддержка резервных копий теневых копий означает, что фактическое сохранение виртуальных копий не требуется. Резервные копии теневых копий всегда являются полными.

Восстановление можно использовать для применения одной резервной копии или для применения комбинации одной полной резервной копии с одной или несколькими инкрементными резервными копиями. Кроме того, любые существующие файлы журналов также могут быть воспроизведены для воссоздания всего набора данных вплоть до последней транзакции, зарегистрированной как зафиксированная на уровне транзакции 0. Восстановление резервной копии может быть выполнено в любой системе, способной поддерживать исходное приложение. Это не обязательно должна быть одна и та же машина или даже конфигурация машины. Расположение файлов можно изменить в процессе восстановления.

Резервное копирование и восстановление на различное оборудование

Когда создается база данных ESENT, физическая сектор диска размер хранится в базе данных. Ожидается, что размер физического сектора останется неизменным между сеансами; в противном случае выдается сообщение об ошибке. Когда физический диск клонируется или восстанавливается из образа диска на диск, который использует другой размер физического сектора (Расширенный формат Диски), ESENT сообщит об ошибках. ^[4]

Это известная проблема, и Microsoft предлагает оперативные исправления. Для Windows Vista или Windows Server 2008 см. KB2470478. ^[5] Для Windows 7 или Windows Server 2008 R2 см. KB982018.^[6]

История

JET Blue был первоначально разработан Microsoft как предполагаемое обновление для JET Красный ядро базы данных в Microsoft Access, но никогда не использовался в этой роли. Вместо этого он стал использоваться Exchange Server, Active Directory, Служба репликации файлов (FRS), редактор конфигурации безопасности, службы сертификации, Служба имен в Интернете Windows (WINS) и множество других служб, приложений и компонентов Windows Microsoft.^[7] В течение многих лет это был частный API, используемый только Microsoft, но с тех пор он стал опубликованным API, которым может пользоваться каждый.

Работа над механизмом доступа к данным (DAE) началась в марте 1989 года, когда Аллен Рейтер присоединился к Microsoft. В течение следующего года группа из четырех разработчиков работала на Аллена, чтобы в значительной степени завершить ISAM. У Microsoft уже был BC7 ISAM (JET Red), но он начал работу над механизмом доступа к данным (DAE) для создания более надежного механизма базы данных в качестве входа в область новой тогда архитектуры клиент-сервер. Весной 1990 года команды BC7 ISAM и DAE объединились, чтобы создать компанию Joint Engine Technology (JET); отвечает за производство двух двигателей v1 (JET Красный ) и v2 (JET Blue), которые соответствовали бы той же спецификации API (JET API). DAE стала JET Blue за цвет флага Израиля. BC7 ISAM стал JET Red за цвет флага России. Хотя JET Blue и JET Red были написаны в соответствии с одной и той же спецификацией API, они не разделяли никакого кода ISAM. Они оба поддерживали общий обработчик запросов QJET, который позже вместе с BC7 ISAM стал синонимом JET Red.

JET Blue впервые был выпущен в 1994 году как ISAM для WINS, DHCP и ныне несуществующего РПЛ сервисы в 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^[8] заявил, что разработчики, которые внесли свой вклад в JET Blue, включают Чин Ляо, Стивен Хехт, Мэтью Беллью, Ян Хосе, Эдвард «Эдди» Гилберт, Кеннет Кин Лам, Баласубраманиан Шрирам, Джонатан Лием, Эндрю Гудселл, Лаурион Берчалл, Андрей Маринеску, Адам Фоксман, Иван Триндев, Спенсер Лоу и Бретт Ширли.

Сравнение с JET Red

Хотя они имеют общую родословную, между ними существуют огромные различия. JET Красный и ESE.

• JET Red - это технология обмена файлами, тогда как ESE предназначен для встраивания в серверное приложение и не предоставляет общий доступ к файлам.
• JET Red делает все возможное для восстановления файлов, в то время как ESE поддерживает ведение журнала с упреждающей записью и изоляцию моментальных снимков для гарантированного восстановления после сбоя.
• JET Red до версии 4.0 поддерживает только блокировку на уровне страницы, в то время как ESE и JET Red версии 4.0 поддерживают блокировку на уровне записи.
• JET Red поддерживает широкий спектр интерфейсов запросов, включая ODBC и OLE DB. ESE не поставляется с механизмом запросов, но вместо этого полагается на приложения для написания собственных запросов как C Код ISAM.
• JET Red имеет максимальный размер файла базы данных 2 ГиБ, в то время как ESE имеет максимальный размер файла базы данных 8 TiB с 4 KiB страниц и 16 ТиБ со страницами 8 КиБ.

Рекомендации

• «Биржевая терминология». Архивировано из оригинал на 2008-11-09. Получено 2015-08-20.
• «Расширяемый механизм хранения». Microsoft. Получено 2015-08-20.
• «Понимание основ хранилища информации». Архивировано из оригинал 9 июня 2007 г.. Получено 2007-06-18.
• «Справочник по расширяемому механизму хранения». Получено 2014-07-22.