Файлы журнала транзакций в базе данных edb

Question

В моей попытке извлечь данные (дампы и выборочное чтение столбцов) из разнообразной базы данных edb я столкнулся с фундаментальной проблемой. У меня есть база данных edb с несколькими файлами журналов. Я знаю, какая информация есть в базе данных, но я извлекаю только половину. Я боюсь, что оставшаяся половина спит где-то в файлах журнала. Я предположил, что механизм EDB знает, где находятся файлы журналов, и автоматически загружает их при подключении базы данных (JET_paramSystemPath, JET_paramLogFilePath и JET_paramBaseName установлены правильно). Это неправильное предположение? Если так, что я должен сделать, чтобы загрузить журналы также?

Как вариант, можно ли просто зафиксировать транзакции в файле EDB и избавиться от журналов?

Answer 1

Если есть незафиксированные транзакции, база данных будет помечена как "несогласованная". Вы можете проверить это, используя ESENTUTL /MH для базы данных. Вызов JetAttachDatabase для несовместимой базы данных всегда будет неудачным.

Таким образом, если ваша программа может присоединить и открыть базу данных, она будет согласованной. Есть два способа сделать базу данных согласованной:

1. Чистое отключение ESENT.
2. Запуск восстановления с использованием лог-файлов во время JetInit.

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

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

Еще один поворот заключается в том, что файлы журналов содержат полный путь к базе данных. Это означает, что если вы скопировали / переместили базу данных, восстановление не будет работать. Начиная с Windows Server 2003, вы можете справиться с этим, установив JET_paramAlternateDatabaseRecoveryPath в каталог, содержащий базу данных.

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