В прошлой статье мы обсудили вопрос мягкого восстановления базы данных при помощи команды Esutil /R. В подавляющем большинстве случаев эта команда отрабатывает успешно и базу удается смонтировать на сервер. Но бывают и такие ситуации, когда база сильно повреждена и мягко восстановить её не получается, в таких случаях необходимо попытаться вытащить из базы как можно больше информации.
Исправление
Для исправления базы данных придется использовать команду ESEUTIL /P. Стоит несколько раз подумать, прежде чем пользоваться функцией Repair, т.к. данная операция в ЛЮБОМ случае приведет к потере данных, и сколько именно данных будет потеряно спрогнозировать не реально, можно только с уверенностью сказать, что информация, находящаяся в лог-файлах будет на 100% потеряна.
Все дело в том, что база данных почтовых ящиков не является реляционной, а состоит из множества деревьев с указателями на страницы с данными. Так вот, ESEUTIL /P будет проверять все эти указатели и при обнаружении несоответствий, просто удалит указатель, в независимости от того, на какие данные он ссылается.
Процесс исправления запускается не по отношению к лог-файлам, как было с восстановлением, а по отношению к файлу самой базы данных.
eseutil /P MDB2.edb
После запуска на экран выводится предупреждение, которое позволяет одуматься и отказаться от этого метода восстановления базы.
Рис.1: Предупреждение перед операцией Repair.
Если все же вы твердо решили продолжать, то нужно нажать ОК и утилита ESEUTIL сделает все сама.
Рис.2: Исправление базы при помощи команды ESEUTIL /P.
После операции Repair может быть заметно снижена производительность базы данных, в связи с этим рекомендуется делать автономную дефрагментацию базы при помощи команды ESEUTIL /D, в результате выполнения команды будет создана абсолютно новая база данных, но тут нужно помнить, что для дефрагментации базы у вас должно быть свободного места больше на 110%, чем занимает исходная база.
Проверка логической целостности
После дефрагментации нужно будет проверить логическую целостность базы данных. Ранее, для этого используется утилита ISINTEG. На серверах Exchange 2007 и старше можно было выполнить команду:
isinteg -s имя_сервера -fix -test alltests
тем самым инициировав процесс проверки базы данных.
Рис.3: Проверка логической целостности базы при помощи ISINTEG.
Описание программы ISINTEG.
Неудобство использования ISINTEG заключается в том, что во время её работы база данных почтовых ящиков должна находиться в отключенном состоянии, а это означает достаточно длительный простой в случае большого размера базы.
Exchange 2010
Плюсом к этому, с приходом Exchange 2010 ISINTEG перестала понимать все функции новой базы данных. Но это и нормально, ведь данное средство не изменялось с 2000-го года!
К счастью, сервер Exchange 2010 и не нуждается в отдельном средстве проверки базы, т.к. по умолчанию, для каждой базы на сервере ежедневно по расписанию производится фоновое обслуживание, которое автоматически находит ошибки и при этом не требует отключения базы.
Рис.4: Фоновое обслуживание базы данных.
Exchange 2010 SP1
С входом Exchange 2010 SP1, появилась замена средства ISINTEG в виде новых командлетов:
· New-MailboxRepairRequest – тестирование и исправление почтовых ящиков;
· New-PublicFolderDatabaseRepairRequest – тестирование и исправление общих папок.
Эти командлеты позволяют выполнять тестирование и исправление как целых баз данных, так и отдельных почтовых ящиков. При этом может быть запущено асинхронное сканирование сразу нескольких ящиков, которые во время проверки будут недоступны пользователю, зато все остальные ящики в базе будут прекрасно работать. Правда, если вы запускаете проверку для всей базы сразу, то все почтовые ящики в базе будут отключены.
Синтаксис использования командлетов следующий:
new-MailboxRepairRequest [-Mailbox <MailboxID> | -Database <DatabaseID>] -CorruptionType <CorruptionType> [-DetectOnly] [-DomainController <FQDN>]
Здесь
· Mailbox или Database – это соответственно почтовый ящик или база данных;
· CorruptionType – вид проверки, которую вы желаете запустить:
o SearchFolder;
o AggregateCounts;
o ProvisionedFolder;
o FolderView.
· DetectOnly – используется, если вы хотите лишь обнаружить ошибки, но не исправлять их;
· DomainController – определяет контроллер домена для обновления данных.
Для того, чтобы запустить сразу все виды проверки, то необходимо их перечислить через запятую:
New-MailboxRepairRequest -Mailbox <MailboxID> -CorruptionType SearchFolder,AggregateCounts,ProvisionedFolder,FolderView
Если нужен только один вид проверки для базы данных, то команда будет выглядеть следующим образом:
New-MailboxRepairRequest –Database MDB2 –CorruptionType AggregateCounts
Рис.5: Проверка всей базы.
В результате команда будет выполняться в фоновом режиме, а вам будет доступен её RequestID. Также в журнале событий Windows вы найдете событие под номером EventID = 10059, которое будет означать запуск сканирования
Рис.6: Запуск сканирования базы данных в журнале событий Windows.
И событие с EventID = 10048, которое будет означать успешное завершение операции.
Рис.7: Завершение операции сканирования базы данных в журнале событий Windows.
Заключение
В заключение хочется ещё раз напомнить, что задумываться о резервном копировании данных нужно задолго до того, как вам понадобится их восстанавливать, так что этот процесс должен быть заранее продуман и отработан.
В прошлой статье мы обсудили вопрос мягкого восстановления базы данных при помощи команды Esutil /R. В подавляющем большинстве случаев эта команда отрабатывает успешно и базу удается смонтировать на сервер. Но бывают и такие ситуации, когда база сильно повреждена и мягко восстановить её не получается, в таких случаях необходимо попытаться вытащить из базы как можно больше информации.
Исправление
Для исправления базы данных придется использовать команду ESEUTIL /P. Стоит несколько раз подумать, прежде чем пользоваться функцией Repair, т.к. данная операция в ЛЮБОМ случае приведет к потере данных, и сколько именно данных будет потеряно спрогнозировать не реально, можно только с уверенностью сказать, что информация, находящаяся в лог-файлах будет на 100% потеряна.
Все дело в том, что база данных почтовых ящиков не является реляционной, а состоит из множества деревьев с указателями на страницы с данными. Так вот, ESEUTIL /P будет проверять все эти указатели и при обнаружении несоответствий, просто удалит указатель, в независимости от того, на какие данные он ссылается.
Процесс исправления запускается не по отношению к лог-файлам, как было с восстановлением, а по отношению к файлу самой базы данных.
eseutil /P MDB2.edb
После запуска на экран выводится предупреждение, которое позволяет одуматься и отказаться от этого метода восстановления базы.
Рис.1: Предупреждение перед операцией Repair.
Если все же вы твердо решили продолжать, то нужно нажать ОК и утилита ESEUTIL сделает все сама.
Рис.2: Исправление базы при помощи команды ESEUTIL /P.
После операции Repair может быть заметно снижена производительность базы данных, в связи с этим рекомендуется делать автономную дефрагментацию базы при помощи команды ESEUTIL /D, в результате выполнения команды будет создана абсолютно новая база данных, но тут нужно помнить, что для дефрагментации базы у вас должно быть свободного места больше на 110%, чем занимает исходная база.
Проверка логической целостности
После дефрагментации нужно будет проверить логическую целостность базы данных. Ранее, для этого используется утилита ISINTEG. На серверах Exchange 2007 и старше можно было выполнить команду:
isinteg -s имя_сервера -fix -test alltests
тем самым инициировав процесс проверки базы данных.
Рис.3: Проверка логической целостности базы при помощи ISINTEG.
Описание программы ISINTEG.
Неудобство использования ISINTEG заключается в том, что во время её работы база данных почтовых ящиков должна находиться в отключенном состоянии, а это означает достаточно длительный простой в случае большого размера базы.
Exchange 2010
Плюсом к этому, с приходом Exchange 2010 ISINTEG перестала понимать все функции новой базы данных. Но это и нормально, ведь данное средство не изменялось с 2000-го года!
К счастью, сервер Exchange 2010 и не нуждается в отдельном средстве проверки базы, т.к. по умолчанию, для каждой базы на сервере ежедневно по расписанию производится фоновое обслуживание, которое автоматически находит ошибки и при этом не требует отключения базы.
Рис.4: Фоновое обслуживание базы данных.
Exchange 2010 SP1
С входом Exchange 2010 SP1, появилась замена средства ISINTEG в виде новых командлетов:
· New-MailboxRepairRequest – тестирование и исправление почтовых ящиков;
· New-PublicFolderDatabaseRepairRequest – тестирование и исправление общих папок.
Эти командлеты позволяют выполнять тестирование и исправление как целых баз данных, так и отдельных почтовых ящиков. При этом может быть запущено асинхронное сканирование сразу нескольких ящиков, которые во время проверки будут недоступны пользователю, зато все остальные ящики в базе будут прекрасно работать. Правда, если вы запускаете проверку для всей базы сразу, то все почтовые ящики в базе будут отключены.
Синтаксис использования командлетов следующий:
new-MailboxRepairRequest [-Mailbox <MailboxID> | -Database <DatabaseID>] -CorruptionType <CorruptionType> [-DetectOnly] [-DomainController <FQDN>]
Здесь
· Mailbox или Database – это соответственно почтовый ящик или база данных;
· CorruptionType – вид проверки, которую вы желаете запустить:
o SearchFolder;
o AggregateCounts;
o ProvisionedFolder;
o FolderView.
· DetectOnly – используется, если вы хотите лишь обнаружить ошибки, но не исправлять их;
· DomainController – определяет контроллер домена для обновления данных.
Для того, чтобы запустить сразу все виды проверки, то необходимо их перечислить через запятую:
New-MailboxRepairRequest -Mailbox <MailboxID> -CorruptionType SearchFolder,AggregateCounts,ProvisionedFolder,FolderView
Если нужен только один вид проверки для базы данных, то команда будет выглядеть следующим образом:
New-MailboxRepairRequest –Database MDB2 –CorruptionType AggregateCounts
Рис.5: Проверка всей базы.
В результате команда будет выполняться в фоновом режиме, а вам будет доступен её RequestID. Также в журнале событий Windows вы найдете событие под номером EventID = 10059, которое будет означать запуск сканирования
Рис.6: Запуск сканирования базы данных в журнале событий Windows.
И событие с EventID = 10048, которое будет означать успешное завершение операции.
Рис.7: Завершение операции сканирования базы данных в журнале событий Windows.
Заключение
В заключение хочется ещё раз напомнить, что задумываться о резервном копировании данных нужно задолго до того, как вам понадобится их восстанавливать, так что этот процесс должен быть заранее продуман и отработан.
Перейти к содержанию
На чтение 2 мин Просмотров 2.8к. Опубликовано 17.12.2015
Случилось на днях неприятное происшествие: в результате непредвиденного сбоя отключился диск с базой exchange 2010. В результате после восстановления диска база отказалась подключаться на сервере Exchange. Поэтому тема заметки «Восстановление баз exchange» в полевых условиях.
При попытке ручного подключения базы данных я получал ошибку:
Couldn't mount the database that you specified. Specified database: Mailbox Database; Error code: An Active Manager operation failed. Error: The database action failed. Error: Operation failed with message: MapiExceptionCallFailed: Unable to mount database. (hr=0x80004005, ec=-515)
- Сделал резервную копию поврежденной базы данных. Процесс этот не быстрый, размер базы был более 400 гб. Но это следовало сделать, чтобы иметь возможность повторить процедуру восстановления базы если что-то пойдет не так.
- Проверил диск с базой данных на ошибки утилитой chkdsk.
- Проверяем базу с помощью утилиты eseutil. Она находится в подпапке bin папки куда установлен Exchange. Для проверки используем команду:
eseutil /mh "d:путькбдбазаданных.edb"
- В выводе команды ищем строку содержащую State: Dirty Shutdown. Это значит, что база данных не была корректно отмонтирована.
- Производим починку базы данных командой:
eseutil /p "d:путькбдбазаданных.edb"
Процесс не быстрый, на моей базе в 400 Гб он занял около двух часов.
- После завершения повторяем команду из п.3. Вы должны увидеть State: Clean Shutdown. На всякий случай делаем копию восстановленной базы (на ваше усмотрение).
- Пробуем подключить базу в консоли Exchange, если все подключилось то на этом процедура закончена.
- Если база не подключается то необходимо проверить логи командой:
eseutil /ml "d:путьклогамE00"
Где E00-начальная последовательность именования лог-файлов. На моем сервере она была к примеру E01. Во время проверки необходимо убедится, что все лог файлы прошли без ошибок. Тем не менее, если статус БД в п.6 Clean Shutdown то можно смело удалить все логи.
- Если при этом база все-таки не монтируется попробуйте после удаления всех лог-файлов выполнить в консоли PowerShell Exchange команду:
Mount-database "Name my database" -Force
На этом мое злоключение закончилось, база успешно подключилась. В качестве дополнительного материала могу привести ссылку: http://www.alexxhost.ru/2010/10/eseutil.html, там описан метод мягкого восстановления. Если данная инструкция вам не помогла то попробуйте описанные там команды.
Ну и конечно не забываем про регулярное резервное копирование базы Exchange.
Статья посвящена достаточно распространенной проблеме, с которой рано или поздно сталкиваются все администраторы Exchange – повреждение (логические ошибки) в почтовом ящике пользователя. Подобные логические ошибки проявляются в таких проблемах, как ошибки синхронизации и зависания в Outlook , неправильное представление элементов в папке, их неверное количество, сбои в поиске, ошибки в общих папках и т.д.
Эти ошибки в основном возникают из-за сбоев на стороне клиента Outlook, в том случае, если клиент при обработке элементов почтовых папок некорректно обновляет флаги MAPI (особенно часто это происходит с «общими» ящиками, с которыми одновременно работают несколько пользователей). В большинстве случаев пользователь может даже не подозревать о наличие в его ящике или папках ошибок, т.к. внешне все работает нормально. Но при некоторых ошибках пользователь может испытывать проблемы с доступом к ящику или отдельным папкам, просмотру или удалению писем или папок, хранящихся в ящике и т.п.
В том случае, если пользователь сталкивается с такими проблемами, администратору сервера Exchange приходилось прибегать к одному из трех способов восстановления такого поврежденного ящика:
- Импорту данных из Outlook, запущенного в режиме кэширования, в PST файл, удалению и пересозданию почтового ящика «проблемного» пользователя на сервере, и, наконец, импорту данных из PST-файла в новый ящик Exchange. Данная методика предполагает определенное количество ручных манипуляция на компьютере пользователя.
- Полное отключение (размонтирование) почтового хранилища и его проверка утилитой Isinteg.exe (Information Store Integrity Checker), позволяющей исправить повреждения в базе Exchange на уровне приложения. Данный метод требует довольно длительного простоя почтового сервиса для всех пользователей, чьи ящики располагаются в отключенной базе.
Примечание. В некоторых случаях, можно попытаться переместить все рабочие ящики пользователей в «здоровую» почтовую базу. В этом случае получится провести проверку целостности хранилища без отключения большого количества пользователя. Однако, эта методика, по разным причинам, не всегда применима.
- Восстановление почтовой базы Exchange из резервной копии, импорт данных конкретного ящика в PST файл и дальнейший перенос данных в пересозданный ящик. Такая методика имеет недостаток – будут потеряны все письма, которые попали в ящик пользователя после выполнения последнего бэкапа.
Описанными выше методиками приходилось пользоваться администраторам Exchange-серверов вплоть до выхода Exchange 2010 SP1, в котором появился более удобный функционал для восстановления логической структуры поврежденного ящика – комадлет Powershell New-MailboxRepairRequest. Данный командлет позволяет на прикладном уровне найти и исправить логические ошибки и повреждения в базе Exchange, причем поиск и исправление ошибок может производиться как для конкретного ящика, так и для всех ящиков в базе (последовательно). Т.е. не требуется целиком переводить почтовую базу в режим offline, а в каждый конкретный момент времени будет недоступен только один ящик, тот, для которого в данный момент проводится проверка и восстановление целостности. Перед выполнением одного из описанных выше радикальных способов восстановления целостности ящика, определенно стоит попробовать воспользоваться этой командой.
Данный командлет можно использовать для поиска, восстановления и мониторинга поврежденных ящиков во всех поддерживаемых версиях Exchange: 2010 ,2013 и 2016.
Синтаксис команды таков:
New-MailboxRepairRequest -Mailbox <MailboxIdParameter> -CorruptionType <MailboxStoreCorruptionType[]> [-Archive <SwitchParameter>] [-Confirm [<SwitchParameter>]] [-DetectOnly <SwitchParameter>] [-DomainController <Fqdn>] [-WhatIf [<SwitchParameter>]]
Командлет позволяет найти и исправить следующие типы повреждений в ящиках Exchange:
- SearchFolder – ошибки в папках поиска
- AggregateCounts – проверка и исправление информации о количестве элементов в папках и их размере
- FolderView – неверное содержимое, отображаемое представлениями папок
- ProvisionedFolder – нарушения логической структуры папок
С помощью параметра DetectOnly можно выполнить проверку ящика или почтовой базы без выполнения каких-либо действий, например:
New-MailboxRepairRequest -Mailbox winitpro -DetectOnly -CorruptionType ProvisionedFolder, SearchFolder
Следующий пример запустит процесс анализа и восстановления ящика пользователя winitpro на все 4 типа повреждений:
New-MailboxRepairRequest -Mailbox winitpro -CorruptionType ProvisionedFolder, SearchFolder, AggregateCounts, Folderview
Так можно запустить поиск ошибок и их восстановление для всех ящиков базы:
New-MailboxRepairRequest -Database “MailBaseMsk1” -CorruptionType ProvisionedFolder, SearchFolder, AggregateCounts, Folderview
Команда выполняется в фоновом режиме и в консоль PowerShell результатов выполнения не выводит. Отследить ее запуск и восстановление можно по идентификатору задачи RequestID и журналу событий Windows (источник событий MSExchangeIS Mailbox Store: событие EventID 10059 — запуск сканирования, EventID 10048 успешное завершение операции).
Также могут быть полезными следующие EventID (для удобства отслеживания процедуры восстановления ящиков Exchange, их можно собрать в отдельное представление журнала MSExchangeIS Mailbox Store)
- 10044 – ошибка выполнения запроса восстановления ящика
- 10045 — ошибка выполнения запроса восстановления базы
- 10046 – Восстановление логической структуры ящика завершено успешно
- 10047 – запуск запроса восстановления уровня ящика
- 10048 – запрос восстановления успешно завершен
- 10049 – ошибка выполнения восстановления, обнаружен другой выполняющийся запрос в этой же базе
- 10050 –запрос восстановления пропущен для ящика
- 10051 – запрос восстановления отменен из-за того, что база отмонтирована
- 10059 – запуск восстановления на уровне базы Exchange
- 10062 – обнаружено повреждние
- 10064 – запуск восстановления общей папки
Совет. В Exchange 2013 появился специальный командлет Get-MailboxRepairRequest, позволяющий узнать статус выполнения операции восстановления ящика.
Примечание. Одной из особенностей командлета New-MailboxRepairRequest – после его запуска, процедуру исправления ящика нельзя прервать без остановки службы Exchange Information Store и отмонтирования почтовой базы.
В том случае, если на сервере имеется несколько почтовых баз, с целью сохранения производительности сервера Exchange, не рекомендуется одновременно запускать New-MailboxRepairRequest сразу для большого количества баз (не смотря на то что, для одной базы поддерживается только один процесс MailboxRepairRequest, в рамках одного сервера одновременно может работать до 100 запросов).
В качестве практического примера использования командлета рассмотрим небольшой кейс.
Пользователь Exchange столкнулся с невозможностью просмотра писем в одной из папок Outlook. Указанная папка была восстановлена из резервной копии ящика. Однако саму папку ни из Outlook, ни из Outlook Web App, ни даже hard и soft удалением с помощью MFCMAPI, удалить не получилось. Ошибка клиента Outlook, мало о чем говорит:
Cannot delete this folder. Right-click the folder, and then click Properties to check your permissions for this folder. See the folder owner or your administrator to change your permissions. Outlook is synchronizing local changes made to items in this folder. You cannot remove this folder until the synchronization with the server is complete
Для проверки и восстановления целостности ящика была запущена команда:
New-MailboxRepairRequest -Mailbox [email protected] -CorruptionType ProvisionedFolder,SearchFolder,AggregateCounts,Folderview
После успешного завершения операции восстановления (событие 10048 в журнале), поврежденная папка в Outlook Web App пропала немедленно, в Outlook же, для корректного отображения «обновленного» ящика пришлось удалить локальный кэш (ost файл).
Обслуживание баз данных Exchange бывает двух видов: непрерывное и по требованию. В данной статье рассматриваются оба типа обслуживания, а также изменения, внесенные специалистами Microsoft в Exchange Server 2010, включая некоторые новые команды, доступные в Exchange Server 2010 SP1
Основой Microsoft Exchange Server являются базы данных, хотя это не так очевидно, как для приложений типа Microsoft SQL Server. Базы данных требуют постоянного внимания для поддержания нужного уровня производительности. .
Необходимость в обслуживании
Некоторые специалисты утверждают, что правильно спроектированное приложение для работы с базами данных должно быть самообслуживаемым. Однако эта цель пока еще не достигнута в реальных приложениях, в том числе в Exchange. Обслуживание необходимо для оптимизации внутренних структур баз данных, удаления устаревших данных и применения политик управления. Большая часть этой работы производится в фоновом режиме, как часть непрерывного обслуживания, осуществляемого процессом Exchange Information Store, а помощник для управляемых папок Managed Folder Assistant отвечает за применение правил политик сохранения (retention policies) к почтовым ящикам, которые подпадают под действие этих политик.
В Exchange 2010 реализована новая схема базы данных, это первая полная переработка внутренней структуры после выхода Exchange Server 4.0 в 1996 году. Предыдущие модификации, например увеличение размера страницы с 4 до 8 Кбайт в Exchange Server 2007, помогли Exchange справиться с запросами к современным почтовым системам, но не могли стать основой для системы, в которой даже в корпоративной среде нормой вскоре будут почтовые ящики размером 10 Гбайт. Новая схема, реализованная в Exchange 2010, использует набор внутренних таблиц, принадлежащих отдельным почтовым ящикам, а не относящихся ко всей базе данных в целом. Это изменение не выглядит значительным, но оно позволяет процессу Store более эффективно извлекать данные в ответ на запросы пользователей, особенно в современных средах, в которых на одном сервере хранится несколько тысяч почтовых ящиков. Другие изменения, такие как увеличение размера страницы до 32 Кбайт и отсрочка обновления представлений до запроса элементов пользователем, меняют структуру ввода-вывода с огромного количества небольших произвольных операций ввода-вывода на малое количество крупных последовательных операций. Существенно, что Exchange 2010 обрабатывает больше данных значительными порциями, а не мелкими кусочками. В Microsoft иногда называют использование мелких произвольных операций ввода-вывода nickel and diming, что дословно означает «монеты по 5 и 10 центов», а перевести можно как «разорение на мелких монетах».
Этот подход обусловлен возрастанием среднего размера сообщения с 4 Кбайт в 1996 году до более 100 Кбайт сегодня и отсюда значительным снижением количества выполняемых операций ввода-вывода в секунду (IOPS) на один почтовый ящик. Что касается производительности в целом, то ваши результаты будут сильно зависеть от многих параметров среды, особенно от используемого оборудования для системы хранения и от размещения различных файлов (операционная система, Exchange, базы данных, журналы транзакций), но в целом можно утверждать, что компании, внедрившие Exchange 2010 в производственной среде, получат значительное снижение операций ввода-вывода по сравнению с Exchange 2007 и гигантское снижение по сравнению с Exchange Server 2003. Рекламные публикации Microsoft по Exchange 2010 говорят о снижении количества операций ввода-вывода на 70% при переходе с Exchange 2003 на Exchange 2007 и примерно таком же улучшении после изменений, сделанных в Exchange 2010. Все эти цифры не нужно принимать за чистую монету, пока вы не проверите показатели производительности на своих производственных серверах. Но нет никакого сомнения, что улучшение будет. Вопрос в том, насколько лучше будет работать Exchange 2010 на оборудовании, выбранном вами для его развертывания.
Работа в режиме 24×7
Exchange всегда обладал возможностью фонового обслуживания баз данных. Отличие Exchange 2010 в том, что работа механизма Extensible Storage Engine (ESE), или обслуживание структур баз данных, выполняется по умолчанию в режиме 24 часа 7 дней в неделю, а не в заданном временном окне, как это было в предыдущих версиях (при необходимости вы могли задать в Exchange нужное именно вам временное окно). Недостаток использования временного окна заключается в том, что его могло не хватить для выполнения всей работы. И эта проблема росла с увеличением базы данных, так что приходилось увеличивать это окно в надежде, что удастся успеть выполнить всю работу.
Операции по обслуживанию очень важны для баз данных Exchange, так как они выполняют следующие действия:
- удаление из базы данных элементов и почтовых ящиков («жесткое удаление») по истечении срока сохранения;
- поиск страниц, ранее занятых удаленными элементами и почтовыми ящиками, и их возврат для использования базой данных;
- проверка контрольных сумм страниц для поиска поврежденных страниц.
Exchange 2010 выполняет все эти операции по обслуживанию, но теперь сканирование ESE может осуществляться непрерывно в режиме 24×7, если только вы не отключите фоновое обслуживание базы данных путем изменения ее свойств, как показано на экране 1.
 |
