ESEUTIL — известная утилита командной строки. Когда-то она считалась превосходной, но затем потеряла привлекательность вследствие многочисленных изменений в технологии обработки сообщений. Благодаря этим изменениям были устранены пробелы, которые ранее устраняла утилита ESEUTIL. Так почему же многие специалисты по-прежнему рекомендуют время от времени использовать ее для очистки баз данных? Это одна из загадок Exchange.
У ESEUTIL долгая история взаимодействия с Exchange. Эта утилита командной строки сохранила интерфейс со времен Exchange 4.0. Когда-то ESEUTIL была незаменимой для каждого администратора. Но то было в далекие времена единственных баз данных, ненадежных дисков и вездесущих программных ошибок. В таких условиях способности ESEUTIL (при грамотном применении) восстанавливать любой сервер Exchange до работоспособного состояния выглядели почти магическими.
Применение ESEUTIL можно сравнить с лечением пиявками — хорошее решение для узких задач при разумном использовании, но не универсальное средство от всех недугов. Тем не менее на удивление много специалистов по-прежнему считают ESEUTIL подходящим инструментом для частого применения.
Когда-то сервер Exchange располагал всего одной базой данных почтовых ящиков, которая представляла собой колоссальную единую точку отказа. Размер базы данных не превышал 16 Гбайт, но казался огромным для дисков на 128 и 256 Гбайт. Однако он был вполне достаточным в условиях аккуратного выделения 50 Мбайт квот пользователям, получавшим лишь несколько сообщений в день (при этом ни одно из них не поступало из отдела маркетинга и потому не содержало по 10 Мбайт вложений).
Все шло хорошо до тех пор, пока мы не заметили, что ядру базы данных Exchange свойственна некоторая небрежность при управлении неиспользованными страницами в базе данных. Повторное использование страниц, освобожденных в результате удаления ненужных сообщений — не самая сильная сторона Exchange. Программе постоянно требуется все больше и больше места от файловой системы. Результат — чрезмерно разбухающие базы данных.
Проблема усугубляется множеством причин, которые могут привести к физической или логической порче базы данных. Иногда это аппаратные сбои (типичный виновник — контроллер устройств хранения). Программные ошибки тоже могут вызывать проблемы. Журналы событий полны сообщениями об ошибках -1018, -1019, -1022 и многих других.
Но администраторы Exchange знают ответ. Нужно уведомить пользователей, что сервер будет отключен от сети на некоторое время, а затем запастись любимыми напитками и поразить наблюдателей ловкостью, с которой вы используете различные параметры командной строки для программ ISINTEG (http://support.microsoft.com/kb/301460) (не рекомендуется для использования в Exchange 2010) и ESEUTIL. Обе программы выполняются долго и позволяют заняться в это время другой работой.
ISINTEG предназначалась только для случаев логической порчи, например неверных показаний счетчиков. Это далеко не те проблемы, которые можно решить с помощью ESEUTIL (например, зияющие пробелы, возникающие в базе данных после появления на страницах неверных контрольных сумм). С помощью ESEUTIL можно навести порядок в базе данных и восстановить ее компактность, вернув пространство в файловую систему. Одним словом, ESEUTIL — утилита для серьезных администраторов.
Итак, мы тратили многие часы, запуская ESEUTIL/D (http://support.microsoft.com/kb/328804) для дефрагментации базы данных в автономном режиме (см. экран) или ESEUTIL/P (http://technet.microsoft.com/en-us/library/aa997215(v=exchg.65).aspx) для восстановления базы данных после физического повреждения (также известного как «жесткое восстановление»). Скорость выполнения обеих операций — 2-3 Гбайт/ч; для обеих требуется монопольный доступ к базе данных; для построения новой версии базы данных обеим операциям необходимо свободное пространство на диске, составляющее 110% размера базы данных; необходимо выполнить полное резервное копирование до и — на всякий случай — после операции. После запуска ESEUTIL все журналы транзакций становятся недействительными, так как в результате дефрагментации или перестроения базы данных будет создана новая база данных, никак не связанная с журналами.
.jpg) |
| Экран. Запуск ESEUTIL с ключом /D для дефрагментации базы данных в автономном режиме |
По простоте своей в прошлом мы с удовольствием работали с ESEUTIL. Но, помимо использования ESEUTIL/M (http://technet.microsoft.com/en-us/library/aa997818(v=exchg.65).aspx) для дампа заголовков базы данных время от времени, ценность ESEUTIL постоянно снижалась после того, как Microsoft выпустила Exchange 2000 в 1999 году. Благодаря более отлаженному коду стало меньше программных ошибок и усовершенствован метод повторного использования удаленных страниц в хранилище сообщений Store, чему способствует автоматическая оперативная дефрагментация. В современных базах данных меньше пустых мест, а из-за быстрого снижения стоимости хранения данных и увеличения объемов памяти в 99% случаев совершенно излишне выполнять дефрагментацию в автономном режиме. Так или иначе, современные пользователи, привыкшие к постоянному подключению, не потерпят, чтобы администраторы переводили базы данных в автономный режим для перестроения.
Группы обеспечения доступности баз данных (DAG), появившиеся в Exchange 2010, оказались как нож в сердце ESEUTIL. Благодаря многочисленным копиям базы данных и автоматическим исправлениям через частичное обновление единой страницы в основном устраняются ошибки -1018 и им подобные. Поэтому пользуйтесь ESEUTIL для перестроения базы данных, только если это рекомендуют сделать специалисты службы поддержки Microsoft, но не источники из Интернета.
Недавно Microsoft изменила свою политику поддержки (http://blogs.technet.com/b/exchange/archive/2015/05/01/new-support-policy-for-repaired-exchange-databases.aspx), чтобы стимулировать пользователей переместить все почтовые ящики из проблемной базы данных, не торопясь запускать ESEUTIL. Полезно освободить новую базу данных от всех ошибок, которые могли бы стать причиной запуска ESEUTIL. Кроме того, новые версии Exchange настолько успешно функционируют во время перемещения почтовых ящиков, что эта операция должна стать привычной для всех.
Вряд ли разумно следовать примеру людей, которые используют ESEUTIL просто потому, что им нравится эта программа.