Eseutil - часть 1: технологии баз данных

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

Технологии баз данных Exchange

Когда вы устанавливаете сервер Exchange Server 2010 Mailbox, база почтовых ящиков (Mailbox Database) создается автоматически. В следующем примере новая база почтовых ящиков создана в каталоге ‘C:\Program Files\Microsoft\Exchange Server\V14\Mailbox\Mailbox Database 0242942819’

Как видно на рисунке 1, здесь показан ряд файлов:

• Mailbox Database 0242942819.edb ‘ это файл самой базы данных почтовых ящиков, которая содержит все сообщения. Случайное число ‘0242942819’ генерируется во время создания базы почтовых ящиков и используется для создания уникального имени в организации Exchange
• E00.log - это лог файл, используемый в настоящее время механизмом базы данных
• E00000003A.log, E00000003B.log, E00000003C.log’ ‘ это лог файлы, хранящиеся на диске, которые можно использовать для восстановления. Обратите внимание, что используется шестнадцатеричная система счисления
• E00.chk ‘ это файл контрольной точки, используемой для отслеживания отношений между лог файлами и файлом базы данных почтовых ящиков
• E00res00001.log and E00res00002.log ‘ это предварительно созданные лог файлы, используемые, когда диск, содержащий лог файлы, заполнен
• E00tmp.log ‘ новый лог файл, который создается в текущий момент

Все имена лог файлов в этом примере начинаются с трех символов, E00, называемых префиксом. Этот префикс будет использоваться для лог файлов данной конкретной базы данных. Вторая база данных будет использовать префикс E01, третья – E02, и т.д.’

Механизм баз данных обрабатывает данные в так называемых ‘страницах’, каждая из которых имеет размер в 32КБ. Эти 32КБ составляют размер страницы в Exchange Server 2010; Exchange Server 2007 использует страницы размером 8КБ, а Exchange Server 2003 и более ранние версии использовали страницы размером 4КБ. Транзакция, которая может представлять собой новое сообщение, создание новой папки в папке входящих сообщений, создание или удаление сообщений, состоит из нескольких страниц. Как только транзакция создается в памяти, она тут же записывается из памяти в используемый лог файл, которым в данном примере является E00.log. Когда этот E00.log файл заполнен записями транзакций, он сохраняется на диск, используя другое имя, а имена будут последовательно пронумерованы с каждым новым журналом. На рисунке выше это будет журнал E00000003E.log. Цифра ‘3E’ называется ‘lGeneration’ номером внутри механизма базы данных. Механизм базы данных постоянно увеличивает этот номер. Помимо NTFS имен полный набор лог файлов идентифицируется ‘сигнатурой лог файлов (log file signature)’; они автоматически генерируются во время создания лог файла и содержат отметку даты и времени, за которой стоит случайный набор цифр. Сигнатура лог файла может выглядеть примерно так:

‘Create time:07/30/2009 09:38:51 Rand:246084591 Computer:’

Примечание: после последнего двоеточия нет никаких значений в сигнатуре лог файла.

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

‘Create time:05/12/200908:33:12 Rand:812305 Computer:’

И опять же, за последним двоеточием нет никаких значений. В оставшейся части статьи я буду опускать ‘Computer:’ часть сигнатуры ради простоты. Страницы не записываются в файл базы данных немедленно, а лишь по прошествии определенного времени. Они будут оставаться в памяти на случай, если Exchange снова потребуется страница. Таким образом ценные данные ввода/вывода диска сохраняются, поскольку все еще находятся в памяти. Чем больше памяти в сервере Exchange Server, тем больше информации может в ней храниться. Когда страница сохраняется в файл базы данных, файл контрольной точки обновляется. Файл контрольной точки отслеживает то, какие страницы записаны в базу данных. Страницы ‘под’ файлом контрольной точки записаны в файл базы данных, а страницы ‘над’ файлом контрольной точки все еще находятся в памяти и пока что не записаны в файл базы данных.

Итак, где же находятся сами данные? Они находятся в памяти сервера, в лог файлах или в базе данных почтовых ящиков.

Говоря коротко:

1. Почтовые данные сначала обрабатываются в памяти, разделяются на страницы.
2. Обновленные страницы, образующие транзакцию, записываются в лог файл.
3. Если страницы больше требуются Exchange, они записываются в базу данных.
4. Файл контрольной точки обновляется и отображает новое место контрольной точки.

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

Файл базы почтовых ящиков на самом деле является открытым файлом, для которого недостающие данные находятся в лог файлах. Так обстоит дело, когда база данных почтовых ящиков подключена, и Exchange обрабатывает данные. Когда база данных отключена, вся информация в памяти сбрасывается в базу данных, файл контрольной точки обновляется (вся информация теперь находится в базе данных, в своем конечном месте) и база данных закрывается. Теперь база данных находится в ‘согласованном состоянии’. Это состояние иногда также называют ‘чистым отключением (clean shutdown)’.