| Экран 1. Установка параметров обслуживания базы данных почтовых ящиков |
Если для базы данных разрешено сканирование ESE в режиме 24×7, процесс Store непрерывно вычисляет контрольные суммы страниц, гарантируя, что целостность базы данных постоянно проверятся. Это очень важно, так как Exchange 2010 также предоставляет возможность исправлять отдельные проблемные страницы внутри группы доступности баз данных database availability group (DAG). Если процесс Store обнаруживает проблемную страницу (для которой не выполняется проверка контрольной суммы), он может отправить серверам, хранящим другие копии этой базы данных, запрос на предоставление корректной копии страницы. После получения корректной копии Store может исправить базу данных и восстановить ее целостность. Автоматическое обнаружение и исправление проблемных страниц — значительное преимущество использования серверов почтовых ящиков в группе DAG, так как это избавляет администраторов от классической ошибки с кодом 1018 (нарушение целостности страницы).
Сканирование ESE в режиме 24×7 — не единственный вид постоянно выполняемого обслуживания. Exchange 2010 выполняет дефрагментацию в режиме онлайн для оптимизации внутренней структуры, элементы удаляются из базы данных непосредственно сразу после истечения срока хранения, не дожидаясь наступления очередного окна обслуживания, а удаленные страницы сразу же возвращаются в повторное использование для хранения новых элементов. И наконец, процесс Store анализирует состояние непрерывности базы данных после выполнения транзакций и при необходимости запускает фоновый поток для перемещения данных между страницами, чтобы Exchange мог загружать большие непрерывные порции данных, вместо выискивания и извлечения из разных частей базы данных всех страниц, необходимых для выполнения транзакции.
Все эти виды деятельности регулируются автоматически таким образом, чтобы фоновое обслуживание не лишало серверы возможности выполнять клиентские запросы. Другими словами, в моменты пиковой нагрузки Exchange ограничивает объем фонового обслуживания и снимает эти ограничения, когда поток запросов пользователей сокращается.
Для выполнения обработки, например перемещения страниц, необходимой для обслуживания в режиме 24×7, требуются некоторые дополнительные циклы процессора и подсистемы ввода-вывода. Однако это не должно быть проблемой для большинства современных многоядерных серверов, особенно если операции ввода-вывода осуществляются не самим сервером.
Обслуживание по требованию
При условии что все автоматическое обслуживание выполняется в фоновом режиме, у администраторов становится меньше оснований вмешиваться в работу серверов Exchange 2010 для выполнения обслуживания по требованию. Однако мы пока еще живем не в идеальном мире, и администраторы должны уметь распознавать два основных типа повреждений баз данных: логические и физические.
Логические ошибки проявляются в таких проблемах, как неверное количество элементов в папке или неправильное их представление, которое не включает все нужные элементы. Логические ошибки часто возникают в результате сбоев на стороне клиента, когда клиент при обработке элементов в папке некорректно обновляет флаги MAPI. Такие проблемы обычно терпимы в том смысле, что вы можете нормально работать, даже если в папке или почтовом ящике есть ошибки. Некоторые пользователи вообще не замечают таких ошибок. Ведь если Outlook выдает информацию, что в папке имеется 1119 элементов, будет ли у кого-нибудь время сосчитать все элементы и убедиться, что Outlook верно отобразил их количество, предоставленное ему сервером Exchange?
Физические ошибки намного хуже по причине влияния на нормальную работу сервера Exchange, так как они могут сделать базу данных недоступной для пользователей. В прошлом физические ошибки или повреждения могли быть вызваны недоработками в программном обеспечении или аппаратными сбоями. Сегодня подавляющее большинство физических ошибок обусловлены аппаратными сбоями, такими как неполадки в дисковом контроллере при попытке записать обновленную страницу в базу данных. Физические повреждения приводят к потере данных, если страницы, содержащие индексы и контент почтовых ящиков, не могут быть исправлены.
В предыдущих версиях Exchange обслуживание по требованию осуществлялось с помощью двух утилит командной строки, входящих в набор инструментов Exchange. ISINTEG (Information Store Integrity, утилита поддержания целостности хранилища информации) исправляла логические ошибки, ESEUTIL (или даже EDBUTIL, если вы помните такое давнее название) боролась с проблемами на физическом уровне, в недрах базы данных. Эти утилиты — напоминание о тех днях, когда было допустимо отключить базы данных на несколько часов для выполнения обслуживания. По этой причине утилиты были проклятием для администраторов. Принимая во внимание размеры нынешних почтовых баз данных, их обработка может длиться много часов, а это ставит под угрозу возможность соответствия соглашениям об уровне обслуживания (SLA) и другим эксплуатационным требованиям.
Новый подход к исправлению логических ошибок
ISINTEG не используется в Exchange 2010, так как Microsoft не стала обновлять эту утилиту для поддержки новой схемы базы данных. Перенос внимания в схеме базы данных с таблиц, работающих со всей базой данных, на таблицы для отдельных почтовых ящиков означает, что теперь весьма редки логические проблемы, влияющие на базу данных, и, если вы обнаружите проблему в почтовом ящике, простого перемещения почтового ящика из одной базы данных в другую может быть достаточно для устранения проблем с такими структурами, как именованные свойства, представления и списки элементов. Причина, по которой перемещение почтового ящика решает подобные проблемы, заключается в том, что операция перемещения пересоздает ящик заново в целевой базе данных и при этом ликвидирует многие логические ошибки.
В Exchange 2010 SP1 специалисты Microsoft вместо утилиты ISINTEG предложили новый набор команд для исправления баз данных почтовых ящиков и общих папок, с помощью которых администраторы могут создавать запросы на восстановление, способные устранить большинство причин сбоев в представлениях и отображении количества элементов. Это следующие виды повреждений:
- сбои в поиске папок (почтовый ящик);
- неверное общее количество элементов в папках (почтовый ящик);
- неверное содержимое, отображаемое представлениями папок (почтовый ящик);
- состояние репликации общих папок;
- контроль представлений общих папок;
- физическое повреждение общих папок.
Данные команды восстановления используют примерно такую же модель, как и запросы на перемещение, импорт и экспорт почтовых ящиков в Exchange 2010, где администратор создает запрос на восстановление, который помещается в очередь для обработки процессом Store, а тот в свою очередь асинхронно в режиме онлайн исполняет запрошенные восстановительные действия для баз данных. У пользователя нет необходимости завершать сеанс работы со своим почтовым ящиком в то время, пока Store проверяет и исправляет внутреннюю структуру почтового ящика. В Exchange 2010 SP1 отсутствуют какие-либо средства графического интерфейса для выполнения запросов на восстановление в консоли управления Exchange Management Console (EMC) или панели управления Exchange Control Panel (ECP), все действия должны выполняться с помощью команд консоли Exchange Management Shell (EMS). Вы также не сможете выполнять запросы на восстановление почтовых ящиков или общих папок на предыдущих версиях серверов Exchange, так как данная возможность зависит от обновлений схемы Active Directory, внесенных установкой Exchange 2010 SP1.
Команда New-MailboxRepairRequest создает запрос на восстановление почтового ящика, а команда New-PublicFolder DatabaseRepairRequest — запрос на восстановление базы данных общих папок. Например, следующая команда создает запрос для проверки корректности представления папки:
New-MailboxRepairRequest -Mailbox 'Redmond, Tony' -CorruptionType FolderView
Если вы добавите к запросу параметр -DetectOnly, Exchange сообщит обо всех найденных повреждениях, но не будет их устранять. Существуют и другие типы повреждений почтовых ящиков, которые могут быть исправлены: SearchFolder, AggregateCounts и ProvisionedFolder. Они служат для исправления повреждений папок поиска, количества элементов в папках и подготовленных папок (provisioned folders).
Вы можете выполнить несколько исправлений за один проход почтового ящика с помощью задания списка соответствующих параметров. Например:
New-MailboxRepairRequest -Mailbox 'Redmond, Tony' -CorruptionType FolderView, SearchFolder
Параметр Archive определяет, нужно ли процессу Store сканировать личный архив почтового ящика. Если параметр отсутствует, то архив не обрабатывается, то есть для исправления архива нужна несколько модифицированная команда:
New-MailboxRepairRequest -Mailbox 'Redmond, Tony' -CorruptionType FolderView, SearchFolder –Archive
Вы также можете одновременно просканировать все почтовые ящики в базе данных, чтобы исправить все найденные в них повреждения. Например:
New-MailboxRepairRequest -Database 'ViP Mailboxes' -CorruptionType FolderView, SearchFolder, AggregateCounts
Для баз данных общих папок сегодня можно выполнить только один вид исправлений. Это исправление списка реплик, которое делается следующим образом:
New-PublicFolderDatabaseRepairRequest -Identity ‘PFDatabase1’-CorruptionType ReplicaList
Когда вы отправляете новый запрос на восстановление почтового ящика или общей папки, Exchange посылает в ответ идентификатор задачи и имя сервера, который будет обрабатывать запрос, как показано на экране 2. Это сервер почтовых ящиков, хранящий активную копию базы данных, или сервер, на котором смонтирована база данных общих папок.
|
|
| Экран 2. Запрос на восстановление почтового ящика |
Единственное место, в котором отображается процесс восстановления, — это журнал приложений, где регистрируется событие с идентификатором 10047, когда инициируется запрос на восстановление почтового ящика (или событие с идентификатором 10059 при получении запроса на восстановление всей базы данных) и событие с идентификатором 10048, когда процесс восстановления успешно завершается и в почтовом ящике не остается никаких повреждений. Эти события регистрируются на сервере, который обрабатывает запрос. Если обнаруживается повреждение, Exchange регистрирует событие с идентификатором 10062 с описанием найденного повреждения и результатом выполненных действий. Заметим, что процессу Store может потребоваться выполнить несколько восстановительных действий, прежде чем он ликвидирует все проблемы в почтовом ящике, поэтому необходимо продолжать выполнять запросы, пока не будет зарегистрировано событие с идентификатором 10048, подтверждающее восстановление почтового ящика.
Чтобы не оказывать сильного влияния на производительность системы, вы можете выполнить только один запрос на восстановление всей базы данных. Однако на сервере можно выполнять одновременно до 100 запросов на восстановление отдельных почтовых ящиков (распределенных по нескольким базам данных).
Если база данных имеет копии внутри группы DAG, то результаты любых действий по решению проблем, обнаруженных в таблицах почтового ящика, реплицируются вместе с остальными транзакциями на все копии базы данных, а события в журнале приложений регистрируются на том сервере, на котором осуществлялось исправление. То же самое происходит и при исправлениях баз данных общих папок, за исключением того, что исправление осуществляется в одной базе данных общих папок, а результаты реплицируются с помощью механизма репликации общих папок.
Вы не можете отменить задание на восстановление или просмотреть его текущий статус. Возможно, такая функциональность будет добавлена корпорацией Microsoft в каком-либо будущем выпуске. На сегодня единственный способ прервать процесс восстановления — размонтировать базу данных или переместить ее на другой сервер. Такие действия удаляют все задания на восстановление, активные для этой базы данных.
Миф о ESEUTIL
Временами создается впечатление, что некоторые специалисты наделили ESEUTIL мифическими способностями решать любые проблемы в базах данных Exchange. Более того, они рекомендуют регулярно запускать ESEUTIL для сжатия и исправления баз данных, чтобы обеспечивать их максимально возможную производительность. Это миф и заблуждение, от которых нужно как можно скорее избавиться. Я считаю, что применение ESEUTIL подобно «операции на головном мозге» базы данных Exchange, потому что, если ESEUTIL применяется неопытным администратором и без весомых для того оснований, это может превратить базу данных в бесформенную кучу неизвестно чего.
Было время, когда применение ESEUTIL к базе данных являлось единственным средством освободить пространство в подсистеме хранения и решить ее внутренние проблемы. Эти времена прошли в начале нынешнего десятилетия, когда Microsoft наконец нашла решение, как можно с помощью фонового обслуживания эффективно возвращать в повторное использование удаленные страницы. Однако многие из нынешних администраторов застряли в том далеком времени!
До сих пор еще остаются веские основания для запуска ESEUTIL, но не постоянно и уж точно не для освобождения дискового пространства. Вам может потребоваться использовать ESEUTIL для приведения в согласованное состояние резервной копии базы данных, прежде чем ее можно будет смонтировать в качестве базы данных для восстановления, или вы можете получить рекомендацию службы поддержки Microsoft Customer Service and Support (CSS) использовать ESEUTIL для ликвидации низкоуровневых проблем в базе данных, которые не могут быть исправлены командами восстановления. В этом случае почти наверняка произойдет потеря данных, так как ESEUTIL просто удаляет те страницы, которые не может исправить.
Базы данных, функционирующие в группе DAG, имеют значительное преимущество перед нереплицируемыми базами данных в том, что они сами могут исправлять единичные проблемные страницы, запрашивая корректные данные из другой копии базы данных. Запрошенные данные помещаются в поток журнала транзакций, а затем реплицируются процессом Store во все копии базы данных, устраняя проблему.
Кроме перечисленных мной случаев я не могу представить какое-либо разумное основание, зачем мне может потребоваться размонтировать базу данных и лишить на несколько часов пользователей доступа к ней для запуска ESEUTIL, чтобы достичь некоего малозаметного улучшения в базе данных, и то не наверняка. В производственной среде это точно не имеет никакого смысла.
Обслуживание баз данных — это часть жизни администраторов Exchange. Львиная доля этой работы автоматизирована и выполняется в фоновом режиме, но иногда должны производиться некие действия по требованию для решения проблем, возникающих на логическом или физическом уровне. Новые команды восстановления, реализованные в Exchange 2010 SP1, — долгожданное улучшение, так как они позволяют избавляться от логических повреждений по требованию без прекращения доступа к базам данных. Однако мы всем еще продолжаем держаться за утилиту ESEUTIL, которая наверняка должна стать следующей в списке Microsoft для модернизации и обновления.
Тони Редмонд (exchguru@windowsitpro.com) — редактор журнала Windows IT Pro, старший технический редактор Exchange & Outlook Administrator, вице-президент и главный технолог HP Services
После неожиданного выключения сервера одна из баз не подключилась. При попытке подключить базу вручную выдается ошибка:
--------------------------------------------------------
Ошибка Microsoft Exchange
--------------------------------------------------------
Не удалось подключить базу данных 'Managers'.
Managers
Ошибка
Ошибка:
Не удалось подключить указанную базу данных. Указанная база данных: Managers; код ошибки: Сбой операции Active Manager. Ошибка: Сбой действия базы данных. Ошибка: Сбой операции с сообщением: MapiExceptionCallFailed: Unable to mount database. (hr=0x80004005, ec=-550)
При этом остальные базы успешно подключились и работают, все службы запущены.Как исправлять почтовую базу Exchange:
На всякий случай делаем копию базы и всех логов.
Проведем диагностику:
1. Запускаем Exchange Manager
2. Проверяем базу. Выполняем команду:eseutil /mh d:ExBasesMybaseMybase.edb
3. Ищем сообщение как на скриншоте. Это означает, что наша база некорректно выключилась и часть информации не перенесена из лога в базу. Если у нас есть логи и они не испорчены, то мы сможем все восстановить. Если логов нет или они испорчены, то часть данных будет потерена.
4. Проверяем логи :eseutil /ml d:ExBasesMyBase
Восстанавливаем базу Exchange
5. Если тест логов не выдал ошибку, то восстанавливаем базу:eseutil /r «E02» /l d:ExBasesMyBase /d d:ExBasesMybaseMybase.edb
E02 — имя лога
Если восстановление прошло успешно пробуем подключить почтовую базу. Иначе смотрим п.6
6. Если с логами что-то не так, можно попробовать восстановить базу игнорируя ошибку в логах:eseutil /r «E02» /a /i /l d:ExBasesMyBase /d d:ExBasesMybaseMybase.edb
Если восстановление прошло успешно пробуем подключить почтовую базу. Иначе смотрим п.7
7. Если логи содержат ошибки и база не восстановилась по п.5,6, то восстанавливаем базу без логовeseutil /p d:ExBasesMybaseMybase.edb
8. После этого пробуем подключить базу
Применимо к: Exchange Server 2010 SP1
Последнее изменение раздела: 2011-03-19
Служба поиска Exchange индексирует почтовые ящики и
поддерживаемые вложения в почтовых ящиках Exchange. Благодаря
увеличению объемов сообщений электронной почты, размеров почтовых
ящиков и квот хранилища, а также подготовке личных архивных
почтовых ящиков для пользователей и введению поиска в нескольких
почтовых ящиках для выполнения поиска на обнаружение служба поиска
Exchange является критическим компонентом серверов почтовых
ящиков в организации Microsoft Exchange Server 2010. Неполадки
со службой поиска Exchange могут повлиять на производительность
работы пользователей и на функции поиска в нескольких почтовых
ящиках.
Дополнительные сведения о службе поиска Exchange см. в разделе
Общие сведения о
подсистеме поиска Exchange.
Необходимы сведения о задачах управления, связанных с
управлением службой поиска Exchange? См. раздел Управление поиском
Exchange.
Использование командлета
Test-ExchangeSearch
В этом разделе на шаге 5 процедуры описан способ
запуска командлета Test-ExchangeSearch для выполнения
диагностики неполадок службы поиска Exchange. Командлет
Test-ExchangeSearch можно использовать для проверки функций
службы поиска Exchange для сервера почтовых ящиков, базы
данных почтовых ящиков или определенного почтового ящика. Этот
командлет доставляет тестовое сообщение на определенный почтовый
ящик (или на системный почтовый ящик базы данных, если почтовый
ящик не определен), а затем выполняет поиск, чтобы определить,
необходимо ли индексировать сообщение (включая время, затраченное
на индексацию). В обычных условиях служба поиска
Exchange индексирует сообщение в течение 10 секунд с момента
создания или отправки сообщения в почтовый ящик. Тестовое сообщение
автоматически удаляется после проверки.
Exchange 2010 включает в себя следующие улучшения для
командлета Test-ExchangeSearch.
- В стандартный вывод добавлен параметр Mailbox.
- Если имя сервера указано, командлет одновременно проверяет все
базы данных почтовых ящиков на сервере почтовых ящиков. После
запуска команды на сервере почтовых ящиков, не содержащем активную
копию базы данных, для баз данных, которые реплицируются на другие
серверы почтовых ящиков в группе доступности базы данных, проверка
выполняется автоматически на сервере, который содержит активную
копию базы данных. - При использовании командлета с параметром
MonitoringContext предоставляются дополнительные данные,
которые можно использовать при отслеживании программного
обеспечения, например Microsoft System Center Operations Manager
2007. - При использовании командлета с параметром Verbose
возвращаются дополнительные результаты и состояние для каждого
шага, а также дополнительные диагностические сведения для помощи в
устранении неполадок, связанных с поиском.
Дополнительные сведения о синтаксисе и параметрах см. в
разделе Test-ExchangeSearch.
Получение элементов, не
поддерживающих поиск
Можно использовать командлет
Get-FailedContentIndexDocuments для получения списка
элементов почтового ящика, не поддерживающих поиск, которые
невозможно индексировать с помощью службы поиска Exchange. Этот
командлет можно запустить на сервере почтовых ящиков, в базе данных
почтовых ящиков или в определенном почтовом ящике. Командлет
возвращает сведения о каждом элементе, поиск которого не удалось
выполнить. Существует несколько причин, по которым невозможно
выполнить поиск элемента почтового ящика. Например, если
сообщение электронной почты содержит тип файла вложения, для
которого не установлен фильтр поиска. Если фильтр поиска доступен
для этого типа файла, можно установить его на серверы Exchange.
 Важно! |
