Ведение журнала транзакций Exchange

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

Exchange использует сложную систему управления внутренней памятью, настроенную на высокую производительность и позволяющую эффективно управлять кэшированием десятков гигабайт (ГБ) страниц баз данных. Таким образом, физическая запись изменений в файл базы данных является низкоприоритетной задачей при нормальной работе.

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

Вместо записи всех сведений в один большой файл журнала Exchange использует последовательность файлов журнала, каждый из которых имеет размер 1 мегабайт (1024 КБ). Когда файл журнала заполняется, Exchange закрывает и переименовывает его в соответствии с порядковым номером. Первому заполненному файлу журнала назначается имя Enn00000001.log. nn — это двухзначное число, которое называется базовым именем (префиксом журнала).

Файлы журнала для каждой группы хранения различаются по именам файлов с нумерованными префиксами (например E00, E01, E02 или E03). Файл журнала, открытый в текущий момент для группы хранения, называется просто Enn.log — ему не назначается порядковый номер до его заполнения и закрытия.

Файл контрольных точек (Enn.chk) отслеживает прогресс Exchange при записи сведений из журналов в файлы базы данных. Для каждого потока журнала существует свой файл контрольных точек, а для каждой группы хранения — отдельный поток журнала. Все базы данных в одной группе хранения используют один поток журнала. Таким образом, один файл журнала часто содержит сведения об операциях для нескольких баз данных.

Файлы журнала нумеруются в шестнадцатеричной системе счисления, поэтому за файлом журнала E0000000009.log следует файл E000000000A.log, а не E0000000010.log. Порядковые номера файлов журнала можно преобразовать в десятичные значения с помощью калькулятора Windows (Calc.exe) в режиме Инженерный. Для этого запустите файл Calc.exe, а затем в меню Вид выберите пункт Инженерный.

Чтобы просмотреть десятичный порядковый номер для конкретного файла журнала, изучите его заголовок с помощью средства для работы с базами данных Exchange Server Eseutil.exe. Первая 4-килобайтная страница каждого файла журнала содержит сведения о заголовке, описывающие и идентифицирующие файл журнала и базы данных, к которым он относится. Команда Eseutil /ml [имя_файла_журнала] выводит сведения о заголовке. Дополнительные сведения о средстве Eseutil см. в разделе Eseutil.

При использовании для отображения заголовка неправильного параметра (например при использовании с заголовком базы данных параметра /ml вместо параметра /mh) появится сообщение об ошибке либо будут выведены искаженные или неверные сведения о заголовке.

Заголовок базы данных невозможно просмотреть, если база данных подключена. Также нельзя просмотреть заголовок текущего файла журнала (Enn.log), если подключена какая-либо база данных из группы хранения. Exchange не закрывает текущий файл журнала, пока его использует хотя бы одна база данных. Тем не менее можно просматривать заголовок файла контрольных точек, если базы данных подключены. Exchange обновляет файл контрольных точек каждые тридцать секунд, и его заголовок не доступен для просмотра только в момент обновления.

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

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

	Копировать код
Base name: e00 Log file: e00.log lGeneration: 11 (0xB) Checkpoint: (0xB,7DC,6F)

Эти строки заголовка файла журнала показывают, что файл журнала является текущим, поскольку его имя не имеет порядкового номера. Строка lGeneration показывает, что после заполнения и закрытия файла журнала ему будет присвоен порядковый номер B, соответствующий десятичному значению 11. Базовое имя — e00, поэтому окончательное имя файла журнала — E000000000B.log.

Значение Checkpoint в предыдущем примере заголовка фактически не считывается из заголовка файла журнала, но выводится таким образом, как будто оно считано оттуда. Средство Eseutil.exe считывает значение Checkpoint напрямую из файла Enn.chk, поэтому не требуется выполнять отдельную команду, чтобы узнать местоположение файла контрольных точек. Если файл контрольных точек был уничтожен, значение Checkpoint считывается как NOT AVAILABLE. В этом случае контрольной точкой является текущий файл журнала (0xB), а числа 7DC и 6F показывают, насколько далеко в файле журнала находится контрольная точка. Обратите внимание на то, что эти сведения редко требуются на практике.

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

Как правило, просмотр сервером Exchange файла журнала, который уже был применен к базе данных, занимает одну — две секунды. Если в файле журнала имеются операции, которые необходимо записать в базу данных, выполнение этих операций может занять от 10 секунд до нескольких минут. В среднем содержимое файла журнала записывается в базу данных за 30 секунд или быстрее.

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

Чтобы выяснить, было ли выполнено «чистое» отключение базы данных, выполните команду Eseutil /mh и изучите заголовки файлов.