Теперь предположим, что на сервере произошел крах, или менее критический сбой, мы выдернули шнур питания из сервера. База данных находится в несогласованном состоянии, поскольку не была отключена корректно, поэтому она несогласованна, что также называется ‘некорректным отключением (dirty shutdown)’. Но все данные все еще находятся в лог файлах, поэтому Exchange способен восстановить последнюю часть базы данных на основе информации из лог файлов. Этот процесс, называемый автоматическим восстановлением, возникает, когда сервер запускается, и база данных снова подключается. Exchange знает всю информацию до того, как контрольная точка будет в базе данных, поэтому Exchange начнет с момента контрольной точки для восстановления и воспроизводит только эту информацию. В 99% случаев в такой ситуации база данных будет нормально подключена, но в оставшемся 1% инструмент ESEUTIL может быть весьма полезен. Также случаются неприятности со страницами баз данных на физическом жестком диске или контроллере диска. Страницы могут быть повреждены, что, как правило, выдает ошибку с кодом -1018 в журнале регистрации событий. ESEUTIL может помочь вам и в этом случае. Но здесь также нужно быть осторожным: поскольку ESEUTIL является очень мощным инструментом, он также может уничтожить вашу базу данных, что приведет к потере данных. Поэтому нужно обязательно убедиться, что у вас есть приличная резервная копия баз данных Exchange, или следует поработать с ESEUTIL на другом, изолированном сервере, чтобы предотвратить возникновение ошибок.

ESEUTIL

ESEUTIL представляет собой утилиту для работы с базами данных Exchange, которая расположена в каталоге \bin на сервере Exchange. С этим инструментом используется ряд ключей:

• ESEUTIL /D ‘ используется для автономной дефрагментации базы данных
• ESEUTIL /R ‘ используется для восстановления базы данных
• ESEUTIL /g ‘ выполняет проверку базы данных на целостность
• ESEUTIL /k ‘ выполняет проверку контрольной суммы базы данных
• ESEUTIL /p ‘ исправляет базу данных, когда она повреждена (и не подлежит восстановлению)
• ESEUTIL /m ‘ может выгружать информацию заголовка базы данных и лог файлов
• ESEUTIL /y ‘ может копировать большие файлы типа Mailbox Database
• ESEUTIL /c ‘ используется для ‘жесткого восстановления (hard recover)’ базы данных во время резервного копирования в режиме онлайн

Я начну с информационных опций, опций, которые не являются разрушительными.

Информация заголовка

Каждый файл базы данных, лог файл или файл контрольной точки имеет заголовок. Заголовок содержит (внутреннюю) информацию, используемую сервером Exchange. Информацию заголовка можно читать с помощью ESEUTIL /m. Чтобы прочитать информацию заголовка из файла базы данных, используется следующая команда:

‘ESEUTIL /MH ‘Mailbox Database 0872095299.edb’

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

На рисунке 3 отчетливо видна сигнатура базы данных (Create time: 03/31/2010 18:20:50 Rand:82186442) и сигнатура соответствующих лог файлов (Create time:10/16/2009 12:12:19 Rand 3690040). Чтобы посмотреть заголовок лог файла, нужно использовать следующую команду:

ESEUTIL /ML E00.log

В информации этого заголовка вы увидите, когда был создан лог файл, его lGeneration номер (последовательный номер, с использованием которого будет переименован этот лог файл), сигнатура лог файла и информация соответствующей базы данных. Если этот лог файл и база данных связаны, вы увидите одинаковую информацию сигнатур в обоих файлах.

На рисунке 4 четко показана сигнатура лог файла (Create time:10/16/2009 12:12:19 Rand 3690040). Она совпадает с сигнатурой лог файла, которую мы видели ранее в информации заголовка файла базы данных, поэтому данный лог файл принадлежит к предыдущей базе данных. Чтобы проверить последовательность лог файлов, связанных друг с другом, нужно ввести следующую команду:

ESEUTIL /ML E00

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

ESEUTIL /MK E00.chk

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

В информации заголовка вы найдете сигнатуру лог файла: 10/16/2009 12:12:19 Rand 3690040. Как мы видели в заголовке лог файла E00.log, это та же сигнатура лог файла, поэтому данный файл контрольной точки принадлежит лог файлу E00.log.

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

Последней опцией здесь является проверка места, используемого базой данных почтовых ящиков. Вы можете получить всю информацию относительно внутреннего использования: количество внутренних таблиц (используемых для внутреннего образования базы данных), их названия, тип, и т.д. Однако первая запись интересна тем, что она показывает доступное «пустое место» в базе данных. Это объем свободного места, которое можно взять в файле базы данных (т.е. известная автономная дефрагментация (Offline Defragmentation)). Об использовании свободного места я расскажу в следующей части цикла.

Итак, база данных почтовых ящиков, как видно из рисунка выше, имеет 241МБ доступного свободного места в общем размере 2008 ГБ.

Заключение

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

Можно использовать инструмент ESEUTIL для получения любого типа интересующей информации из этих файлов с помощью опций /MH, /ML, /MK и /MS. В следующей части я расскажу о других ключах, которые можно использовать с утилитой ESEUTIL.