Обслуживание баз данных для продуктов Microsoft® SharePoint® 2010 (стр. 4 )

Важно! Продукт SQL Server 2000 поддерживал использование команд DBCC DBREINDEX и DBCC INDEXDEFRAG для обслуживания индексов. Эти команды были отмечены как устаревшие, начиная с SQL Server 2005, и будут удалены в последующей версии SQL Server. Не используйте эти команды для выполнения обслуживания индекса базы данных SharePoint 2010.

Примечание. Когда перестроение индекса выполняется с отключением от сети, для таблицы используется совмещаемая блокировка, которая предотвращает выполнение всех операций, кроме SELECT. Базы данных SharePoint 2010 используют кластеризованные индексы специфически. Когда перестроение кластеризованного индекса выполняется вне сети, к таблице применяется монопольная блокировка, которая предотвращает доступ к этой таблице пользователей.

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

USE Contoso_Content_1 GO ALTER INDEX ALL ON [имя_базы_данных. [ имя_схемы ] . | имя_схемы. ]имя_таблицы_или_представления REBUILD WITH (FILLFACTOR = 80, SORT_IN_TEMPDB = ON, STATISTICS_NORECOMPUTE = ON) GO

Точная настройка производительности индекса с помощью установки коэффициента заполнения

Коэффициент заполнения можно использовать для дальнейшего улучшения условий хранения и производительности данных индекса. При создании или перестроении индексов значение коэффициента заполнения (1–100) в процентах определяет место на каждой странице конечного уровня, которое может быть заполнено данными. Оставшееся место резервируется для использования в будущем. Во многих ситуациях рационально по умолчанию использовать нулевое значение коэффициента заполнения для всего сервера (что означает 100%-ное заполнение каждой страницы). Однако для SharePoint 2010 оптимальным является значение 80 на уровне сервера, так как оно закладывает поддержку для роста и минимизирует фрагментацию.

Примечание. Мы не рекомендуем устанавливать коэффициент заполнения для отдельных таблиц или индексов. Хотя такой метод и является наиболее предпочтительным для баз данных, отличных от SharePoint SQL Server, тестирование показало, что базы данных SharePoint лучше всего работают с коэффициентом заполнения 80 %.