Если все базы данных в группе хранения отключены и находятся в состоянии «чистого» отключения, все файлы журнала можно безопасно удалить без последствий для баз данных. После удаления всех файлов журнала Exchange создаст новую последовательность файлов журнала, начинающуюся с Enn00000001.log. Файлы баз данных можно также переместить на другой сервер или в другую группу хранения с существующими файлами журнала, при этом базы данных подключатся к другому потоку журнала.

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

Если база данных находится в состоянии «грязного» отключения, для ее повторного подключения необходимы всех существующие журналы транзакций, начиная с контрольной точки. Если эти журналы недоступны, базу данных следует восстановить, выполнив команду Eseutil /p, чтобы согласовать базу данных и подготовить ее к запуску.

Внимание!

При восстановлении базы данных некоторые данные будут утрачены. Потери данных часто минимальны, но в некоторых случаях они могут быть разрушительными. После выполнения команды Eseutil /p для базы данных следует полностью восстановить базу данных, выполнив указанные ниже операции. Сначала выполните команду Eseutil/d, чтобы дефрагментировать базу данных. Эта операция удаляет и повторно создает все индексы базы данных и деревья пространства. Затем запустите средство проверки целостности банка данных (Isinteg.exe) в режиме –fix. Это средство проверяет базу данных на наличие логических несогласованностей, возникших в результате удаления ожидающих обработки журналов транзакций. Например, в базе данных могут быть устаревшие ссылки. Средство Isinteg.exe пытается исправить подобные проблемы с минимально возможными потерями данных.

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

Циклическое ведение журнала

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

При стандартном ведении журнала транзакций, используемом Exchange 2007, каждая транзакция базы данных в группе хранения записывается сначала в файл журнала, а затем — в базу данных. Когда размер файла журнала достигает одного мегабайта (МБ), файл переименовывается и создается новый файл журнала. Со временем создается набор файлов журнала. Если Exchange непредвиденно завершает работу, транзакции можно восстановить с помощью преобразования данных из этих файлов журналов в базу данных. При циклическом ведении журнала первый файл журнала перезаписывается и повторно используется после записи содержащихся в нем данных в базу данных.

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

Дополнительные сведения о включении и отключении циклического ведения журнала в Exchange 2007 см. в разделе Включение и отключение циклического ведения журнала для группы хранения.

Непрерывная репликация и циклическое ведение журнала

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

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

В окончательной первоначальной версии сервера Exchange 2007 поддерживается совместное использование циклического ведения журнала с кластером с непрерывной репликацией и локальной непрерывной репликацией. Однако использовать эту возможность не рекомендуется, поскольку она не позволяет выполнить восстановление базы данных с повтором всех завершенных транзакций после восстановления из резервной копии. Сервер Exchange 2007 с пакетом обновления 1 (SP1) также позволяет группам хранения в средах кластера с непрерывной репликацией, локальной непрерывной репликации или резервной непрерывной репликации использовать циклическое ведение журнала. Однако использовать эту возможность также не рекомендуется по указанной выше причине. В этих средах используется циклическое ведение журнала непрерывной репликации, а не циклическое ведение журнала расширенного обработчика хранилищ (также известное как циклическое ведение журнала JET (Joint Engine Technology)). В средах кластера с непрерывной репликацией, локальной непрерывной репликации или резервной непрерывной репликации для включения и отключения циклического ведения журнала всегда следует использовать указанную ниже последовательность действий.

1. Приостановите непрерывную репликацию с помощью командлета Suspend-StorageGroupCopy.
   
   
2. Включите или отключите циклическое ведение журнала. Подробное описание действий по включению и отключению циклического ведения журнала см. в разделе Включение и отключение циклического ведения журнала для группы хранения.
   
   
3. Отключите и снова подключите базу данных в группе хранения, для которой производится включение или отключение циклического ведения журнала.
   
   
4. Возобновите непрерывную репликацию с помощью командлета Resume-StorageGroupCopy.
   
   

Для групп хранения в среде с локальной непрерывной репликацией перед выполнением командлета Enable-StorageGroupCopy для включения локальной непрерывной репликации для группы хранения необходимо убедиться в том, что текущие параметры циклического ведения журнала обнаружены и используются службой банка данных Microsoft Exchange. Это можно сделать путем отключения и повторного подключения базы данных в группе хранения. В то время как служба банка данных Microsoft Exchange требует отключения и повторного подключения базы данных для обнаружения и использования изменений конфигурации, служба репликации Microsoft Exchange способна обнаруживать и использовать изменения конфигурации динамически, без перезапуска. Таким образом, если не выполнить приведенную выше процедуру, это может привести к ситуации, в которой служба репликации Microsoft Exchange будет считать, что циклическое ведение журнала отключено (или включено), в то время как служба банка данных Microsoft Exchange будет считать, что циклическое ведение журнала соответственно включено (или отключено). Это может привести к преждевременному усечению файлов журнала.

Примечание.

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

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

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

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

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