Расширяемые файлы подсистемы хранилища

  • Статья

Применимо к: Windows | Windows Server

Расширяемые файлы подсистемы хранилища

Подсистема расширяемого хранилища использует следующие типы файлов:

Эта таблица содержит общие сведения об именах файлов данных, управляемых ESE. Для Windows Vista и более поздних версий параметр JET_paramLegacyNames влияет на используемые имена файлов.

Метка Значение

Файлы журнала транзакций

Файлы журнала транзакций содержат операции с файлами базы данных. Они содержат достаточно информации, чтобы привести базу данных в логически согласованное состояние после непредвиденного завершения процесса или завершения работы системы.

Имена файлов журналов зависят от базового имени из трех букв, которое можно задать с помощью JET_paramBaseName. В приведенных ниже примерах используется базовое имя "edb", так как это базовое имя по умолчанию. Расширение для файлов журнала транзакций будет .log или .jtx в зависимости от того, задана ли JET_bitESE98FileNames в параметре JET_paramLegacyFileNames. Дополнительные сведения см. в разделе Расширяемые системные параметры подсистемы хранилища.

Файлы журнала транзакций называются <base><generation-number.log>, начиная с 1. Номер создания журнала имеет шестнадцатеричный формат. Например, edb00001.log является первым журналом, а edb000ff.log — 255-м журналом. Файлы журнала имеют пять шестнадцатеричных цифр в имени файла журнала до 1048576-го файла журнала, после чего файлы журнала начинают называться в формате 11,3 (например, edb00100000.log). <Base.log> всегда является файлом журнала, который используется в настоящее время. Если ядро СУБД неактивно, генерацию edb.log можно определить с помощью следующей команды: esentutl.exe -ml edb.log.

Хотя файлы журнала транзакций имеют . Расширение LOG, обычно связанное с текстовыми файлами, файлы журнала транзакций имеют двоичный формат и никогда не должны изменяться пользователем. Операции базы данных сначала записываются в журнал. Данные можно записать в файл базы данных позже; возможно сразу, потенциально гораздо позже. В случае непредвиденного завершения процесса или системы операции по-прежнему присутствуют в файлах журнала, и можно выполнить откат незавершенных транзакций. Процесс повторения файлов журнала транзакций называется обратимым восстановлением и выполняется автоматически при вызове JetInit или JetInit2 . Обратимое восстановление также можно выполнить вручную с помощью параметра "-r" программы Esentutl.exe. Процесс воспроизведения файлов журнала транзакций в базе данных, восстановленной из резервной копии, называется жестким восстановлением.

Файлы журналов имеют фиксированный размер и настраиваются с помощью JET_paramLogFileSize. Когда текущий файл журнала (то есть edb.log) заполняется, он переименовывается <в base-number.log><>, а в потоке журнала транзакций требуется новый файл журнала транзакций.

С каждым экземпляром базы данных связана одна последовательность файлов журнала. Windows XP представила JetCreateInstance, что позволяет использовать несколько последовательностей файлов журнала транзакций одним процессом. Однако несколько последовательностей файлов журнала транзакций не могут находиться в одном каталоге.

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

Файлы журнала транзакций будут удалены ядром СУБД во время полного резервного копирования (см. статьи JetBackup, JetTruncateLog, JetTruncateLogInstance) или во время обычных операций, если включено циклическое ведение журнала.

После заполнения файла журнала транзакций ядро СУБД должно создать новый файл журнала. Циклическое ведение журнала — это средство, с помощью которого файлы журнала могут быть автоматически очищены ядром СУБД, когда они больше не требуются для аварийного восстановления. Этот процесс является альтернативой удалению файлов журнала в качестве дополнительного продукта выполнения резервного копирования. Циклическим ведением журнала можно управлять с помощью системного параметра JET_paramCircularLog . Файлы журнала транзакций не следует удалять с помощью других методов.

Временные файлы журнала транзакций

Когда файл edb.log заполняется, ESE необходимо создать новый файл. Новый файл транзакций журнала называется временным файлом журнала транзакций до его использования ESE.

При создании нового файла журнала и расширении его размера он будет называться <базовым>tmp.log. Создание нового файла может быть потенциально дорогостоящей операцией, поэтому ESE создаст следующий файл журнала заранее в качестве фоновой задачи.

Так как временный файл журнала транзакций создается с учетом необходимости создания нового файла журнала транзакций, он не содержит полезных сведений.

Зарезервированные файлы журнала транзакций

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

Windows Vista: В Windows Vista и более поздних версиях файлы зарезервированных журналов транзакций называются <base>RESXXXXX.jrs.

Windows Server 2003: В Windows Server 2003 и более ранних версиях зарезервированные файлы журнала транзакций имеют имена res1.log и res2.log.

Если в ядре СУБД заканчивается дисковое пространство, он не может создать новый файл журнала. Безопаснее всего завершить работу, но некоторые операции (например, откат) по-прежнему должны записываться в журнал. На этом этапе большинство операций базы данных завершатся сбоем.

Так как зарезервированные файлы журнала транзакций создаются с учетом необходимости в файлах журнала транзакций в сценарии с отсутствием диска, они не содержат полезных сведений.

файлы контрольных точек

