Ноэл М., Спенс К. - Microsoft SharePoint. Полное руководство - 2011

В хранилище управляющих данных имеется простой механизм сбора статистики за какой-то промежуток времени, который позволяет администраторам наблюдать за производительностью и анализировать тенденции в экземплярах SQL Server 2008 R2.

Хранилище управляющих данных — это реляционная база данных внутри экземпляра SQL Server 2008 R2, которая содержит множество различных статистик, относящихся к производительности. Эти статистики собираются с помощью специальных подпрограмм сбора данных, которые называются сборщиками данных (data collector). В хранилище управляющих данных такие данные могут содержаться и для одного, и для нескольких экземпляров SQL Server. Процесс сбора данных зависит от встроенных подпрограмм SSIS и заданий агентов SQL Server, которые уменьшают количество действий, необходимых для создания и сопровождения базы данных, в которой содержатся статистики производительности.

В SQL Server 2008 R2 возможны три различных определения коллекций системных данных. Это Disk Usage (Использование диска). Query Activity (Активность запросов) и Server

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

Сбор коллекций данных можно запускать вручную, по расписанию или выполнять постоянно. Коллекции, собранные при запуске вручную и по расписанию собирают данные и сохраняют их в хранилище управляющих данных примерно одинаково. Эти виды коллекций называются некэшируемыми (noncached) коллекциями. Но при постоянном сборе данных они кэшируются в каталоге и время от времени выгружаются в хранилище управляющих данных. Поэтому они называются кэшируемыми (cached) коллекциями.

Кроме того, компанией Microsoft предусмотрены стандартные отчеты, которые позволяют администраторам анализировать данные в любой из таких коллекций с помощью SQL Server Management Studio.

Для спокойной работы SharePoint с оптимальной производительностью настоятельно рекомендуется, чтобы администраторы выполняли регулярное обслуживание в каждой базе данных SQL Server. К этим задачам обслуживания относятся перестроение индексов, проверка целостности баз данных, обновление статистики индексов, выполнение внутренних проверок согласованности и резервное копирование. Администраторы могут выполнять такие задачи с помощью либо команд Transact-SQL, либо мастера обслуживания баз данных. В данном разделе приведена информация и рекомендации по сопровождению баз данных, которые содержат данные и конфигурации SharePoint. Потом будет рассказано, как автоматизировать и планировать основные задачи сопровождения с помощью создания планов сопровождения баз данных с помощью мастера обслуживания баз данных SQL Server.

Для проверки логической и физической целостности всей баз данных обычно используется команда DBCC CHECKDB.Вообще-то это “супер-команда”, которая выполняет команды CHECKALLOC, CHECKTABLEи CHECKCATALOG.

Ниже приведены рекомендации по использованию команды DBCC CHECKDB:

• Лучше запускать команду DBCC CHECKDB,а не отдельные операции, т.к. она находит большинство ошибок и обычно безопасно выполняется в производственной среде.

• После выполнения команды DBCC CHECKDBее следует запустить снова с аргументом REPAIR,который выполняет исправление всех обнаруженных ошибок.

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

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

Индексы ускоряют выполнение запросов, однако потребляют дополнительные ресурсы: они занимают дисковую память и требуют дополнительного времени на их изменение при любом изменении, удалении или вставке данных.

Часть ll

При первоначальном создании индексов фрагментации нет или почти нет. Но со временем при выполнении вставки, изменения и удаления данных уровень фрагментации индексов может увеличиться.

Когда страница индекса полностью заполнена и требуется записать новые данных, эта страница разбивается на части. Чтобы выделить место под новые данные, SQL Server создает где-то в базе данных новую страницу (не обязательно рядом с предыдущей) и перемещает в нее часть данных из заполненной страницы. В результате логически последовательные блоки данных физически могут оказаться разбросанными на диске. И при поиске данных SQL Server вынужден перескакивать с одной страницы на далеко расположенную другую, вместо того чтобы выполнять последовательное чтение. В результате ухудшается производительность и использование дисковой памяти.