Хранилище Exchange. Часть 1. Extensible Storage Engine (ESE) – файловая структура.

Основным компонентом Exchange является база данных, где хранятся все данные. Какое бы действие вы не производили (создание письма, редактирование, создание встречи и т.д.) – в итоге все изменения будут попадать в эту базу данных. Эта база данных получила название Extensible Storage Engine или в кратце – ESE. Эта серия статей будет посвящена этому движку, начиная от ее файловой структуры и заканчивая ее внутренними механизмами.

Список всех статей серии:

Если посмотреть поближе на технологии Microsoft, то можно обнаружить, что многие из них используют базу ESE для хранения данных. Это и ActiveDirectory (включая AD LDS), и DHCP, и WINS, и конечно же Exchange. Причем в Exchange движок ESE используется не только для хранения данных, но и используется в транспортной службе для хранения почтовых очередей и даже в службе поиска.


Файловая структура почтовой базы

Первая статья из серии посвящена описанию файлов, из которых состоит обычная почтовая база.

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

Если перейти в папку с почтовой базой, то можно увидеть следующую картину:

Узнать путь, где лежит почтовая база можно следующей командой:

Get-MailboxDatabase -Server Ex2013 | fl name, EdbFilePath

Untitled


image

Итак, почтовая база состоит из 7 типов файлов.

<database name>.edb

image

Сама почтовая база. В этом файле Exchange хранит все данные.

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

Имя файла соответсвует имени почтовой базы. Правда ничто нам не мешает сделать имя этого файла отличным от имени почтовой базы.

tmp.edb

image

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

Имя файла всегда стандартное – temp.edb

E00.log

image

Лог файл с транзакциями. Любое действие с почтовыми элементами (создание письма, перемещение письма, создание встречи и т.п.) – это транзакция, т.е. какое-либо действие с данными из почтовой базы. После обработки этой транзакции она помещается в лог файл.

Более подробно о механизме работы с транзакциями будет описано в третьей части Exchange Store. Part 3. Extensible Storage Engine (ESE) – transaction logging.

Имя файла представляет собой префикс почтовой базы, который можно узнать через свойства почтовой базы:

Get-MailboxDatabase | ft name, *prefix*

image

E00<число>.log

image

При достижении файлом E00.log размера в 1МБ, он переименовывается в файл E00<число>.log, где <число> – это порядковый номер файла в шестнадцатеричной системе счисления. При этом создается новый файл E00.log, в который продолжают записываться следующие транзакции.

Размер этих файлов составляет так же 1МБ и их количество может быть неограничено.

На самом деле количество их ограничено, но количество это совсем уж большое – 2 147 486 647. И если вам повезло и нумерация логов достигло этого числа (в нашем примере это E007FFFFFFF.log), то придется просто сбросить счетчик нумерации логов (The transaction log sequence for a database is about to run out of available file names)

E00tmp.log

image

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

Размер этого файла так же 1МБ.

E00res<число>.jrs

image

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

Размер файлов – все так же 1МБ. Имя файла представляет из себя префикс почтовой базы (E00) и суффикса в виде  порядкового номера в шестнадцатеричной системе счисления. Всего таких резервных файлов – 10.

E00.chk

image

Это файл с контрольной точкой.

Так же в четвертой части посмотрим на некоторые интересные свойства этого файла с помощью утилиты eseutil.exe

В этом файле хранится отметка о самой последней транзакции, записанной в почтовую базу, т.е. в файл <database name>.edb.

Более подробно про использование этого файла мы рассмотрим в третьей части Exchange Store. Part 3. Extensible Storage Engine (ESE) – transaction logging.

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

В некоторых случаях удалять лог файлы можно. Но главное четко знать: какие именно файлы можно удалить.

Отдельное спасибо Станиславу Булдакову за ценные комментарии.


Читайте также:

комментариев 7

  1. Anonymous:

    > В общем соучае, уменьшить количество транзакционных логов можно с помощью циклического логирования, что и является рекомендуемым решением.
    Рекомендуемым решение является создание резервной копии при которой логи удаляются, а в общем случае его включать НЕ рекомендуется:
    https://technet.microsoft.com/en-us/library/bb331958%28v=exchg.141%29.aspx#UTL

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

      • Роман:

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

      • Artem:

        Да, это на самом деле рекомендуемое решение. Но с некоторым дополнением — необходимо иметь копию с настроенным отложенным воспроизведением журнала (Lagged Database Copy). Это называется «Exchange Native Protection». Бэкапы в таком случае не нужны.

  2. Bo:

    Спасибо за статью! Но с динамически изменяемым размером верхнего блока, читать материал становится затруднительно.

  3. Sergey:

    Если хочется попробовать, можно корректно выполнить dismount database и далее удалить все файлы логов, только файл базы оставить :) — при выполнении mount database — лог-файлы будут воссозданы.

Добавить комментарий