Расширяемые файлы ядра хранилища
применимо к: Windows | Windows Server
Расширяемые файлы ядра хранилища
Подсистема расширяемого хранилища использует следующие типы файлов:
Эта таблица содержит обзор имен файлов данных, управляемых ESE. Для Windows Vista и более поздних версий параметр JET_paramLegacyNames влияет на имена файлов, которые используются.
| Ярлык | Ценность |
|---|---|
Файлы журнала транзакций
Файлы журнала транзакций содержат операции с файлами базы данных. Они содержат достаточно информации, чтобы привести базу данных в логически согласованное состояние после неожиданного завершения процесса или завершения работы системы.
Имена файлов журнала зависят от трехбуквного базового имени, которое можно задать с помощью JET_paramBaseName. В приведенных ниже примерах используется базовое имя "edb", так как это базовое имя по умолчанию. Расширение для файлов журнала транзакций будет .log или JTX в зависимости от того, задан ли JET_bitESE98FileNames в параметре JET_paramLegacyFileNames. Дополнительные сведения см. в системных параметров подсистемы хранилища.
Файлы журнала транзакций называются <базовых><>.log поколения, начиная с 1. Номер создания журнала находится в шестнадцатеричном формате. Например, edb00001.log является первым журналом, а edb000ff.log — это 255-й журнал. Файлы журнала имеют пять шестнадцатеричных цифр в имени файла журнала до 1048576-го файла журнала, в котором файлы журнала начинают называться в формате 11.3 (например, edb00100000.log). <базовой>.log всегда используется файл журнала. Если ядро СУБД неактивно, можно определить создание edb.log с помощью следующей команды: esentutl.exe -ml edb.log.
Хотя файлы журнала транзакций имеют значение . Расширение LOG, обычно связанное с текстовыми файлами, файлы журнала транзакций находятся в двоичном формате и никогда не должны изменяться пользователем. Операции базы данных записываются в журнал в первую очередь. Данные можно записать в файл базы данных позже; возможно, сразу же, потенциально гораздо позже. В случае неожиданного завершения процесса или завершения системы операции по-прежнему присутствуют в файлах журнала, а неполные транзакции можно откатить. Действие повторения файлов журнала транзакций называется обратимого восстановления, и выполняется автоматически при вызове JetInit или JetInit2. Обратимое восстановление также можно выполнить вручную с параметром "-r" программы Esentutl.exe. Действие повторения файлов журнала транзакций в базе данных, восстановленной из резервной копии, называется жесткого восстановления.
Файлы журналов имеют фиксированный размер, настраиваемый с помощью JET_paramLogFileSize. При заполнении текущего файла журнала (то есть edb.log) он переименовывается в <базовый><номер поколения>.log, а новый файл журнала транзакций необходим в потоке журнала транзакций.
Каждый экземпляр базы данных имеет одну последовательность файлов журнала, связанную с ней. Windows XP представила JetCreateInstance, что позволяет использовать несколько последовательностей файлов журнала транзакций для одного процесса. Однако несколько последовательностей файлов журнала транзакций не могут существовать в одном каталоге.
Файлы журнала транзакций почти никогда не должны управляться вручную, переименовать, переместить или удалить, так как повреждение данных может привести к повреждению данных.
Файлы журнала транзакций будут удалены ядром СУБД во время полной резервной копии (см. JetBackup, JetTruncateLog, JetTruncateLogInstance), или во время обычных операций, если циклическое ведение журнала включено.
После заполнения файла журнала транзакций ядро СУБД должно создать новый файл журнала. Циклическое ведение журнала — это средство автоматического очистки файлов журналов ядром СУБД, когда они больше не требуются для аварийного восстановления. Этот процесс является альтернативой удалению файлов журналов как по продукту выполнения резервной копии. Циклическое ведение журнала можно контролировать с помощью JET_paramCircularLog системного параметра. Файлы журнала транзакций не следует удалять с помощью любого другого метода.
Временные файлы журнала транзакций
При заполнении edb.log ESE необходимо создать новый файл. Новый файл транзакции журнала называется временным файлом журнала транзакций до его использования ESE.
Хотя создается новый файл журнала и его размер расширен, он будет вызываться <базовых>tmp.log. Создание нового файла может быть потенциально дорогостоящей операцией, поэтому ESE создаст следующий файл журнала заранее в качестве фоновой задачи.
Так как временный файл журнала транзакций создается в ожидании необходимости нового файла журнала транзакций, он не содержит полезных сведений.
Зарезервированные файлы журнала транзакций
Зарезервированные файлы журнала транзакций создаются при запуске подсистемы, чтобы разрешить ведение журнала важных операций для получения чистого завершения работы.
Windows Vista: в Windows Vista и более поздних версиях зарезервированные файлы журнала транзакций называются <базовыми>RESXXXXX.jrs.
Windows Server 2003: в Windows Server 2003 и более ранних версиях зарезервированные файлы журнала транзакций называются res1.log и res2.log.
Если ядро СУБД не занимает места на диске, он не может создать новый файл журнала. Самое безопасное, что нужно сделать, заключается в том, чтобы полностью завершить работу, но некоторые операции (такие как операции отката) по-прежнему должны быть зарегистрированы. Большинство операций базы данных завершаются сбоем на этом этапе.
Так как зарезервированные файлы журнала транзакций создаются в ожидании необходимости файлов журнала транзакций в сценарии вне диска, они не содержат полезных сведений.
Файлы контрольных точек
Файл контрольной точки хранит контрольную точку для определенной последовательности файлов журнала транзакций. Файл контрольной точки называется <базовым>.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).
Файлы карты Flush
Начиная с юбилейного обновления 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 и заставляет удалить и повторно создать несогласованную карту очистки с нуля.
Размер файла карты очистки напрямую пропорциональен связанному файлу базы данных и приблизительно равен (все размеры в байтах, результат должен быть округлен до следующего 8 192):
8,192 + ((<database file size> / <database page size>) / 4)
Например, для базы данных размером 1,5 ГБ с размером страницы размером 32 КБ приблизительный размер карты очистки составляет 24 576 байт (или 24 КБ).
Файл карты очистки необходимо обновить по мере очистки страниц базы данных. Если ведение журнала транзакций включено (например, JET_paramRecovery задано значение on, значение по умолчанию), обновление карты очистки выполняется, так как клиентское приложение вносит изменения в базу данных. В среднем вся карта очистки записывается на ненезависимый носитель один раз за каждые 20% JET_paramCheckpointDepthMax -worth (в байтах) созданных журналов транзакций. Количество операций записи зависит от распределения по всей базе данных изменений. Но это в большинстве случаев (все размеры в байтах):
<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 (сервер).