Администраторы SharePoint стоят на страже порядка при каждом развертывании SharePoint. Целостность данных SharePoint проистекает от должной организации сайтов, коллекций сайтов, типов контента и тегов метаданных. Управляющие настройками и функциями SharePoint администраторы несут ответственность за общую производительность и стабильность всей платформы SharePoint. И хотя оптимальная производительность фермы SharePoint — это нечто большее, чем хороший набор баз данных, несомненно, что этот набор должен обеспечивать работу компонентов низшего уровня настолько гладко, насколько это возможно.

.

SharePoint 2010 поставляется в комплекте с мастером Microsoft SQL Server Maintenance Plan Wizard, который помогает администраторам SharePoint автоматизировать утомительные задачи эксплуатации, однако важно четко понимать, что именно должно быть сделано.

Базы данных

С SharePoint 2007 было проще, ведь для понимания и управления базами данных, необходимых для нормального функционирования приложения, требуются только базы данных контента, базы данных конфигурации и, возможно, одна-две поисковые базы данных.

SharePoint 2010 — совсем другое дело. С появлением служебных приложений и обширного набора системных баз данных одна установка SharePoint 2010 может иметь до 20 баз данных, каждая из которых должна содержать резервную копию и обслуживаться. Именно поэтому важно понимать, какие базы данных являются основными для системы или какие необходимы для должного функционирования различных приложений SharePoint 2010 (рисунок 1 и рисунок 2 представляют различные базы данных и дают информацию о них).

 

Рисунок 1. Основные базы данных SharePoint 2010

 

Рисунок 2. Серверные базы данных SharePoint 2010

Перед тем как более подробно рассматривать базы данных SharePoint, важно понять, какие версии SQL Server поддерживаются системами SharePoint 2010. SharePoint 2010 поддерживает 64-разрядную версию SQL Server 2008 R2, SQL Server 2008 и SQL Server 2005. Я рекомендую использовать SQL Server 2008 R2, потому что у него самый широкий набор функций и свойств, предназначенных для SharePoint. Например, хранилище Remote Blog Storage доступно только в редакции SQL Server 2008 Enterprise. Чтобы получить больше информации о различных версиях SQL Server, просмотрите руководство «SQL Server 2008 R2 and SharePoint 2010: Better Together» по адресу technet.microsoft.com/en-us/library/cc990273.aspx.

Убедитесь, что на все системы SQL Server установлены последние пакеты обновлений и исправления, согласно рекомендациям статьи на TechNet «Hardware and Software Requirements (SharePoint Server 2010)» Статья опубликована на technet.microsoft.com/en-us/library/cc262485.aspx. Эта страничка обновляется при появлении новых пакетов обновлений и исправлений. Посещайте ее хотя бы раз в месяц. Ко времени написания этой статьи данная страничка обновлена уже три раза, а самое последнее обновление было в июле 2010.

Ручное или автоматическое развертывание баз данных?

С некоторыми исключениями, SharePoint 2010 сам создает все базы данных, необходимые для корректного функционирования среды SharePoint. Пользуясь автоматической процедурой развертывания, должен ли администратор баз данных быть готов к предварительному созданию баз данных SharePoint вручную? В производственной среде обстоятельства диктуют более гибкий подход, чем автоматическое развертывание, в частности возможны такие ситуации, когда вам нужно обеспечить:

  • гарантированную проверку всех имен баз данных (а не идентификаторов GUID в именах баз данных);
  • гарантированную проверку размеров баз данных;
  • процедурное разделение управления средами приложений и данных.

Если необходимо создать базы данных вручную, а не автоматически, вам нужно задействовать подходящие команды PowerShell для создания баз данных и регистрации их в SharePoint. Например, вы можете использовать такую команду PowerShell для создания новой конфигурации базы данных:

New-SPConfigurationDatabase
   -DatabaseName "SharePointConfigDB1"
   -DatabaseServer "SQL-01"
   -Passphrase (ConvertTo-SecureString
   "MyPassword» -AsPlainText -force)
   -FarmCredentials (Get-Credential)

Найти подробное описание того, как администратор баз данных может создавать различные базы данных контента и конфигурации, можно в статье TechNet «Deploy by using DBA-created databases (SharePoint Server 2010)» по адресу technet.microsoft.com/en-us/library/cc262869.aspx.

Целостность данных

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

Защита данных — процесс мудреный, особенно если беспорядочные скачки напряжения и отключения питания вызывают нарушение работы подсистемы ввода-вывода SQL Server в момент записи на диск. Разрушение данных часто является результатом именно этого, а без должных проверок ошибки прокрадутся в базу данных и будут оставаться незамеченными, пока в соответствии с законом Мерфи руководству не понадобятся важные данные.

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

Нарушения физической целостности данных, которые отслеживаются DBCC CHECKDB, встроенной функцией SQL, обычно вызываются проблемами с оборудованием.

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

Ошибки в SQL Server также могут вызвать этот тип нарушения; например, как можно узнать из статьи Microsoft (http://support.microsoft.com/?kbid=955280), подтверждение транзакции может случайно не произойти при ее выполнении в Windows Server 2003 или в Windows XP Professional x64 Edition.

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

Важно отметить, что команда DBCC CHECKDB не выполняет проверку на логические нарушения целостности. Однако она может вызвать такое нарушение, если используется установка REPAIR_ALLOW_DATA_LOSS, поскольку в этом случае при восстановлении после нарушения физической целостности не учитываются никакие ограничения.

Что же делать администратору баз данных? Когда команда DBCC CHECKDB возвращается с сообщениями об ошибке, лучше всего обратиться к резервным копиям баз данных.

Однако это решение требует наличия регулярно создаваемых копий, которые не должны быть повреждены. Как упоминалось ранее, команда DBCC CHECKDB потенциально может вызывать ошибки, когда она используется для решения проблем целостности. Без резервных копий не существует способа «вылечить» данные в поврежденной базе данных.

Скорость

SharePoint — это сложное приложение, которое полагается на многие другие инфраструктуры, компоненты и серверные приложения. Ненадлежащее обслуживание одного из этих уровней может вызвать проблемы и, возможно, даже простой. К счастью, настройка SQL Server для оптимальной производительности не так уж сложна. Улучшения производительности SQL Server включают пару настроек конфигурации, надлежащее размещение файлов данных и журналов и перестройку табличных индексов время от времени.

Первое — это надлежащий выбор аппаратного обеспечения для SQL Server. Как было сказано в руководстве Microsoft «SQL Server 2008 R2 and SharePoint 2010: Better Together» (technet.microsoft.com/en-us/library/cc990273.aspx), SharePoint 2010 требует 64-разрядной версии SQL Server, потому что 32-разрядное аппаратное и программное обеспечение больше не поддерживается. Базовая конфигурация массива RAID, разбиение разделов SAN и требования к локальным хранилищам также играют важную роль в определении производительности SQL Server, поскольку некоторые рекомендации настаивают на физическом распределении файлов данных и файлов журналов по различным дискам. Кроме того, требования к оперативной памяти системы SQL Server начинаются с 16 Гбайт и выше. Microsoft предоставляет некоторые специфические для SharePoint рекомендации относительно SQL Server в статье на TechNet «Storage and SQL Server capacity planning and configuration (SharePoint Server 2010)» по адресу technet.microsoft.com/en-us/library/cc298801.aspx.

Управление файлами базы данных

Когда дело доходит до управления файлами данных SQL Server, опыт показывает, что файлы данных и журналы должны находиться каждый на своем физическом диске. Это больше чем размещение на разных томах диска. Рекомендация здесь сводится к следующему: поместить файлы журнала и файлы данных на различные диски и убедиться, что никакое другое приложение не использует их. Данная схема минимизирует доступ на запись к дискам и уменьшает возможности фрагментации файла.

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

Измерение и уменьшение фрагментации

Фрагментация данных внутри SQL Server может объясняться обычными манипуляциями с данными, включая вставку, изменение и удаление. Базовым симптомом фрагментации данных является увеличение свободного пространства, соответствующего объему данных. Дело в том, что SQL Server сохраняет данные как страницу базы данных, которая содержит детали заголовка, детали записи и индекс. Однако страница базы данных также настроена в соответствии с заполнением SQL Server так, чтобы она имела минимальный размер. Записи меньшие, чем результат такого заполнения, приводят к большому количеству пустого пространства в таблице. Системы SharePoint полагаются на ключи индекса, основанные на GUID, и вследствие этого усугубляют проблему, беспорядочно вставляя данные по всему диапазону записей.

Чтобы решить эту проблему, лучше всего либо изменить схему индекса либо перестроить индекс для того, чтобы сжать и дефрагментировать данные. Поскольку SharePoint не может изменять схему используемого индекса, единственной возможностью остается перестройка индекса для таблиц. Соблазн заключается в том, чтобы периодически перестраивать все индексы, используя план автоматического обслуживания, но он ведет к требованию значительного количества доступного свободного пространства, так что это неудачный выбор для больших систем. Лучшим вариантом было бы использование представления DMV SYS.DM_DB_INDEX_PHYSICAL_STATS, с тем чтобы найти индексы, которые наиболее фрагментированы. На сайте MSDN приводится пример кода, по адресу msdn.microsoft.com/library/ms188917.

Поддержание текущей статистики

Когда SQL Server выполняет запрос, он вычисляет и компилирует план исполнения. План исполнения создается Query Processor в SQL Server, и он определяет, какие таблицы и индексы используются для достижения оптимальной производительности. Метрики для определения производительности запроса выводятся из статистики, которая помогает SQL Server понять, как данные распределяются внутри таблицы или индекса. Статистика собирается при разнообразных операциях чтения, включая полное и примерное сканирование данных. Если эта статистика не актуальна в силу фрагментированных индексов, план исполнения не будет таким эффективным, каким он мог бы быть.

Обычно статистика сохраняется актуальной автоматически, но определенные обслуживающие операции или интенсивные манипуляции с данными могут вызвать потерю ее актуальности. Вы можете заставить SQL Server обновить статистику через встроенную функцию SP_UPDATESTATS. Не рекомендуется запускать эту функцию после восстановления индекса, потому что такое действие может изменить предыдущий уровень выборки (который определен автоматически) и будет иметь неблагоприятные последствия. В опубликованной в августе 2008 года статье на TechNet «Top Tips for Effective Database Maintenance» (technet.microsoft.com/en-us/magazine/2008.08.database.aspx) рекомендуемое обслуживание баз данных предполагает такой план:

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

Определение размеров данных

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

Database size = ((# Documents × #
   Versions) × Avg Size) + (10 KB
   ×(# List items + (# Versions × #
   Documents)))

Хотя это вычисление даст лишь грубую оценку объема хранения, можно кое-что сделать для того, чтобы уточнить результат. Как упоминалось ранее, контент базы данных хранится в страницах базы данных, которые имеют постоянный размер благодаря заполнению. Регулирование коэффициента заполнения может повлиять на фрагментацию и общий объем данных на диске. Уменьшить размер базы данных можно с помощью DBCC SHRINKDATABASE, хотя Microsoft в настоящий момент дает некоторые предостережения об использовании этой функции. Наконец, если перекладывание обязанностей по хранению всех данных в SQL Server приводит к большим затратам и перегрузке, вы можете предписать SharePoint использовать файловую систему для хранения больших бинарных объектов, BLOB.

Более подробную информацию можно найти в статье TechNet «Storage and SQL Server capacity planning and configuration (SharePoint Server 2010)» (technet.microsoft.com/enus/library/cc298801.aspx).

Установка коэффициента заполнения на сервер

Изменяя начальное значение FILLFACTOR по умолчанию, администратор баз данных может уменьшить фрагментацию и разбиение страниц (симптом фрагментации, который влияет на производительность). Однако побочный эффект состоит в том, что занято больше пространства на диске, поскольку страницы базы данных будут объемнее. Во время регулярных операций новый контент может быть вставлен в это свободное пространство без запроса кластерного индекса для присоединения большого количества данных. Кимберли Трипп делится опытом обслуживания баз данных в своем блоге на сайте www.sqlskills.com/BLOGS/KIMBERLY/post/Database-Maintenance-Best-Practices-Part-II-e28093-the-most-important-setting-FILLFACTOR.aspx.

Уменьшение объема базы данных

Все версии SQL Server, которые поддерживаются SharePoint, обладают способностью уменьшать файлы данных, что освобождает пространство на диске. Ни одна из баз данных в SharePoint не настроена на автоматическое уменьшение объема файлов данных. Настоятельная рекомендация от Microsoft и специалистов SQL Server заключается в том, чтобы не производить автоматическое уменьшение базы данных или не выполнять плановых операций сжатия баз данных. Причина в том, что уменьшение базы данных игнорирует фактор заполнения и делает все индексы фрагментированными. Затем, когда вы запускаете команду восстановления индексов, база данных достигает своего изначального размера. Вместо того чтобы полагаться на команды DBCC_SHRINKDATABASE, которые есть в SQL Server, будет более безопасно разбить базы данных контента или удалить данные из существующих баз данных. Ниже представлен список действий, которые следует выполнить для получения свободного пространства в среде SharePoint:

  • использовать STSADM MERGCONTENTSDB;
  • удалить документы;
  • удалить библиотеки;
  • удалить списки;
  • удалить элементы списка;
  • удалить сайты.

Удаленное хранилище BLOB

Для того чтобы освободить дефицитные ресурсы, такие как файловая система, можно использовать новый механизм Remote BLOB Storage (RBS), доступный в SQL Server 2008. Хотя это и звучит многообещающе — можно переместить объемные данные (например, файлы изображений, видео- или аудиофайлы), вам все равно прежде всего нужно оценить достоинства и недостатки. Если файлы небольшие и у вас много маленьких по объему BLOB, вы столкнетесь с уменьшением производительности сервера.

Итак, оцените свой контент для того чтобы определить, нужно ли вам внедрять RBS. Рекомендация: ваши базы данных контента должны быть больше 500 Гбайт, а файлы данных BLOB — больше 256 Кбайт. RBS улучшают производительность систем, где есть очень объемные файлы, но к ним обращаются нечасто. Добавление RBS к вашему SharePoint может на самом деле замедлить работу пользователей.

Планы обслуживания базы данных

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

План обслуживания базы данных похож на техобслуживание машины. Следует осуществлять этот процесс по определенной программе для того, чтобы SQL Server работал на оптимальном уровне, а веб-сайт — на максимуме производительности.

Значительная часть плана обслуживания SQL Server — это использование мастера Maintenance Plan Wizard. Он дает вам возможность добавлять шаги, такие как копирование базы данных и журналов транзакций, обновление статистики базы данных и управление данными, такими как индексы.

В статье TechNet «Top Tips for Effective Database Maintenance» (technet.microsoft.com/en-us/magazine/2008.08.database.aspx) предлагается список задач, которые необходимо включить в план.

  • Удалить излишнюю фрагментацию файла журнала транзакций посредством создания подходящей модели восстановления и расписания резервирования.
  • Исключите любые плановые операции по уменьшению объема базы данных, чтобы снизить риск ненужной фрагментации индекса.
  • Установите автоматическое увеличение базы данных корректно, используя назначение размера файла, а не процентное соотношение. Следуйте этому пути, периодически проверяя размеры базы данных и определяя, необходимо ли задавать размер вручную для достижения оптимальной производительности.
  • Включите постоянную инициализацию файлов, так чтобы автоматическое увеличение базы данных выполнялось как мгновенная операция, а не медленная операция, которая требует заполнения нулями свободного пространства.
  • Наладьте регулярный процесс для обнаружения и удаления фрагментации индекса.
  • Включите настройки AUTO_CREATE_STATISTICS и AUTO_UPDATE_STATISTICS и наладьте регулярный процесс обновления статистики.
  • Включите контрольные суммы страниц.
  • Запустите регулярный процесс DBCC CHECKDB.

Любой администратор SharePoint должен понимать, что потратить некоторое время на создание базового плана обслуживания означает гарантировать, что система заработает хорошо. Это время окупится производительностью, скоростью и резервными копиями, если они когда-нибудь потребуются.

Мэтт Ранлет (mranlett@devcow.com) — консультант в компании Intellinet из Атланты, имеет звание Microsoft MVP

Брендон Шварц (bschwartz@devcow.com) — старший консультант из Атланты, имеет звание Microsoft MVP