В файле контрольных точек хранится контрольная точка для определенной последовательности файлов журнала транзакций. Файл контрольной точки называется <base.chk> или <base.jcp> в зависимости от того, задана ли JET_bitESE98FileNames в параметре JET_paramLegacyFileNames, а его расположение определяется JET_paramSystemPath.

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

  • Записывается в файл журнала транзакций и файл базы данных.

  • Записывается в файл журнала транзакций и еще не записывается в файл базы данных.

Многие операции базы данных могут храниться в одном файле журнала транзакций. Данный файл журнала может состоять из следующих элементов:

  • Все операции, записанные в файл базы данных.

  • Нет операций, записанных в файл базы данных

  • Сочетание операций, записанных в файл базы данных, и операций, еще не записанных в файл базы данных.

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

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

Файлы базы данных

Файл базы данных содержит схему для всех таблиц в базе данных, записи для всех таблиц в базе данных и индексы в таблицах. Его расположение определяется с помощью JetCreateDatabase, JetCreateDatabase2, JetAttachDatabase или JetAttachDatabase2.

База данных завершает работу только после успешного вызова JetTerm или JetTerm2.

Программа Esentutl.exe может определить, правильно ли завершается работа базы данных с помощью параметра -mh. Например, esentutl.exe -mh sample.edb считывает заголовок базы данных с именем sample.edb и выводит состояние sample.edb. Он может вывести "Состояние: чистое завершение работы" или "Состояние: грязное завершение работы".

База данных, которая не была полностью завершена, находится в состоянии грязное завершения работы. До Windows XP это состояние называлось несогласованным. Грязное (несогласованные) базы данных можно привести в чистое состояние с помощью обратимого восстановления. Поврежденная база данных отличается от грязное ("несогласованной") базы данных.

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

Безопасно перемещать или переименовывать можно только чисто завершенные базы данных. Если база данных не была полностью завершена, ее нельзя будет автоматически безопасно переместить или переименовать.

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

Временные базы данных

Временная база данных используется в качестве резервного хранилища для заманчивых и также используется при создании индексов.

Имя и расположение настраиваются с помощью JET_paramTempPath.

Заманчивые создаются с помощью JetOpenTempTable, JetOpenTempTable2, JetOpenTempTable3, JetOpenTemporaryTable. Они также создаются некоторыми вызовами API и используются для возврата сведений о схеме (например , JetGetIndexInfo).

Очистка файлов карты

Начиная с юбилейного обновления Windows 10 (клиент) и Windows Server 2016 (сервер), ESE добавил дополнительный уровень защиты от потери операций записи (или потери сбросов) 1, что позволило обнаруживать такие события повторной инициализации между процессами2. Эта функция требует сохранения метаданных в отдельном файле, который называется файлом карты очистки.

Для каждого файла базы данных создается один файл карты очистки и находится в том же каталоге. Имя файла аналогично файлу базы данных, но с другим расширением. Например, если клиентское приложение создает базу данных с полным путем C:\MyDirectory\MyDabatase.edb, соответствующий файл карты очистки — C:\MyDirectory\MyDabatase.jfm.

Это расширение вводит два требования к именам файлов базы данных:

  • Две базы данных в одном каталоге не должны иметь одинаковые имена файлов с разными расширениями. Например: C:\MyDirectory\MyDabatase.db1 и C:\MyDirectory\MyDabatase.db2.

  • 2. База данных не должна иметь расширение JFM.

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

Размер файла карты очистки прямо пропорционален связанному с ним файлу базы данных и примерно равен (все размеры в байтах, результат должен округлиться до следующего кратного 8192):

8,192 + ((<database file size> / <database page size>) / 4)

Например, для базы данных размером 1,5 ГБ с размером страницы 32 КБ приблизительный размер карты сброса составляет 24 576 байт (или 24 КБ).

Файл карты очистки необходимо обновить по мере очистки страниц базы данных. Если ведение журнала транзакций включено (например, JET_paramRecovery значение по умолчанию), обновление карты очистки выполняется по мере внесения клиентским приложением изменений в базу данных. В среднем вся карта сброса записывается на энергонезависимый носитель один раз для каждых 20 % JET_paramCheckpointDepthMax (в байтах) создаваемых журналов транзакций. Количество операций записи зависит от распределения изменений в базе данных. Но это не более, приблизительно (все размеры в байтах):

<flush map file size> / JET_paramMaxCoalesceWriteSize

Если ведение журнала транзакций отключено (например, JET_paramRecovery задано значение off), карта очистки обновляется только один раз, если база данных явно отсоединена (через JetDetachDatabase или неявно отсоединена путем завершения связанного экземпляра ESE (с помощью любой из функций JetTerm , если JET_bitTermDirty не пройдена).

1 Потерянная запись (или потеря записи) определяется как операция записи, которая успешно возвращается из операционной системы в ядро СУБД ESE, но фактические данные никогда не сохраняются в файле базы данных на энергонезависимом носителе. Обычно это вызвано неисправностью или неправильно настроенным стеком хранилища (программным или аппаратным обеспечением). Клиентские приложения могут получать ошибку JET_errReadLostFlushVerifyFailure от функций ESE, требующих чтения данных из базы данных, если данные находятся в регионе, где произошло событие потерянной записи.

2 Возможность обнаружения потерянных операций записи в течение времени существования процесса имеется с Windows 8 (клиент) и Windows Server 2012 (сервер).