Введение
Сканирование онлайнового обслуживания базы данных включает два основных процесса, а именно контрольное суммирование и обнуление страниц базы данных. Оба этих процесса доступны в 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, чтобы изменения вошли в силу.
Как я говорил ранее, внесение этого изменения означает, что функция контрольного суммирования будет включаться при следующем запуске онлайнового обслуживания. Вы, возможно, помните, что онлайновое обслуживание базы данных можно запланировать на запуск посредством параметров в свойствах базы данных почтового ящика в консоли управления Exchange Management Console. Чтобы найти этот параметр, следуйте этим шагам:
- Запустите консоль Exchange Management Console.
- Перейдите по вкладке Конфигурация сервера в Древе консоли, затем найдите и выберите вкладку Почтовый ящик.
- Убедитесь, что выделен правильный сервер Exchange в Результирующей панели, после чего вы увидите группы хранения и базы данных этого сервера в Рабочей панели.
- Правой клавишей нажмите на соответствующей базе данных и выберите Свойства из контекстного меню.
- В появившемся окне свойств соответствующей базы данных почтового ящика, обратите внимание на опцию График обслуживания: в закладке Общие, как показано на рисунке 2. Она позволяет вам настраивать время запуска онлайнового обслуживания базы данных. У вас есть ряд предустановленных временных промежутков или возможность задать пользовательский график.
Конечно вы также можете использовать оболочку Exchange Management Shell для задания временного окна онлайнового обслуживания. Здесь используется команда Set-MailboxDatabase с параметром ‘MaintenanceSchedule. Если вы не совсем уверены в том, какой формат задать параметру в оболочке Exchange Management Shell, полезным способом определения этой информации будет использование соответствующей команды Get, в этом примере Get-MailboxDatabase, и обработка результатов в команде format-list, используя только нужный вам параметр. К примеру, вы можете использовать следующую команду:
Get-MailboxDatabase | fl MaintenanceSchedule
Примерные результаты этой команды показаны на рисунке 3.
Записи журнала регистрации событий
Существуют новые записи в журнале регистрации событий, которые помогут вам осматривать прогресс функции контрольного суммирования базы данных. Во-первых, когда процесс начинается, регистрируется следующее событие:
Source: ESE
Category: Online Defragmentation
Event ID: 717
Description: Online maintenance is starting the database checksumming background task for database
Пример такого события показан на рисунке 4.
Когда процесс завершен, регистрируется следующее событие:
Source: ESE
Category: Online Defragmentation
Event ID: 721
Description: Online maintenance database checksumming background task is completed for database
После этого поле описания переходит к предоставлению вам аннотации операции, которая включает такую ключевую информацию, как количество увиденных страниц, и все найденные плохие контрольные суммы. Пример такого события показан на рисунке 5. Конечно, это маленькая база данных для тестирования, которую я использую, так как процесс занял всего 12 секунд; производственные базы данных займут гораздо больше времени.
Еще одно событие, связанное с контрольным суммированием базы данных, которое вы можете встретить, это событие 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.
Когда вы включили этот ключ реестра, обратите внимание, что вам не нужно перезагружать сервер или какую-либо службу; просто перезапустите инструмент производительности (Performance tool) и увидите дополнительные счетчики, как показано на рисунке 7.
Резюме
Контрольное суммирование базы данных является важным процессом для запуска в среде Exchange 2007, так как оно может дать вам указатели поврежденных контрольных сумм, которые могут находиться в вашей базе данных. В этой части статьи рассматривалось, как включить данный процесс и на что обращать внимание после его включения. Во второй части мы рассмотрим другой процесс, который вы можете включить при необходимости, процесс обнуления страниц базы данных.