Основные сведения об обслуживании базы данных
Применимо к: Exchange Server 2010 SP3
Последнее изменение раздела: 2016-11-28
Архитектурные изменения, которые были сделаны в ядре СУБД в Microsoft Exchange Server 2010, значительно повысили его производительность и надежность. Однако эти архитектурные изменения также изменили поведение задач обслуживания базы данных по сравнению с предыдущими версиями Exchange Server. Эта тема описывает задачи обслуживания базы данных, которые должны выполняться на регулярной основе над базами данных Exchange Server 2010.
Совокупность задач, описанных в данной теме, известна как фоновое обслуживание базы данных.
Сжатие базы данных
Сжатие базы данных должно быть выполнено для того, чтобы освободить неиспользованное пространство в файле базы данных. Сжатие базы данных не возвращает это неиспользованное пространство файловой системе. Вместо этого оно освобождает страницы в базе данных, сжимая записи в наименьшее количество страниц, и сокращает операции ввода-вывода, необходимые для доступа к страницам. Для выполнения этой операции ядро СУБД обработчика ESE использует метаданные базы данных, которые являются информацией, описывающей таблицы в базе данных. Для каждой таблицы ядро СУБД обработчика ESE проверяет каждую страницу в таблице и старается переместить записи на страницы, расположенные в логическом порядке.
Сжатие базы данных очень важно, потому что оно сокращает время, связанное с резервным копированием файла базы данных, и помогает поддерживать прогнозируемый размер файла базы данных. Это важно для точного определения размера сервера/хранилища.
Процесс сжатия базы данных был изменен в Exchange Server 2010. Самое главное, операция теперь отдает предпочтение непрерывности данных перед степенью сжатия. Предыдущие версии Exchange Server были более сфокусированы на сжатии пространства. Это приводило к тому, что страницы всегда оставались в произвольном порядке после того, как процесс реорганизовывал записи в свободном пространстве на страницах. В сочетании с архитектурой схемы хранилища эта произвольная реорганизация значила, что любой запрос на извлечение набора данных (например, загрузка элементов внутри папки) всегда заканчивался произвольным вводом-выводом. В Exchange Server 2010 произвольный ввод-вывод снижен благодаря тому, что записи сохраняются на страницах по порядку.
Кроме того, в предыдущих версиях Exchange Server операции сжатия базы данных производились во время периода обслуживания. В Exchange 2010 процесс сжатия базы данных является фоновым и проводится постоянно.
Дефрагментация базы данных
Дефрагментация базы данных (также известная как дефрагментация OLD v2 и дерева B+) — новая задача обслуживания в Exchange Server 2010. Дефрагментация базы данных важна для поддержки эффективного использования ресурсов диска на протяжении длительного времени (например, сделать операции ввода-вывода более последовательными, вместо произвольных) и для поддержки компактности таблиц, отмеченных как последовательные.
Дефрагментация базы данных является фоновым процессом, который постоянно анализирует базу данных по мере выполнения операций и затем активирует асинхронную работу, когда это необходимо. Этот процесс отслеживает все таблицы в поиске свободных страниц. Если таблица достигает порога, при котором высокий процент числа страниц всего дерева B+ свободен, свободные страницы возвращаются к корню. Этот процесс также работает на поддержание непрерывности по всему набору таблиц с помощью советов по последовательным пространствам (таблица, созданная по известному образцу последовательного использования). Если при дефрагментации базы данных записи не сохраняются на последовательных страницах в последовательной таблице, на которой обнаруживается отметка о сканировании/предварительном прочтении, процесс дефрагментирует этот участок таблицы, перемещая все затронутые страницы в новую область памяти дерева B+. Вы можете использовать счетчики производительности, чтобы увидеть нижний уровень активной работы, выполняемой процессом дефрагментации базы данных, после достижения устойчивого состояния.
Процесс дефрагментации базы данных имеет следующие элементы управления для регулировки выполнения задач:
Максимальное количество задач, ожидающих выполнения Это предотвращает выполнение процессом дефрагментации большого количества работы во время первого прохода, если в базу данных внесли очень большое количество изменений.
Регулирование задержки 100 мс Если система перегружена, дефрагментация базы данных отложит работу по дефрагментации. Отложенная работа будет завершена в следующий раз, когда база данных будет следовать тому же операционному шаблону и система будет иметь больше ресурсов.
Оперативное сканирование базы данных (проверка контрольных сумм базы данных)
Сканирование оперативной базы данных (также известное как проверка контрольных сумм базы данных) — это процесс, посредством которого база данных читается большими блоками, а каждая страница проверяется на физическое повреждение. Основная цель проверки контрольных сумм базы данных — определить физическое повреждение и потерянные записи на диск, которые могут быть не определены транзактными операциями (устаревшие страницы).
.gif "Примечание") Примечание. |
|---|
| В Exchange Server 2007 и предыдущих версиях операции проверки контрольных сумм базы данных проводились во время процесса резервного копирования. Однако это вызывало проблемы в реплицированных базах данных, потому что проверка контрольных сумм выполнялась только для резервной копии. Если была сделана резервная копия пассивной копии, проверка контрольных сумм активной копии не проводилась. Чтобы решить эту проблему, в пакет обновления 1 (SP1) для Exchange Server 2007 была добавлена новая необязательная задача обслуживания, названная "проверка контрольных сумм оперативного обслуживания". Для получения дополнительной информации см. раздел Как настроить сканирование при оперативном обслуживании базы данных в пакетах обновления 1 и 2 для Exchange 2007. |
В Exchange 2010 сканирование оперативной базы данных заключается в проверке контрольных сумм базы данных и в выполнении операций после сбоя хранилища Exchange 2010. Сбои могут привести к утечке пространства. Операция сканирования оперативной базы данных находит и восстанавливает потерянное пространство. Система в Exchange 2010 разработана с учетом того, что каждая база данных полностью проверяется один раз каждые семь дней. Если проверка базы данных не выполнена полностью в этот промежуток времени, выдается предупреждение. Сейчас в Exchange 2010 доступно два режима запуска сканирования баз данных для активных копий базы данных:
Выполнение последней задачи в запланированной процедуре обслуживания баз данных почтовых ящиков: Можно настроить продолжительность ее выполнения, изменив расписание обслуживания баз данных почтовых ящиков. Данный вариант отлично подходит для небольших баз данных, имеющих размер менее 1 ТБ, полная проверка которых требует меньше времени.
Круглосуточное выполнение поведения по умолчанию в фоновом режиме: Этот вариант подходит для всех случаев, но мы рекомендуем его для баз данных больших размеров (1–2 ТБ). Exchange проверяет базу данных не чаще одного раза в день. Данная операция ввода-вывода полностью последовательна (поэтому легко обрабатывается диском), и на большинстве систем скорость проверки контрольных сумм осуществляется со скоростью около 5 МБ/с.
| Примечание. |
|---|
|
Восстановление страницы
Функция восстановления страниц заменяет поврежденные страницы исправными копиями. Обнаружение поврежденных страниц — это функция проверки контрольных сумм базы данных. Кроме того, поврежденные страницы определяются во время работы, когда страница сохраняется в кэш базы данных. Функция восстановления страниц работает с копиями баз данных высокого уровня доступности. Способ восстановления поврежденной страницы зависит от того, является база данных высокой доступности активной или пассивной.
Процесс восстановления страницы в активных копиях базы данных
Обнаружены поврежденные страницы.
В активный файл журнала записывается метка. Эта метка указывает номер поврежденной страницы. Она также указывает, что эта страница требует замены.
В список запросов на восстановление страницы добавляется запись.
Активный файл журнала закрывается.
Служба репликации отправляет файл журнала в пассивные копии базы данных.
Служба репликации на целевом сервере почтовых ящиков получает отправленный файл журнала и проверяет его.
Банк данных на целевом сервере воспроизводит файл журнала до метки, получает свою исправную копию страницы, вызывает ответ службы преобразования, а затем передает страницу исходному серверу почтовых ящиков.
Исходный сервер почтовых ящиков получает исправную версию страницы, подтверждает существующую запись в списке запросов на исправление страницы, а затем записывает страницу в буфер журнала. Соответственно, страница вставляется в кэш базы данных.
Соответствующая запись в списке запросов на исправление страницы удаляется.
На этом этапе база данных считается исправленной. (Через некоторое время контрольная точка продвинется, кэш базы данных будет сброшен на диск, а поврежденная страница на диске будет заменена.)
Любая другая копия этой страницы (полученная из другой пассивной копии) будет удалена по умолчанию. Это происходит потому, что в списке запросов на восстановление страницы отсутствует соответствующая запись.
Процесс восстановления страницы в пассивных копиях базы данных
На сервере почтовых ящиков, на котором обнаружены поврежденные страницы, воспроизведение журнала приостанавливается для затронутой копии базы данных.
Служба репликации координируется с сервером почтовых ящиков, на котором размещена активная копия базы данных, и извлекает поврежденные страницы и необходимый диапазон журнала из заголовка активной копии базы данных.
Сервер почтовых ящиков обновляет заголовок базы данных для затронутой копии базы данных и вставляет новый необходимый диапазон журнала.
Этот сервер почтовых ящиков уведомляет сервер почтовых ящиков, на котором расположена активная копия базы данных о том, какие файлы журнала ему необходимы.
Сервер почтовых ящиков получает необходимые файлы журнала и проверяет их.
Затем сервер почтовых ящиков вставляет исправные версии страниц базы данных, которые он получил из активной копии базы данных. Страницы записываются в буфер журнала. Соответственно, страница вставляется в кэш базы данных.
Сервер почтовых ящиков возобновляет воспроизведение журнала.
Обнуление страниц
Обнуление страниц базы данных является мерой безопасности, с помощью которой удаленные страницы в базе данных заменяются шаблоном (обнуленным). Это сильно усложняет обнаружение данных.
В Exchange Server 2007 и предыдущих версиях операции обнуления страницы происходят во время процесса потокового резервного копирования. Так как обнуление происходит во время потокового процесса резервного копирования, оно не приводит к созданию файлов журнала. Это создает проблему для реплицированных баз данных, потому что в пассивных копиях страницы никогда не обнуляются. Кроме того, в активных копиях страницы обнуляются в том случае, если потоковое резервное копирование завершено. Чтобы решить эту проблему, в пакете обновления 1 для Exchange Server 2007 мы реализовали новую необязательную задачу обслуживания: обнуление страниц базы данных во время проверки контрольной суммы. При включенном обнулении страниц базы данных во время проверки контрольной суммы эта задача обнуляет страницы во время обслуживания, а затем вносит изменения в журнал. Затем изменения реплицируются на пассивные копии.
Однако в реализации пакета обновления 1 для Exchange Server 2007 процесс обнуления происходит во время запланированного обслуживания. Это создает задержку между временем, в которое страница удаляется, и временем, когда она обнуляется. Тем не менее, задача обнуления страницы становится событием среды, которое выполняется постоянно для Exchange Server 2010 SP1. В данное время задача обычно обнуляет страницы во время транзакции, при которой происходит удаление без восстановления.
Кроме того, страницы базы данных могут быть очищены в процессе оперативной проверки контрольной суммы. Целевыми страницами в данном случае являются следующие:
Удаленные записи, которые не могут быть восстановлены во время выполнения из-за пропущенных задач (если система слишком перегружена) или из-за сбоя хранилища до того, как задачи очистят данные.
Удаленные таблицы и дополнительные индексы. Когда они удаляются, их содержимое не очищается. Однако оперативная проверка контрольной суммы определяет, что эти страницы больше не принадлежат допустимым объектам, и очищает страницы.
Дополнительные сведения об обнулении страниц в Exchange Server 2010 см. в разделе Общие сведения об обнулении страниц Exchange 2010.
Используйте счетчики производительности для отслеживания задач фонового обслуживания
В Exchange Server 2010 события не записываются для таких задач обслуживания, как дефрагментация и сжатие. Однако вы можете использовать счетчики производительности для отслеживания задач фонового обслуживания. Следующая таблица описывает счетчики производительности, которые необходимо использовать в объекте MSExchange Database ==> Instances.
| Счетчик | Описание |
|---|---|
Продолжительность обслуживания базы данных |
Время (в секундах), которое прошло с завершения последнего обслуживания для этой базы данных. Если значение равно 0, обслуживание завершено на этот день. |
Неверные контрольные суммы страниц при обслуживании базы данных |
Количество неверных контрольных сумм страниц, обнаруженных при выполнении обслуживания базы данных |
Задачи дефрагментации |
Число выполняемых в настоящий момент фоновых задач дефрагментации базы данных |
Выполненных задач дефрагментации/с |
Скорость завершения фоновых задач дефрагментации базы данных |
Следующая таблица описывает счетчики обнуления страниц, которые необходимо использовать в объекте MSExchange Database:
| Счетчик | Описание |
|---|---|
Обнуленные страницы обслуживания базы данных |
Указывает число страниц, обнуленных ядром СУБД с момента вызова счетчика производительности |
Обнулено страниц при обслуживании базы данных/с |
Указывает скорость, с которой страницы обнуляются ядром СУБД |
Свободное пространство
В базе данных вы можете иметь тысячи таблиц. Вы можете иметь как минимум одну таблицу для каждой папки в каждом почтовом ящике. Таблицы сообщений, таблицы папок и таблицы приложений занимают 90 процентов пространства, используемого базой данных. Эти таблицы имеют наибольший процент пустого пространства (также известного как свободное пространство) в базе данных.
Чтобы определить объем свободного пространства в базе данных и использовать это свободное место, выполните следующие действия:
Отключите базу данных.
Выполните дамп пространства с помощью инструментов служебных программ Exchange Server для баз данных (Eseutil) с параметром /MS. Дополнительные сведения о том, как это сделать, см. в статье How to Run Eseutil /M in File Dump Mode (Как запустить Eseutil /M в режиме дампа файла).
В конце файла дампа находится приблизительно такая строка:
-----------------------------------------------------------------------
253Это сумма всего количества страниц, доступных во всех таблицах. Чтобы определить истинный размер свободного пространства в базе данных, умножьте это количество на 32 КБ.
| Примечание. |
|---|
| Пример файла дампа Eseutil см. в статье Determining the True Amount of Space in an Exchange Database (Определение истинного размера пространства в базе данных Exchange). |
После определения размера свободного места в базе данных вы, возможно, захотите использовать это свободное пространство.
Если вы имеете дело с базой данных, которая располагает значительным количеством свободного пространства, и не ожидаете, что типичные операции затребуют это пространство, мы рекомендуем выполнить следующие действия:
Создайте новую базу данных и связанные с ней копии базы данных.
Переместите все почтовые ящики в новую базу данных.
Удалите исходную базу данных и связанные с ней копии базы данных.
© Корпорация Майкрософт (Microsoft Corporation), 2010. Все права защищены.