|---|
| Фильтры поиска, предоставленные корпорацией Microsoft, проверяются и поддерживаются корпорацией Microsoft. Перед установкой фильтров поиска на серверы Exchange в производственной среде рекомендуется проверить любые фильтры поиска сторонних производителей в тестовой среде. |
 Примечание. |
|---|
| Сообщения, содержащие файл вложения, формат которого включен в список надежных отправителей, не возвращаются в список элементов, не поддерживающих поиск. Дополнительные сведения см. в подразделе «Служба поиска Exchange и вложения» в разделе Общие сведения о подсистеме поиска Exchange. |
Дополнительные сведения о синтаксисе и параметрах см. в
разделе Get-FailedContentIndexDocuments.
Запись «Служба поиска Exchange» в разделе Разрешения для почтового
ящика.
- Проверка состояния службы Запущена ли
служба индексатора поиска Microsoft
Exchange (MSExchangeSearch) на сервере почтовых ящиков?
Если да, перейдите к шагу 2. Если нет, используйте оснастку
«Службы» консоли управления (MMC), чтобы убедиться, что служба
MSExchangeSearch запущена. Для этого выполните следующие
действия.- Нажмите кнопку Пуск, выберите пункт
Администрирование и выберите Службы. - Убедитесь, что в окне Службы для пункта Состояние
для службы Индексатор поиска Microsoft Exchange указано
значение Запущено.
- Нажмите кнопку Пуск, выберите пункт
- Проверка конфигурации базы данных почтовых
ящиков Присвоено ли параметру
IndexEnabled значение True для базы данных почтовых ящиков
пользователя? Если да, перейдите к шагу 3. Если нет, выполните
следующую команду в командной консоли Exchange, чтобы убедиться,
что для отметки IndexEnabled установлено значение True.
Скопировать кодGet-MailboxDatabase | Format-Table Name,IndexEnabled
Подробные сведения о синтаксисе и параметрах см. в разделе Get-MailboxDatabase.
- Проверка состояния сканирования базы данных почтовых
ящиков Отсканирована ли база данных Exchange?
Если да, перейдите к шагу 4. Если нет, используйте монитор
надежности и производительности для проверки счетчика Состояние
режима полного сканирования объекта производительности
Индексы поиска MSExchange. Выполните следующие шаги.- Откройте монитор надежности и производительности
(perfmon.exe). - В дереве консоли в разделе Средства наблюдения выберите
Системный монитор. - На панели системного монитора нажмите кнопку Добавить
(зеленый знак «плюс»). - В окне Добавить счетчики в списке Выбрать счетчики с
компьютера выберите сервер, на котором размещена база данных
почтовых ящиков, которую необходимо отслеживать. - В непомеченном поле под списком Выбрать счетчики с
компьютера выберите объект производительности Индексы поиска
MSExchange. - В поле Экземпляры выбранного объекта выберите экземпляр
базы данных почтовых ящиков пользователя. - Нажмите кнопку Добавить, а затем кнопкуОК.
На панели системного монитора в столбце Объект отображается
объект производительности Индексы поиска MSExchange, а его
различные счетчики отображаются в столбце Счетчик.
Просмотрите счетчик Состояние режима полного сканирования.
Если база данных все еще сканируется, ее значение равно
1. Если сканирование завершено, значение равно 0.Чтобы просмотреть другие счетчики, относящиеся к поиску,
используйте предыдущие шаги с «а» до «ж» для добавления следующих
объектов производительности.- Индексатор поиска MSExchange
- MSFTESQL-Exchange:Catalogs
- MSFTESQL-Exchange:FD
- MSFTESQL-Exchange:Indexer
- MSFTESQL-Exchange:Service
Дополнительные сведения об использовании системного монитора см. в
разделе Пошаговое руководство по отслеживанию
надежности и производительности для Windows Server 2008 - Откройте монитор надежности и производительности
- Проверка работоспособности индексирования копии базы
данных Работоспособен ли индекс содержимого?
Используйте командлет Get-MailboxDatabaseCopyStatus для
проверки работоспособности индексирования содержимого для копии
базы данных.Скопировать кодGet-MailboxDatabaseCopyStatus | Format-Table Identity,ActiveDatabaseCopy,ContentIndexState -Auto
Дополнительные сведения о синтаксисе и параметрах см. в разделе
Get-MailboxDatabaseCopyStatus. - Запуск командлета
Test-ExchangeSearch Если база данных почтовых
ящиков уже отсканирована, можно запустить командлет
Test-ExchangeSearch для базы данных почтовых ящиков или для
определенного почтового ящика.Скопировать кодTest-ExchangeSearch -Identity AlanBrewer@contoso.com
Дополнительные сведения о синтаксисе и параметрах см. в разделе
Test-ExchangeSearch. - Проверка журнала событий
приложений Проверка журнала событий приложений
на наличие сообщений об ошибках, связанных с поиском, с помощью
средства просмотра событий или командной консоли Exchange.
Проверьте события Source: MSExchangeSearch Indexer и
msftesql-Exchange. Дополнительные сведения см. по ссылке,
приведенной в записи журнала событий. - Перезапуск службы индексатора поиска Microsoft
Exchange Используйте оснастку «Службы» консоли
управления (MMC) или командную консоль Exchange, чтобы остановить и
перезапустить службу индексатора поиска
Microsoft Exchange (MSExchangeSearch).- Нажмите кнопку Пуск, выберите пункт
Администрирование и выберите Службы. - В области Службы щелкните правой кнопкой мыши службу
Индексатор поиска Microsoft Exchange и нажмите кнопку
Остановить. После остановки службы повторно щелкните службу
правой кнопкой мыши и выберите команду Запустить.
- Нажмите кнопку Пуск, выберите пункт
- Повторное заполнение каталога поиска В
некоторых случаях, например при повреждении каталога поиска, может
потребоваться повторно заполнить каталог. При необходимости
повторного заполнения каталога поиска служба поиска
Exchange уведомляет пользователя с помощью ввода записей в
журнал событий приложений. Дополнительные сведения о повторном
заполнении каталога поиска см. в разделе Повторное заполнение
каталога поиска.
Резюме: Microsoft Scripting Guy, Ed Wilson рассказывает об использовании Windows PowerShell для упрощения проверки статуса баз данных Exchange.
Q: У меня есть довольно большое число серверов Exchange, и когда я делаю восстановление баз данных, зачастую я не могу подключить базу, потому что она находится в состоянии «Dirty». Могу ли я использовать Windows PowerShell для исправления и подключения баз данных?
Используем eseutil для проверки состояния базы данных Exchange
Что касается Exchange и Windows PowerShell, то нельзя сказать, что вам совсем не повезло только потому, что вам придется использовать Eseutil. Это потому, что Windows PowerShell неплохо работает с утилитами командной строки. Microsoft Windows PowerShell MVP Sean Kearney написал целую серию статей, в которых он рассказывает о работе с утилитами командной строки из Windows PowerShell.
Одна из вещей, которая мне не нравится, это то, что при работе с Eseutil вам нужно указывать путь к базе данных, с которой вы собираетесь работать. Это потому, что обычно пути представляют из себя довольно длинные строки, содержащие GUID и другие непростые вещи, которые значительно снижают шансы на их правильный ввод. К счастью, эту проблему можно довольно просто решить с помощью PowerShell. Следующая команда возвращает путь к базе данных Exchange.
Get-MailboxDatabase -Status | select edbfilepath
Команда и ее вывод приведены на следующем рисунке.
Используем PowerShell для подключения и отключения баз данных Exchange
Чаще всего, когда вам приходится работать с Eseutil, это происходит потому, что база данных Exchange не монтируется. Таким образом, если я собираюсь запустить Eseutil для проверки статуса базы, она должна находиться в состоянии «offline». Это достаточно просто сделать из PowerShell. Для этого нужно получить все базы данных Exchangeс помощью командлета Get-MailboxDatabase и передать результаты командлету Dismount-Database.
Get-MailboxDatabase | Dismount-Database –confirm:$false
Запуск вышеприведенной команды отключит все базы данных Exchange. При этом запрос подтверждения выведен не будет – для этого указан параметр -confirm:$false.
Если я хочу подключить все базы данных Exchange, я передам результаты командлету Mount-Database.
Get-MailboxDatabase -Status | Mount-Database
Запускаем Eseutil для каждой базы данных Exchange
Для определения состояния баз данных Exchange мне нужно запустить команду eseutil с параметром/mh. Также нужно указать полный путь к базе данных Exchange. Тут нам опять очень пригодится PowerShell. Мы уже получали путь к базе через PowerShell. Так же я знаю, что он может выполнять повторяющиеся операции. Символ «%» в нижеприведенной команде – это алиас для командлетаForeach-Object. При помощи этой команды я запущу eseutil для каждой их баз данных Exchange.
Get-MailboxDatabase -Status | % { eseutil /mh $_.edbfilepath }
Команда выводит достаточно много информации. Меня же интересует значение поля «State».
Если мне не хочется просматривать весь вывод, я могу отфильтровать результаты с помощью командлета Select-String. Я ищу строку, содержащую слово «State».
[PS] C:>Get-MailboxDatabase -Status | % { eseutil /mh $_.edbfilepath } | Select-String -Pattern «State:»
State: Clean Shutdown
State: Clean Shutdown
[PS] C:>
Подключаем базы почтовых ящиков
Итак, я знаю, что обе мои базы в состоянии «Clean Shutdown» и я смогу их вернуть в состояние «online». Для этого я воспользуюсь следующей командой.
Get-MailboxDatabase –Status | Mount-Database
Так как предыдущая команда не выводит никакой информации, я хочу убедиться, чтоб базы почтовых ящиков действительно подключены. Для этого я использую командлет Get-MailboxDatabase и выберу свойства name и mounted.
[PS] C:>Get-MailboxDatabase -Status | select name, mounted
Name Mounted
—- ——-
Mailbox Database 1301642447 True
Mailbox2 True
[PS] C:>
Итак, это все, что касается Windows PowerShell и Eseutil.
Недавно столкнулись с ситуацией, что после восстановления MailBox Database из бэкапа в Exchange 2010 база упорно отказывалась монтироваться. Eseutil ни в какую не хотел восстанавливать базу в режиме soft repair. Он постоянно выкидывал ошибку — bad signature for a log file. Номер ошибки – 530.
В раздумьях как решить проблему наткнулся на отличную заметку, состоящую из шагов для восстановления базы. Которая помогла восстановить проблемный Mailbox Database. Решил заметку перевести и оставить для себя на будущее, возможно пригодится.
1. Сделайте бэкапы файлов с расширениями edb, log и stm.
Скопируйте priv.edb, pub.edb, логи (.log) и файлы stm в другое расположение.
2. Убедитесь, что у вас есть 110% свободного места на диске.
Убедитесь, что у вас есть 110% свободного места на диске для базы. Не используйте сетевые шары.
3. Проверьте состояние вашей базы
Сделайте проверку состояния базы при помощи команды
eseutil /mh «путь до файла базы edb» (eseutil /mh «D:dbdatabasedb.edb»)
4. Проверьте статус базы.
Статус базы будет – dirty shutdown.
5. Попытайтесь использовать softrepair
eseutil /r – запускайте из папки с логами, и укажите префикс логов (eseutil /r E04).
Или запустите так – eseutil /r «prefix»<E04> /l <путь до логов>
Или так – esetuil /r E00 /l D:dblogs /d D:dbdatabase
6. Проверьте снова статус
Если статус поменялся на clear shutdown можно переходить к пункту 9.
7. Если softrepair не сработал, попробуйте hard repair.
Учтите, обрабатываются данные со скоростью 3-5 ГБ в час.
eseutil /p (esetuil /p «путь до файла edb»), esetuil /p «D:dbdatabasedb.edb»
8. Выполните дефрагментацию базы данных:
esetuil /d (eseutil /d «путь до файла edb»)
После выполнения команды необходимо вручную удалить все файлы логов в папке MDBDATA (я удалял все файлы с расширением log в папке с логами), перед попыткой смонтировать базу данных.
9. Проверьте целостность базы данных
Если есть достаточно времени (около 2-10 минут на обработку 1ГБ данных), можно запустить проверку целостности, если времени нет – шаг можно пропустить.
isinteg -s “имя сервера” -test alltests
Если проверка будет провалена, попробуйте
isinteg -s “имя сервера” -fix -test -alltests
Выполняйте команду до тех пор, пока у всех ошибок не станет статус 0 или статус не перестанет меняться. (Иногда необходимо 3 прохода для достижения результата).
10. Проверьте состояние снова.
Снова выполните eseutil /mg, в результате статус должен быть clear shutdown.
Перед выполнением hard repair необходимо:
1. Убедиться, что базы размонтированы в консоли управления.
2. Не забыть сделать бэкап всех файлов.
Имейте ввиду, что использование eseutil /p является крайней мерой. Запускать команду следует только в том случае, если не удается примонтировать базу данных из-за нарушения целостности.
Команда удаляет все данные, которые посчитает ненужными (поврежденные данные, незавершенные транзакции и т.д.).
Команда обрабатывает около 3-5 ГБ данных в час.
Не щелкайте по экрану командной строки во время выполнения команды, тем самым вы переведете команду в состояние паузы. Если это произойдет нажмите F5 для продолжения.
У вас должно быть как минимум 110% свободного места от размера базы для выполнения eseutil /d.
Если вы явно не укажите команде ключ /t для задания папки temp, по умолчанию используется папка exchsrvr/bin
Отключите службу smtp перед монтированием базы, чтобы избежать попадания в нее новых писем? при проверке работоспособности базы при первом подключении.
Isinteg должна запускаться, что бы исправить логические повреждения вызванные удалением данных.
Здесь мы рассмотрим восстановление баз данных в Microsoft Exchange Server 2010 с помощью встроенной утилиты Eseutil.
Рассмотрим восстановление баз данных с помощью встроенной утилиты Eseutil.
Все операции производим из командной строки или из Exchange management shell.
Иногда возникают проблемы при подключении баз данных данныхв Exchange 2010 возможные причины которых могут быть:
- не правильное завершение работы сервера
- что то случилось с логами.
Для начала надо посмотреть состояние базы данных.
Eseutil / MH «Путь к базе данных»
После, выведется список разных параметров, нас интересует строка State:
Если в строке State указано что база Clean shutdown, то переместите все файлы из папки журналов транзакций (на всякий случай не удаляйте, скопируйте лучше в другую папку) и подключите базу. Если не помогло, перезагрузите сервер и попробуйте подключить базу.
Если в строке State: указано что база Dirty Shutdown.
Надо убедиться что с логами всё в порядке командой Eseutil / ML «Путь лог-файлов префикс журнала» (если баз несколько, то префиксы будут e00, e01, e02, e03)
Если все журналы логов на месте (как показано ниже) переходим к пункту 1. Если не всё в порядке и есть ошибки, переходим к пункту 2.
1. Восстанавливаем базу с помощью мягкого восстановления — Eseutil / R
Eseutil / r <префикс журнала(e00 и.т.д)> / l «Путь лог-файлов» / D «Путь к базе данных»
После того как в консоли появится сообщение что Operation complete successfully, подключаем базу.
Если не помогло, перезагрузите сервер и подключаем базу.
2.Если в строке с логами не всё в порядке то мягкое восстановление не поможет и придётся делать жесткое восстановление Eseutil / P (при жестком восстановлении все логи транзакций будут удалены). Eseutil / P «Путь к базе данных»
После того как появится сообщение что Operation complete successfully, подключаем базу.
Если не помогло, перезагрузите сервер и подключаем базу.
Запись опубликована в рубрике Exchange 2010 с метками Exchange 2010. Добавьте в закладки постоянную ссылку.
Время от времени возникают ситуации, когда администратору Exchange Server 2010 нужно быстро убедиться в том, что его система работает нормально. В большинстве случаев хватает нескольких проверок — состояние служб и очередей, баз сообщений, отработка коммандлетов Test-*.
Как быстро узнать, все ли службы Exchange на всех серверах запущены и нормально работают? Для этого существует встроенный командлет Test-ServiceHealth. А если у вас несколько серверов, да еще Вы хотите вывод на экран сделать поудобнее, то можно воспользоваться следующим сценарием.
Get-ExchangeServer |where {$_.AdminDisplayVersion -like "*14*"}|
foreach{ $srv = $_.Name; Test-ServiceHealth -server $_.Name} | where {$_.RequiredServicesRunning -eq $False } |
format-table @{name="Server"; expression={$srv}},role,servicesnotrunning -autosize
Вывод команды будет выглядеть примерно так.
Server Role ServicesNotRunning
------ ---- ------------------
EX01 Mailbox Server Role {MSExchangeIS, MSExchangeMailboxAssistants, MSExchangeMailSubmission
EX02 Client Access Server Role {MSExchangeAB, MSExchangeFBA, MSExchangeFDS
EX03 Hub Transport Server Role {MSExchangeEdgeSync, MSExchangeServiceHost, MSExchangeTransport
Мы видим, что на серверах не запущены некоторые сервисы Microsoft Exchange, а также роль сервера, которая не работает. Если информация после выполнения скрипта не отображается, то это значит, что все сервисы запущены. Давайте рассмотрим повнимательнее, как этот скрипт работает.
Get-ExchangeServer | where {$_.AdminDisplayVersion -like «*14*»} Отбираем объекты Exchange Server 2010. В системе могут быть серверы Exchange 2007, с которыми этот скрипт не работает.
foreach{ $srv = $_.Name; Test-ServiceHealth -server $_.Name} для каждого объекта Exchange Server, полученного по конвейеру, сценарий выполняет блок команд. Переменной $srv присваивается имя сервера для использования в команде вывода на экран. Командлет Test-ServiceHealth с параметром -server тестирует сервисы на текущем сервере и передаёт в конвейер информацию о результатах теста.
where {$_.RequiredServicesRunning -eq $False } выбираем результаты в которых не запущены службы.
ft @{name=»Server»; expression={$srv}},role,servicesnotrunning -autosize выводим на экран содержимое переменной $srv в столбце Server и столбцы role, servicesnotrunning.
Конечно мониторинг за системой должен быть настроен с помощью SC Operations Manager или другого ПО, но я люблю пользоваться еще и сценариями.
Часто используемые сценарии я храню в текстовом файле на сервере и при необходимости просто их копирую оттуда в EMS и запускаю. Хотя есть масса вариантов с использованием ISE или PowerGUI. Этому я посвящу этому целый вебкаст после возвращения с TechEd 2011.
p.s. спасибо Васе Гусеву за помощь в отладке скрипта и ценные мысли. 🙂
Связанные записи:
Перейти к содержанию
На чтение 2 мин Просмотров 5.6к. Опубликовано 17.12.2015
Случилось на днях неприятное происшествие: в результате непредвиденного сбоя отключился диск с базой exchange 2010. В результате после восстановления диска база отказалась подключаться на сервере Exchange. Поэтому тема заметки «Восстановление баз exchange» в полевых условиях.
При попытке ручного подключения базы данных я получал ошибку:
Couldn't mount the database that you specified. Specified database: Mailbox Database; Error code: An Active Manager operation failed. Error: The database action failed. Error: Operation failed with message: MapiExceptionCallFailed: Unable to mount database. (hr=0x80004005, ec=-515)
Последовательность действий по восстановлению баз exchange
- Сделал резервную копию поврежденной базы данных. Процесс этот не быстрый, размер базы был более 400 гб. Но это следовало сделать, чтобы иметь возможность повторить процедуру восстановления базы если что-то пойдет не так.
- Проверил диск с базой данных на ошибки утилитой chkdsk.
- Проверяем базу с помощью утилиты eseutil. Она находится в подпапке bin папки куда установлен Exchange. Для проверки используем команду:
eseutil /mh "d:путькбдбазаданных.edb"
- В выводе команды ищем строку содержащую State: Dirty Shutdown. Это значит, что база данных не была корректно отмонтирована.
- Производим починку базы данных командой:
eseutil /p "d:путькбдбазаданных.edb"
Процесс не быстрый, на моей базе в 400 Гб он занял около двух часов.
- После завершения повторяем команду из п.3. Вы должны увидеть State: Clean Shutdown. На всякий случай делаем копию восстановленной базы (на ваше усмотрение).
- Пробуем подключить базу в консоли Exchange, если все подключилось то на этом процедура закончена.
- Если база не подключается то необходимо проверить логи командой:
eseutil /ml "d:путьклогамE00"
Где E00-начальная последовательность именования лог-файлов. На моем сервере она была к примеру E01. Во время проверки необходимо убедится, что все лог файлы прошли без ошибок. Тем не менее, если статус БД в п.6 Clean Shutdown то можно смело удалить все логи.
- Если при этом база все-таки не монтируется попробуйте после удаления всех лог-файлов выполнить в консоли PowerShell Exchange команду:
Mount-database "Name my database" -Force
На этом мое злоключение закончилось, база успешно подключилась. В качестве дополнительного материала могу привести ссылку: http://www.alexxhost.ru/2010/10/eseutil.html, там описан метод мягкого восстановления. Если данная инструкция вам не помогла то попробуйте описанные там команды.
Ну и конечно не забываем про регулярное резервное копирование базы Exchange.
Статья посвящена достаточно распространенной проблеме, с которой рано или поздно сталкиваются все администраторы Exchange – повреждение (логические ошибки) в почтовом ящике пользователя. Подобные логические ошибки проявляются в таких проблемах, как ошибки синхронизации и зависания в Outlook , неправильное представление элементов в папке, их неверное количество, сбои в поиске, ошибки в общих папках и т.д.
Эти ошибки в основном возникают из-за сбоев на стороне клиента Outlook, в том случае, если клиент при обработке элементов почтовых папок некорректно обновляет флаги MAPI (особенно часто это происходит с «общими» ящиками, с которыми одновременно работают несколько пользователей). В большинстве случаев пользователь может даже не подозревать о наличие в его ящике или папках ошибок, т.к. внешне все работает нормально. Но при некоторых ошибках пользователь может испытывать проблемы с доступом к ящику или отдельным папкам, просмотру или удалению писем или папок, хранящихся в ящике и т.п.
В том случае, если пользователь сталкивается с такими проблемами, администратору сервера Exchange приходилось прибегать к одному из трех способов восстановления такого поврежденного ящика:
- Импорту данных из Outlook, запущенного в режиме кэширования, в PST файл, удалению и пересозданию почтового ящика «проблемного» пользователя на сервере, и, наконец, импорту данных из PST-файла в новый ящик Exchange. Данная методика предполагает определенное количество ручных манипуляция на компьютере пользователя.
- Полное отключение (размонтирование) почтового хранилища и его проверка утилитой Isinteg.exe (Information Store Integrity Checker), позволяющей исправить повреждения в базе Exchange на уровне приложения. Данный метод требует довольно длительного простоя почтового сервиса для всех пользователей, чьи ящики располагаются в отключенной базе.
Примечание. В некоторых случаях, можно попытаться переместить все рабочие ящики пользователей в «здоровую» почтовую базу. В этом случае получится провести проверку целостности хранилища без отключения большого количества пользователя. Однако, эта методика, по разным причинам, не всегда применима.
- Восстановление почтовой базы Exchange из резервной копии, импорт данных конкретного ящика в PST файл и дальнейший перенос данных в пересозданный ящик. Такая методика имеет недостаток – будут потеряны все письма, которые попали в ящик пользователя после выполнения последнего бэкапа.
Описанными выше методиками приходилось пользоваться администраторам Exchange-серверов вплоть до выхода Exchange 2010 SP1, в котором появился более удобный функционал для восстановления логической структуры поврежденного ящика – комадлет Powershell New-MailboxRepairRequest. Данный командлет позволяет на прикладном уровне найти и исправить логические ошибки и повреждения в базе Exchange, причем поиск и исправление ошибок может производиться как для конкретного ящика, так и для всех ящиков в базе (последовательно). Т.е. не требуется целиком переводить почтовую базу в режим offline, а в каждый конкретный момент времени будет недоступен только один ящик, тот, для которого в данный момент проводится проверка и восстановление целостности. Перед выполнением одного из описанных выше радикальных способов восстановления целостности ящика, определенно стоит попробовать воспользоваться этой командой.
Данный командлет можно использовать для поиска, восстановления и мониторинга поврежденных ящиков во всех поддерживаемых версиях Exchange: 2010 ,2013 и 2016.
Синтаксис команды таков:
New-MailboxRepairRequest -Mailbox <MailboxIdParameter> -CorruptionType <MailboxStoreCorruptionType[]> [-Archive <SwitchParameter>] [-Confirm [<SwitchParameter>]] [-DetectOnly <SwitchParameter>] [-DomainController <Fqdn>] [-WhatIf [<SwitchParameter>]]
Командлет позволяет найти и исправить следующие типы повреждений в ящиках Exchange:
- SearchFolder – ошибки в папках поиска
- AggregateCounts – проверка и исправление информации о количестве элементов в папках и их размере
- FolderView – неверное содержимое, отображаемое представлениями папок
- ProvisionedFolder – нарушения логической структуры папок
С помощью параметра DetectOnly можно выполнить проверку ящика или почтовой базы без выполнения каких-либо действий, например:
New-MailboxRepairRequest -Mailbox winitpro -DetectOnly -CorruptionType ProvisionedFolder, SearchFolder
Следующий пример запустит процесс анализа и восстановления ящика пользователя winitpro на все 4 типа повреждений:
New-MailboxRepairRequest -Mailbox winitpro -CorruptionType ProvisionedFolder, SearchFolder, AggregateCounts, Folderview
Так можно запустить поиск ошибок и их восстановление для всех ящиков базы:
New-MailboxRepairRequest -Database “MailBaseMsk1” -CorruptionType ProvisionedFolder, SearchFolder, AggregateCounts, Folderview
Команда выполняется в фоновом режиме и в консоль PowerShell результатов выполнения не выводит. Отследить ее запуск и восстановление можно по идентификатору задачи RequestID и журналу событий Windows (источник событий MSExchangeIS Mailbox Store: событие EventID 10059 — запуск сканирования, EventID 10048 успешное завершение операции).
Также могут быть полезными следующие EventID (для удобства отслеживания процедуры восстановления ящиков Exchange, их можно собрать в отдельное представление журнала MSExchangeIS Mailbox Store)
- 10044 – ошибка выполнения запроса восстановления ящика
- 10045 — ошибка выполнения запроса восстановления базы
- 10046 – Восстановление логической структуры ящика завершено успешно
- 10047 – запуск запроса восстановления уровня ящика
- 10048 – запрос восстановления успешно завершен
- 10049 – ошибка выполнения восстановления, обнаружен другой выполняющийся запрос в этой же базе
- 10050 –запрос восстановления пропущен для ящика
- 10051 – запрос восстановления отменен из-за того, что база отмонтирована
- 10059 – запуск восстановления на уровне базы Exchange
- 10062 – обнаружено повреждние
- 10064 – запуск восстановления общей папки
Совет. В Exchange 2013 появился специальный командлет Get-MailboxRepairRequest, позволяющий узнать статус выполнения операции восстановления ящика.
Примечание. Одной из особенностей командлета New-MailboxRepairRequest – после его запуска, процедуру исправления ящика нельзя прервать без остановки службы Exchange Information Store и отмонтирования почтовой базы.
В том случае, если на сервере имеется несколько почтовых баз, с целью сохранения производительности сервера Exchange, не рекомендуется одновременно запускать New-MailboxRepairRequest сразу для большого количества баз (не смотря на то что, для одной базы поддерживается только один процесс MailboxRepairRequest, в рамках одного сервера одновременно может работать до 100 запросов).
В качестве практического примера использования командлета рассмотрим небольшой кейс.
Пользователь Exchange столкнулся с невозможностью просмотра писем в одной из папок Outlook. Указанная папка была восстановлена из резервной копии ящика. Однако саму папку ни из Outlook, ни из Outlook Web App, ни даже hard и soft удалением с помощью MFCMAPI, удалить не получилось. Ошибка клиента Outlook, мало о чем говорит:
Cannot delete this folder. Right-click the folder, and then click Properties to check your permissions for this folder. See the folder owner or your administrator to change your permissions. Outlook is synchronizing local changes made to items in this folder. You cannot remove this folder until the synchronization with the server is complete
Для проверки и восстановления целостности ящика была запущена команда:
New-MailboxRepairRequest -Mailbox [email protected] -CorruptionType ProvisionedFolder,SearchFolder,AggregateCounts,Folderview
После успешного завершения операции восстановления (событие 10048 в журнале), поврежденная папка в Outlook Web App пропала немедленно, в Outlook же, для корректного отображения «обновленного» ящика пришлось удалить локальный кэш (ost файл).
Резюме: Microsoft Scripting Guy, Ed Wilson рассказывает об использовании Windows PowerShell для упрощения проверки статуса баз данных Exchange.
Q: У меня есть довольно большое число серверов Exchange, и когда я делаю восстановление баз данных, зачастую я не могу подключить базу, потому что она находится в состоянии «Dirty». Могу ли я использовать Windows PowerShell для исправления и подключения баз данных?
Используем eseutil для проверки состояния базы данных Exchange
Что касается Exchange и Windows PowerShell, то нельзя сказать, что вам совсем не повезло только потому, что вам придется использовать Eseutil. Это потому, что Windows PowerShell неплохо работает с утилитами командной строки. Microsoft Windows PowerShell MVP Sean Kearney написал целую серию статей, в которых он рассказывает о работе с утилитами командной строки из Windows PowerShell.
Одна из вещей, которая мне не нравится, это то, что при работе с Eseutil вам нужно указывать путь к базе данных, с которой вы собираетесь работать. Это потому, что обычно пути представляют из себя довольно длинные строки, содержащие GUID и другие непростые вещи, которые значительно снижают шансы на их правильный ввод. К счастью, эту проблему можно довольно просто решить с помощью PowerShell. Следующая команда возвращает путь к базе данных Exchange.
Get-MailboxDatabase -Status | select edbfilepath
Команда и ее вывод приведены на следующем рисунке.
Используем PowerShell для подключения и отключения баз данных Exchange
Чаще всего, когда вам приходится работать с Eseutil, это происходит потому, что база данных Exchange не монтируется. Таким образом, если я собираюсь запустить Eseutil для проверки статуса базы, она должна находиться в состоянии «offline». Это достаточно просто сделать из PowerShell. Для этого нужно получить все базы данных Exchangeс помощью командлета Get-MailboxDatabase и передать результаты командлету Dismount-Database.
Get-MailboxDatabase | Dismount-Database –confirm:$false
Запуск вышеприведенной команды отключит все базы данных Exchange. При этом запрос подтверждения выведен не будет – для этого указан параметр -confirm:$false.
Если я хочу подключить все базы данных Exchange, я передам результаты командлету Mount-Database.
Get-MailboxDatabase -Status | Mount-Database
Запускаем Eseutil для каждой базы данных Exchange
Для определения состояния баз данных Exchange мне нужно запустить команду eseutil с параметром/mh. Также нужно указать полный путь к базе данных Exchange. Тут нам опять очень пригодится PowerShell. Мы уже получали путь к базе через PowerShell. Так же я знаю, что он может выполнять повторяющиеся операции. Символ «%» в нижеприведенной команде – это алиас для командлетаForeach-Object. При помощи этой команды я запущу eseutil для каждой их баз данных Exchange.
Get-MailboxDatabase -Status | % { eseutil /mh $_.edbfilepath }
Команда выводит достаточно много информации. Меня же интересует значение поля «State».
Если мне не хочется просматривать весь вывод, я могу отфильтровать результаты с помощью командлета Select-String. Я ищу строку, содержащую слово «State».
[PS] C:>Get-MailboxDatabase -Status | % { eseutil /mh $_.edbfilepath } | Select-String -Pattern «State:»
State: Clean Shutdown
State: Clean Shutdown
[PS] C:>
Подключаем базы почтовых ящиков
Итак, я знаю, что обе мои базы в состоянии «Clean Shutdown» и я смогу их вернуть в состояние «online». Для этого я воспользуюсь следующей командой.
Get-MailboxDatabase –Status | Mount-Database
Так как предыдущая команда не выводит никакой информации, я хочу убедиться, чтоб базы почтовых ящиков действительно подключены. Для этого я использую командлет Get-MailboxDatabase и выберу свойства name и mounted.
[PS] C:>Get-MailboxDatabase -Status | select name, mounted
Name Mounted
—- ——-
Mailbox Database 1301642447 True
Mailbox2 True
[PS] C:>
Итак, это все, что касается Windows PowerShell и Eseutil.