Сканирование онлайнового обслуживания базы данных включает два основных процесса, а именно контрольное суммирование и обнуление страниц базы данных. Оба этих процесса доступны в RTM версии Exchange 2007, и хотя они также доступны в SP 1 версии Exchange 2007, они подверглись некоторым изменениям, о которых я расскажу в двух частях этой серии статей. Помимо рассмотрения того, что собой представляют эти изменения, мы также рассмотрим, как активировать эти функции, а также как контролировать их прогресс посредством записей в журнале регистрации событий, которые они создают. Существуют также некоторые импликации производительности, о которых вам тоже нужно знать.
В первой части этой серии статей мы рассмотрим процесс контрольного суммирования базы данных, а во второй части мы уделим внимание процессу обнуления страниц базы данных. Итак, давайте перейдем к процессу контрольного суммирования (checksumming).
Контрольное суммирование базы данных
Контрольное суммирование просто осуществляет проверку целостности базы данных. Если вы использовали предыдущие версии Exchange, вы, вероятно, помните, что существует два ключевых момента, возникающих во время резервного копирования онлайновых потоков баз данных:
- Логи транзакций баз данных переполняются.
- Осуществляются проверки целостности.
Одной из классических ошибок, которая вселяла страх в администраторов Exchange в течение нескольких лет, была ужасная ошибка -1018 error, которая помещалась в журнал регистрации событий проверками целостности во время потокового резервного копирования. Эти процессы потокового резервного копирования и проверки целостности продолжали возникать и в версии Exchange 2007 RTM, но конечно с появлением службы Volume Shadow Copy Service (VSS) резервного копирования в Exchange 2007, связанной с визуальной блокировкой интерфейса потокового резервного копирования, осуществление контрольного суммирования стало проблемой. Почему так? Ответ тому кроется в использовании технологий высокой доступности Exchange 2007, таких как непрерывная кластерная репликация (Clustered Continuous Replication – CCR). Как вы, возможно, предполагали, многие организации применили такие технологии, как CCR, в качестве стратегии высокой доступности и, как вы, несомненно, знаете, эта технология обеспечивает избыточность данных в форме пассивных копий баз данных. Одно из ключевых преимуществ таких технологий, как CCR, заключается в том, что резервное копирование VSS можно настроить так, чтобы оно возникало на пассивных копиях баз данных. Это очень хорошо для производительности, так как процесс резервного копирования не влияет на активные копии, а, следовательно, не влияет непосредственно на пользователей, которые их используют. Однако проблема заключается в том, что в таком сценарии проверки целостности не осуществляются для активных копий.
Чтобы справиться с этой проблемой, организациям приходилось либо выводить свои базы данных в автономный режим и вручную запускать утилиту ESEUTIL, либо перемещать кластерный почтовый сервер (CMS) между узлами кластера на регулярной основе, беря тем самым резервные копии с различных узлов. Конечно, ни один из этих сценариев не является идеальным решением.
Для решения данной конкретной проблемы компания Microsoft сделала процесс контрольного суммирования доступным во время онлайнового обслуживания в Exchange 2007 SP1. На тот случай, если вы не знали, онлайновое обслуживание выполняет ряд очень важных задач, чтобы убедиться в том, что ваши базы данных работают корректно и эффективно. Эти задачи включают такие области, как очистку корзины, чистку удаленных почтовых ящиков и осуществляют онлайновую дефрагментацию. Мы рассмотрим изменение окна времени онлайнового обслуживания через некоторое время.
Включение контрольного суммирования базы данных
Сначала, вам нужно знать, что нужно делать, чтобы активировать процесс контрольного суммирования активных баз данных, так как он не включен по умолчанию; представители Microsoft сделали его функцией по выбору. Для включения этого процесса потребуется внести изменения в системный реестр. Перечисленные ниже подключи системного реестра не будут существовать по умолчанию, поэтому их нужно создать. Нужно внести следующие изменения:
Ключ: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystemName: Online Maintenance Checksum Тип: DWORD Значение: 1
Скриншот того, как должно выглядеть это значение, показан на рисунке 1. Как только вы внесли изменения в системный реестр, вам нужно будет перезапустить службу Microsoft Exchange Information Store, чтобы изменения вошли в силу.
Рисунок 1: Ключ системного реестра для контрольного суммирования
Как я говорил ранее, внесение этого изменения означает, что функция контрольного суммирования будет включаться при следующем запуске онлайнового обслуживания. Вы, возможно, помните, что онлайновое обслуживание базы данных можно запланировать на запуск посредством параметров в свойствах базы данных почтового ящика в консоли управления Exchange Management Console. Чтобы найти этот параметр, следуйте этим шагам:
- Запустите консоль Exchange Management Console.
- Перейдите по вкладке Конфигурация сервера в Древе консоли, затем найдите и выберите вкладку Почтовый ящик.
- Убедитесь, что выделен правильный сервер Exchange в Результирующей панели, после чего вы увидите группы хранения и базы данных этого сервера в Рабочей панели.
- Правой клавишей нажмите на соответствующей базе данных и выберите Свойства из контекстного меню.
- В появившемся окне свойств соответствующей базы данных почтового ящика, обратите внимание на опцию График обслуживания: в закладке Общие, как показано на рисунке 2. Она позволяет вам настраивать время запуска онлайнового обслуживания базы данных. У вас есть ряд предустановленных временных промежутков или возможность задать пользовательский график.
Рисунок 2: График онлайнового обслуживания
Конечно вы также можете использовать оболочку Exchange Management Shell для задания временного окна онлайнового обслуживания. Здесь используется команда Set-MailboxDatabase с параметром ‘MaintenanceSchedule. Если вы не совсем уверены в том, какой формат задать параметру в оболочке Exchange Management Shell, полезным способом определения этой информации будет использование соответствующей команды Get, в этом примере Get-MailboxDatabase, и обработка результатов в команде format-list, используя только нужный вам параметр. К примеру, вы можете использовать следующую команду:
Get-MailboxDatabase | fl MaintenanceSchedule
Примерные результаты этой команды показаны на рисунке 3.
Рисунок 3: Команда Get-MailboxDatabase
Записи журнала регистрации событий
Существуют новые записи в журнале регистрации событий, которые помогут вам осматривать прогресс функции контрольного суммирования базы данных. Во-первых, когда процесс начинается, регистрируется следующее событие:
Source: ESE Category: Online Defragmentation Event ID: 717 Description: Online maintenance is starting the database checksumming background task for database <database name>.
Пример такого события показан на рисунке 4.
Рисунок 4: Событие 717
Когда процесс завершен, регистрируется следующее событие:
Source: ESE Category: Online Defragmentation Event ID: 721 Description: Online maintenance database checksumming background task is completed for database <database name>. This pass started on <date> and ran for a total of <n> seconds, requiring <n> invocations over <n> days.
После этого поле описания переходит к предоставлению вам аннотации операции, которая включает такую ключевую информацию, как количество увиденных страниц, и все найденные плохие контрольные суммы. Пример такого события показан на рисунке 5. Конечно, это маленькая база данных для тестирования, которую я использую, так как процесс занял всего 12 секунд; производственные базы данных займут гораздо больше времени.
Рисунок 5: Событие 721
Еще одно событие, связанное с контрольным суммированием базы данных, которое вы можете встретить, это событие 723, которое возникает в том случае, если в процессе проверки обнаруживаются ошибки.
Воздействие на производительность
Однако прежде чем вы броситесь активировать функцию контрольного суммирования базы данных, всегда важно понимать любые возможные воздействия на производительность. К счастью, этот процесс не имеет большого воздействия на пользователей. Это потому, что, как следует из информации, предоставленной компанией Microsoft на ИТ форуме TechEd в ноябре 2007, внедрение контрольного суммирования показало небольшое увеличение в % счетчика времени процессора (Processor Time counter), а показания счетчика RPC Averaged Latency counter увеличились всего примерно на 10ms.
Учитывая это, все же будет благоразумным вести мониторинг процесса, если вы используете его в своей среде, а чтобы сделать это возможным, компания Microsoft предоставляет вам дополнительные счетчики производительности. Эти счетчики в основном говорят вам о том, сколько страниц базы данных читается в секунду:
- MSExchangeDatabase\Online Maintenance (DB Scan) Pages Read/sec.
- MSExchangeDatabase==>Instances\Online Maintenance (DB Scan) Pages Read/sec
Однако, чтобы видеть эти счетчики в инструменте производительности, вам нужно включить расширенные счетчики производительности Extensible Storage Engine (ESE). Для этого потребуется внести очередные изменения в системный реестр:
Ключ: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ESE\PerformanceName: Show Advanced Counters Тип: DWORD Значение: 1
Эта конфигурация реестра показана на рисунке 6.
Рисунок 6: Конфигурация реестра для расширенного счетчика
Когда вы включили этот ключ реестра, обратите внимание, что вам не нужно перезагружать сервер или какую-либо службу; просто перезапустите инструмент производительности (Performance tool) и увидите дополнительные счетчики, как показано на рисунке 7.
Рисунок 7: Дополнительные счетчики производительности
Резюме
Контрольное суммирование базы данных является важным процессом для запуска в среде Exchange 2007, так как оно может дать вам указатели поврежденных контрольных сумм, которые могут находиться в вашей базе данных. В этой части статьи рассматривалось, как включить данный процесс и на что обращать внимание после его включения. Во второй части мы рассмотрим другой процесс, который вы можете включить при необходимости, процесс обнуления страниц базы данных.
В первой части этой серии статей мы узнали об основных двух процессах, из которых состоит сканирование онлайнового обслуживания баз данных, это процессы контрольного суммирования и обнуления страниц баз данных. Затем мы более подробно рассмотрели процесс контрольного суммирования, что он собой представляет, как он работает, как включить его, а также рассмотрели информацию журналов регистрации событий, которую он производит, чтобы можно было отслеживать его прогресс.
В этой второй и заключительной части мы рассмотрим ту же информацию о процессе обнуления страниц баз данных, а в конце затронем некоторую информацию производительности, связанную с этими процессами. Итак, давайте продолжим и посмотрим, что предлагает нам процесс обнуления страниц баз данных (БД), и как его включать, если это необходимо.
Обнуление страниц баз данных (БД)
Функция обнуления страниц БД присутствовала и в предыдущих версиях Exchange, и, возможно, вы сталкивались с ней, когда работали с Exchange еще до того, как Exchange 2007 был выпущен. Обнуление страниц представляет собой дополнительную функцию безопасности, которую можно использовать, чтобы сделать данные БД Exchange невозвратимыми, или, как говорят представители компании Microsoft, «данные невозвратимы конвенциональным способом». Это осуществляется путем переписывания неиспользуемых страниц баз данных нулями. Что подразумевается под неиспользуемыми страницами? Это страницы, которые ранее содержали данные, но эти данные теперь удалены, как в случае, когда пользователь удаляет ненужные сообщения из своего почтового ящика. Конечно, эти страницы БД не будут отмечены, как неиспользуемые до тех пор, пока не пройдут дополнительные сроки сохранности, как в случае с сроком сохранности удаленных объектов, который позволяет пользователям восстанавливать сообщения, которые они прежде удалили. Общеизвестно, что функция обнуления БД, как правило, используется только в тех организациях, которые нуждаются в более высоком уровне безопасности своей почтовой инфраструктуры, но если вы решили, что эта функция подходит для вашей организации, то продолжайте читать.
Хотя функция обнуления БД была доступна в RTM версии Exchange 2007, в версии SP1 теперь можно выполнять обнуление страниц во время онлайнового обслуживания. Вы можете поинтересоваться, почему это так важно. Если вы прочитали первую часть этой серии статей, то возможно вы помните, что процесс контрольного суммирования баз данных имел определенные проблемы, когда использовался совместно с такими технологиями непрерывной репликации, как Clustered Continuous Replication (CCR) в Exchange 2007 RTM. Функция обнуления БД также имеет определенные ограничения, когда используется с такими технологиями высокой доступности, как локальная непрерывная репликация (Local Continuous Replication – LCR) или CCR в инфраструктуре Exchange 2007 RTM. Проблема заключается в том, что изменения обнуления, сделанные на активной копии БД, не копируются на пассивную базу данных, используемую с LCR или CCR. Чтобы разрешить эту проблему, организациям приходилось либо отключать базы данных и вручную запускать утилиту ESEUTIL, или выполнять потоковое резервное копирование активной и пассивной копии БД. Как и в случае с контрольным суммированием, эти варианты далеки от совершенства. Для решения этой проблемы компания Microsoft сделала в Exchange 2007 SP1 так, что изменения могут копироваться с помощью технологий непрерывной репликации. Также при использовании LCR или CCR совместно с Volume Shadow Copy Service (VSS) резервными копиями процесс обнуления не мог применяться в Exchange 2007 RTM, поскольку он подходит только для потоковых резервных копий. Сделав процесс обнуления страниц частью онлайнового обслуживания, проблема была разрешена.
Включение обнуления страниц БД
Включение функции обнуления страниц БД, так же как и функции контрольного суммирования БД, требует внесения изменений в системный реестр, поскольку это опциональная функция. Этот подключ реестра не будет существовать по умолчанию на сервере Exchange 2007, поэтому его необходимо создать. Нужно внести следующее изменение:
Ключ: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem Имя: Zero Database Changes During Checksum Тип: DWORD Значение: 1
Фотография того, как должно выглядеть значение системного реестра, показана на рисунке 8. Как и в случае с ключом реестра контрольного суммирования, когда вы осуществили изменения реестра, вам нужно перезапустить службу Microsoft Exchange Information Store, чтобы изменения вступили в силу.
Рисунок 8: Ключ реестра для обнуления страниц БД
Записи журнала регистрации событий
Есть новые записи в логах, которые помогут вам обследовать прогресс функции обнуления страниц БД, как и в случае с контрольным суммированием. Сначала, когда процесс обнуления страниц запускается, регистрируется следующее событие:
Source: ESECategory: Online DefragmentationEvent ID: 718Description: Online maintenance is starting the database page zeroing background task for database <database name>.
Пример этого события показан на рисунке 9.
Рисунок 9: Событие 718
Когда процесс завершен, регистрируется следующее событие:
Source: ESECategory: Online DefragmentationEvent ID: 722
Description: Online maintenance database zeroing background task has completed for database <database name>. This pass started on <DATE> and ran for a total of <N> seconds, requiring <N> invocations over <N> days.
Поле описания продолжает предоставлять вам аннотацию работы, которая включает такую ключевую информацию, как количество прочитанных и обнуленных страниц. Пример такого события показан на рисунке 10. Обратите внимание, что я пролистал поле описания вниз, чтобы показать вам аннотацию работы полностью.
Рисунок 10: Событие 722
Два других события, с которыми вы можете столкнуться в журнале обнуления страниц, это событие 724, которое регистрируется в случае обнаружения ошибок во время процесса, и событие 729, которое регистрируется, когда процесс был приостановлен.
Воздействие на производительность
Как я говорил в первой части этой серии статей, нужно время, чтобы осознать воздействие на производительность при включении функции обнуления страниц, прежде чем применять ее. Если говорить конкретно, вы должны осознать, что применение этой функции на существующую большую базу данных, которая использовалась на протяжении некоторого времени, может отрицательно сказаться на производительности сервера. Это может быть следствием наличия большого количества неиспользованных страниц, которые необходимо обнулить, для чего, конечно же, потребуется определенное время и усилия, в результате значительно повысится обмен данными на диске. Гораздо разумнее будет включить функцию обнуления страниц, когда создается новая БД, поскольку усилия на обнуление всех неиспользуемых страниц будут значительно меньше. Этот процесс также может удвоить (а то и утроить) журнал регистрации транзакций, пока первый запуск будет доведен до конца. Конечно, когда первый запуск процесса будет завершен, все вернется в норму относительно генерирования логов транзакций.
Как говорится в информации, представленной компанией Microsoft на форуме TechEd IT в ноябре 2007, использование обнуления страниц привело к незначительному увеличению показателей счетчика % Временного процессора, а показания счетчика RPC Averaged Latency увеличились приблизительно на 20мс. Таким образом, обнуление страниц БД лучше использовать в то время, когда ваши пользователи менее всего пользуются почтовой инфраструктурой.
Как и в случае с контрольным суммированием, компания Microsoft предоставляет счетчики производительности для мониторинга процесса обнуления страниц БД. Это счетчики:
- MSExchangeDatabase\Online Maintenance (DB Scan) Pages Read/sec
- MSExchangeDatabase==>Instances\Online Maintenance (DB Scan) Pages Read/sec
Чтобы видеть эти счетчики, опять же, нужно включить расширенные счетчики производительности Extensible Storage Engine (ESE), как это делалось для процесса контрольного суммирования. Для подробного описания того, как это сделать, обратитесь к первой части этой серии статей.
Резюме
В двух частях этой серии статей мы рассмотрели процессы контрольного суммирования и обнуления страниц БД, подробно разбирая, что собой представляют эти процессы и как их включить в качестве части онлайнового обслуживания. В то время как процесс контрольного суммирования БД может быть очень полезным дополнением онлайнового обслуживания, процесс обнуления страниц БД может подойти не для всех организаций.