Доступны два выпуска сервера Exchange 2010: Standard Edition и Enterprise Edition. Выпуск Exchange 2010 Standard Edition предназначен для удовлетворения потребностей в области обмена сообщениями и совместной работы малых и средних предприятий. Он также подходит для определенных ролей сервера или использования в филиалах. Exchange 2010 Enterprise Edition предназначен для использования на крупных предприятиях.

Выпуск Exchange 2010 Standard Edition поддерживает до пяти баз данных. Выпуск Exchange 2010 Enterprise Edition поддерживает до 100 баз данных.

#RTT

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Внимание!
При восстановлении базы данных некоторые данные будут утрачены. Потери данных часто минимальны, но в некоторых случаях они могут быть разрушительными. После выполнения команды Eseutil /p в базе данных необходимо также выполнить команду Eseutil/ d для дефрагментации базы данных. Эта операция удаляет и повторно создает все индексы базы данных и деревья пространства.

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

#RTT

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

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

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

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

#RTT

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

Изоляция подозрительного почтового ящика

Действия над подозрительным почтовым ящиком

Сброс карантина почтового ящика

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

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

Время сброса карантина почтовых ящиков можно установить в разделе реестра HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Имя_сервера>\Private-{идентификатор_guid_базы_данных}\QuarantinedMailboxes\MailboxQuarantineDurationInSeconds.

Отчеты и оповещения

В системе Exchange 2010 с пакетом обновления 1 (SP1) для обнаружения и устранения повреждений почтовых ящиков используется командлет New-MailboxRepairRequest. Этот командлет можно выполнять для отдельного почтового ящика или базы данных почтовых ящиков. Во время выполнения этой задачи доступ к исправляемому почтовому ящику прерывается. При запуске командлета для базы данных почтовых ящиков недоступен будет только исправляемый почтовый ящик. Все другие почтовые ящики в базе данных продолжают работать. Дополнительные сведения см. в разделе Создание запроса на восстановление почтового ящика.

Командлет New-MailboxRepairRequest определяет и исправляет следующие типы повреждений почтовых ящиков.

• Повреждения папки поиска (с помощью значения SearchFolder параметра CorruptionType)
  
  
• Статистические счетчики в папках, не отражающие правильные значения (с помощью значения AggregateCounts параметра CorruptionType)
  
  
• Представления папок, не возвращающие правильное содержимое (с помощью значения FolderView параметра CorruptionType)
  
  
• Подготовленные папки, неправильно указывающие на неподготовленные родительские папки (с помощью значения ProvisionedFolder параметра CorruptionType)
  
  

После выполнения командлета New-MailboxRepairRequest можно просмотреть дополнительные сведения о запросе в окне «Просмотр событий». Дополнительные сведения см. в разделе Просмотр запросов на восстановление почтовых ящиков в окне просмотра событий.

Также можно использовать командлет New-PublicFolderDatabaseRepairRequest для определения и устранения неполадок репликации в базе данных общедоступных папок. В ходе выполнения запроса общедоступные папки в базе данных остаются доступными. Исключение составляет восстанавливаемая в текущий момент общедоступная папка. Дополнительные сведения см. в разделе Создание запроса на восстановление базы данных общедоступной папки.

#RTT

Другим признаком неисправности хранилища Exchange является взаимоблокировка или бездействие потоков. Если более пяти потоков отдельного почтового ящика, десяти потоков отдельной базы данных или двадцати потоков отдельного сервера остаются бездействующими в течение одной минуты, на сервере регистрируется истечение времени ожидания. Счетчик производительности, в котором хранятся сведения об истечении времени ожидания, называется «В банке данных MSExchangeIS истекло время ожидания запроса RPC».

Хранилище Exchange также выполняет на сервере запись следующих событий:

• 10025 — истечение времени ожидания на сервере Exchange
  
  
• 10026 — истечение времени ожидания в базе данных
  
  
• 10027 — истечение времени ожидания в отдельном почтовом ящике.
  
  

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

#RTT