Чтобы просмотреть значение коэффициента заполнения одного или нескольких индексов, отправьте запрос в представление каталога sys. indexes. Дополнительные сведения об этом представлении см. в описании sys. indexes (Transact-SQL) (http://go. /fwlink/?LinkId=110850&clcid=0x409).

Чтобы настроить значение коэффициента заполнения на уровне сервера, используйте системную хранимую процедуру sp_configure. Дополнительные сведения см. в описании spconfigure (Transact-SQL) (http://go. /fwlink/?LinkId=110851&clcid=0x409).

Сжатие файлов данных

В SQL Server 2008 и SQL Server 2005 вы можете сжимать каждый из файлов в базе данных (с расширениями MDF, LDF и NDF), чтобы удалить неиспользуемые страницы и освободить место на диске. Базы данных SharePoint 2010 не выполняют автоматическое сжатие файлов данных, хотя многие операции создают в базе данных неиспользуемое пространство. К такие операции включают в себя запуск команды Move-SPSite (http://technet. /ru-ru/library/ff607915.aspx) Windows PowerShell, а также удаление документов, библиотек документов, списков, элементов списков и сайтов.

Рис. 3. Выделение места для базы данных

Свободное место освобождается только в конце файла, например, для файла базы данных контента размером 60 ГБ с заданным конечным размером в 40 ГБ освобождается как можно больше места с конца (по принятому представлению конец находится справа) 20 ГБ файла базы данных. Если в конечные 20 ГБ входят используемые страницы, то они переносятся в начальные 40 ГБ файла, которые сохраняются. Вы можете сжимать файлы базы данных по отдельности или группами.

Операции сжатия следует выполнять редко и только после выполнения операции, удаляющей из базы данных очень большой объем данных, а также только в случае, когда такое свободное место не планируется использовать повторно. Операции сжатия файлов данных вызывают значительное повышение уровня фрагментации и являются чрезвычайно ресурсоемкими. Примером ситуации, в которой допустимо сжимать файлы данных базы данных, является перемещение большого числа семейств веб-сайтов из одной базы данных контента в другую или удаление большого списка, так как при этом может создаваться большой объем неиспользуемого пространства. Файлы базы данных можно уменьшать до того момента, пока свободное место не закончится. Таким образом, для базы данных контента, в которой контент удаляется редко, сжатие дает минимальный результат и ведет к возникновению проблем с производительностью, когда базе данных требуется расти для размещения дополнительных данных. Дополнительные сведения см. в статье об инициализации файла базы данных (http://msdn. /ru-ru/library/ms175935.aspx).

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

Используйте следующие рекомендации по сжатию баз данных:

Не выполняйте автоматическое сжатие баз данных и не настраивайте план обслуживания, который предусматривает программное сжатие баз данных. Сжимайте базу данных только в том случае, если 50 % и более ее контента удалено в результате выполнения пользователем или администратором соответствующих операций, и предполагается, что это неиспользуемое место не будет занято другими данными. Мы рекомендуем сжимать только базы данных контента. Обычно база данных конфигурации, база данных центра администрирования и различные базы данных приложения-службы не достигают того числа операций удаления, которое требуется для формирования достаточного объема свободного места. Сжатие баз данных является чрезвычайно ресурсоемкой операцией. Поэтому, если вам совершенно необходимо сжать базу данных, тщательно планируйте время проведения этой операции. После сжатия базы данных индексы в ней фрагментированы. Для устранения этой фрагментации используйте ALTER INDEX… REORGANIZE. Если мгновенная инициализация файлов не разрешена, следует сжимать базу данных до целевого размера, учитывающего объем места, требуемый для ожидаемого в ближайшем будущем роста. Дополнительные сведения см. в статье об инициализации файла базы данных (http://msdn. /ru-ru/library/ms175935.aspx). Если вы устраняете фрагментацию с помощью перестроения индексов, это вызывает повторный рост базы данных и появление неиспользуемого места.

Для освобождения места базы данных и их файлы можно сжимать вручную посредством выполнения инструкций DBCC SHRINKFILE и DBCC SHRINKDATABASE с помощью SQL Server 2008 или SQL Server 2005 Management Studio.

Дополнительные сведения о том, почему сжатие базы данных оказывает отрицательное влияние на производительность и должно выполняться только в случае крайней необходимости, см. в статье о доводах против сжатия файлов данных (http://www. /BLOGS/PAUL/post/Why-you-should-not-shrink-your-data-files. aspx).

Сжатие базы данных с помощью использования команд Transact-SQL

Команда DBCC SHRINKDATABASE сжимает файлы данных и журналов для конкретной базы данных. Для сжатия отдельных файлов используйте команду DBCC SHRINKFILE.

DBCC SHRINKDATABASE

Синтаксис:

DBCC SHRINKDATABASE ( 'имя_базы_данных' | id_базы_данных | 0   [ ,целевой_процент ]   [ , { NOTRUNCATE | TRUNCATEONLY } ] ) [ WITH NO_INFOMSGS ]

Параметр имя_базы_данных | id_базы_данных | 0 задает имя или идентификатор базы данных. Чтобы выбрать текущую базу данных, используйте значение 0.

Параметр целевой_процент — это свободное место в процентах, которое требуется сохранить после выполнения сжатия базы данных.

Параметр NOTRUNCATE сжимает данные в файлах данных, перемещая распределенные страницы из конца файла в нераспределенные страницы в начале файла.

Параметр TRUNCATEONLY освобождает для операционной системы все свободное пространство в конце файла, но не выполняет перемещение страниц внутри файла.

Примечание. Использование параметра TRUNCATEONLY для баз данных контента SharePoint 2010 не поддерживается.

Дополнительные сведения см. в описании DBCC SHRINKDATABASE (Transact-SQL) (http://go. /fwlink/?LinkId=110852&clcid=0x409).

DBCC SHRINKFILE

Синтаксис:

DBCC SHRINKFILE ( { 'имя_файла' | id_файла } { [ , EMPTYFILE ] | [ [ , целевой_размер ] [ , { NOTRUNCATE | TRUNCATEONLY } ] ] } ) [ WITH NO_INFOMSGS ]

Параметр имя_файла | id_файла указывает имя или идентификатор файла.

Параметр EMPTYFILE осуществляет миграцию всех данных из указанного файла в другие файлы в рамках одной группы файлов.

Примечание. Использование параметра EMPTYFILE для файлов баз данных SharePoint 2010 не поддерживается.

Параметр целевой_размер представляет собой целевой размер файла в мегабайтах, выраженный целым числом.

Параметр NOTRUNCATE сжимает данные в файлах данных, перемещая распределенные страницы из конца файла в нераспределенные страницы в начале файла.

Параметр TRUNCATEONLY освобождает для операционной системы все свободное пространство в конце файла, но не выполняет перемещение страниц внутри файла.

Примечание. Использование параметра TRUNCATEONLY для баз данных контента SharePoint 2010 не поддерживается.

Дополнительные сведения см. в описании DBCC SHRINKFILE (Transact-SQL) (http://go. /fwlink/?LinkId=110853&clcid=0x409).

Порядок сжатия базы данных с помощью SQL Server 2008 Management Studio

На панели задач нажмите кнопку Пуск, выберите Все программы, Microsoft SQL Server 2008 и SQL Server Management Studio. В обозревателе объектов подключитесь к экземпляру SQL Server 2008 Database Engine и разверните этот экземпляр. Разверните элемент Базы данных, щелкните правой кнопкой мыши базу данных, которую хотите сжать, и выберите Задачи, Сжать и Файлы. Выберите тип и имя файла. Выберите Реорганизовать файлы перед освобождением неиспользованного места. Необходимо также задать значение Сжать файл до. При выборе этого значения все неиспользуемое место в файле освобождается для операционной системы и предпринимается попытка переноса строк на нераспределенные страницы. Нажмите кнопку ОК.

Создание планов обслуживания SQL Server 2008

Многие операции обслуживания баз данных, описанные в данном техническом документе, могут быть программно применены посредством реализации планов обслуживания SQL Server. Планы обслуживания позволяют автоматизировать и планировать выполнение важных задач по защите данных. С помощью планов обслуживания в SQL Server 2008 или SQL Server 2005 администратор может планировать выполнение таких операций, как запуск проверок согласованности базы данных и реорганизация или перестроение индексов. Дополнительные сведения см. в следующих материалах: