Рекомендации по использованию SQL Server в ферме SharePoint Server

**Применимо к:**SharePoint Foundation 2013, SharePoint Server 2013, SharePoint Server 2016

**Последнее изменение раздела:**2017-09-14

**Сводка.**Узнайте, как реализовать рекомендации для SQL Server в ферме SharePoint Server 2016 и SharePoint Server 2013.

При настройке и обслуживании реляционных баз данных SharePoint Server 2016 в SQL Server 2014 с пакетом обновления 1 (SP1) или SQL Server 2016 необходимо выбрать оптимальные параметры, обеспечивающие максимальную производительность и безопасность. Эти параметры также необходимо выбрать при настройке и обслуживании реляционных баз данных SharePoint Server 2013 в SQL Server 2008 R2 с пакетом обновления 1 (SP1), SQL Server 2012 и SQL Server 2014.

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

Использование выделенного сервера для SQL Server

Чтобы обеспечить оптимальную производительность операций фермы, рекомендуем установить SQL Server на выделенном сервере, на котором не выполняются никакие другие роли фермы и не размещаются базы данных ни для каких других приложений. Единственным исключением является развертывание SharePoint Server 2016 в роли фермы обособленного сервера или SharePoint 2013 на изолированном сервере, который предназначен для разработки и тестирования, но не рекомендуется для использования в рабочей среде. Дополнительные сведения см. в статьях Описание роли MinRole и связанных служб на сервере SharePoint Server 2016 и Установка SharePoint Server 2016 на одном сервере с SQL Server.

Настройка определенных параметров SQL Server перед развертыванием SharePoint Server

Чтобы обеспечить согласованность работы и производительности, перед развертыванием SharePoint Server задайте приведенные ниже параметры и настройки.

• Не включайте автоматическое создание статистики в базах данных контента SharePoint. Включение автоматического создания статистики не поддерживается в SharePoint Server. SharePoint Server настраивает необходимые параметры во время подготовки и обновления. Ручное включение автоматического создания статистики для базы данных SharePoint может существенно изменить план выполнения запроса. Для обработки статистики в базах данных SharePoint используется либо хранимая процедура (proc_UpdateStatistics), либо средства SQL Server.

• Установите максимальную степень параллелизма (MAXDOP) равной 1 для экземпляров SQL Server, в которых размещаются базы данных SharePoint, чтобы обеспечить обслуживание каждого запроса отдельным процессом SQL Server.

  Важно!

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

• Чтобы облегчить обслуживание, например упростить перемещение баз данных на другой сервер, создайте псевдонимы DNS, указывающие на IP-адрес, для каждого экземпляра SQL Server. Дополнительные сведения о псевдонимах DNS или имен узлов см. в статье Добавление псевдонима имени узла для экземпляра SQL Server.

Дополнительные сведения об этих настройках и параметрах SQL Server см. в разделе Задание параметров SQL Server.

Защита сервера базы данных перед развертыванием SharePoint Server

Рекомендуем перед развертыванием SharePoint Server запланировать и реализовать защиту сервера базы данных. Дополнительные сведения см. в приведенных ниже разделах.

• Обеспечение безопасности SQL Server

• Настройка безопасности SQL Server для сред SharePoint Server

• Обеспечение безопасности SharePoint: защита SQL Server в средах SharePoint

• Центр обеспечения безопасности для базы данных Azure SQL и SQL Server Database Engine

Настройка производительности и доступности серверов баз данных

Как и в случае с внешними серверами и серверами приложений, конфигурация серверов баз данных оказывает влияние на работу SharePoint Server Отдельные базы данных предъявляют определенные требования к совместному или раздельному расположению с другими базами данных. Дополнительные сведения см. в статьях Описание роли MinRole и связанных служб на сервере SharePoint Server 2016 и Настройка и планирование загрузки SQL Server и хранилища (SharePoint Server).

Рекомендации для баз данных с высокой доступностью, использующих зеркальное отображение, см. в статье Зеркальное отображение базы данных (SQL Server).

SQL Server Отказоустойчивая кластеризация и группы доступности AlwaysOn

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

Для групп доступности AlwaysOn требуется кластер на основе отказоустойчивой кластеризации Windows Server (WSFC). Для каждой создаваемой группы доступности создается группа ресурсов WSFC. Дополнительные сведения см. в приведенных ниже ресурсах.

• Группы доступности AlwaysOn (SQL Server)

• Обзор групп доступности AlwaysOn (SQL Server)

• Отказоустойчивая кластеризация и группы доступности AlwaysOn (SQL Server)

• Настройка групп доступности AlwaysOn SQL Server для SharePoint Server

Разработка хранилища с учетом оптимальной пропускной способности и управляемости

Мы рекомендуем разделить данные на сервере базы данных по жестким дискам и назначить этим данным приоритеты. В идеальном варианте базу данных tempdb, базы данных контента, базу данных использования, базы данных поиска и журналы транзакций следует размещать на разных жестких дисках. В списке ниже приводятся некоторые рекомендации. Дополнительные сведения см. в разделе Настройка баз данных.

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

  Компоненты с наивысшим рангом следует размещать на самых быстрых дисках.

  1. Файлы данных и журналы транзакций tempdb

  2. Файлы журналов транзакций базы данных контента

  3. Базы данных поиска, исключая базу данных администрирования поиска

  4. Файлы данных базы данных контента

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

  Компоненты с наивысшим рангом следует размещать на самых быстрых дисках.

  1. Файлы данных и журналы транзакций tempdb

  2. Файлы данных базы данных контента

  3. Базы данных поиска, исключая базу данных администрирования поиска

  4. Файлы журналов транзакций базы данных контента

• Результаты тестирования и анализ пользовательских данных показывают, что общая производительность фермы может значительно упасть из-за недостаточно быстрого выполнения дисковых операций ввода-вывода для tempdb. Во избежание данной проблемы выделите для файлов данных tempdb отдельные диски.

• Для обеспечения наибольшей производительности поместите файлы данных tempdb в массив RAID 10. Число файлов данных tempdb должно быть равно числу ядер процессоров, а сами файлы данных tempdb должны быть одинакового размера.

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

• Используйте несколько файлов данных для интенсивно используемых баз данных контента, размещая их на отдельных дисках.

• Чтобы повысить управляемость, вместо того чтобы ограничивать размер баз данных, осуществляйте мониторинг и вносите необходимые корректировки, чтобы размер баз данных контента не превышал 200 ГБ.

  Примечание

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

Правильная настройка подсистем ввода-вывода очень важна для оптимальной производительности и работы систем SQL Server. Дополнительные сведения см. в статье, посвященной наблюдению за использованием диска.

Упреждающий контроль роста размеров файлов данных и журналов

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

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

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

  Важно!

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

  • По умолчанию для новой базы данных задан шаг увеличения, равный 1 МБ. Так как эта настройка авторасширения по умолчанию приводит к увеличению размера базы данных, не полагайтесь на нее. Вместо этого следуйте рекомендациям, приведенным в разделе Задание параметров SQL Server.

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

    Примечание

    Настраивать функцию авторасширения для баз данных SharePoint следует с осторожностью. Если задать для авторасширения процентное значение, например 10 %, база данных размером 5 ГБ будет увеличиваться на 500 МБ каждый раз, когда необходимо расширить файл данных. В этом случае может закончиться место на диске.

    Рассмотрим сценарий, когда объем контента постепенно растет, например, с шагом в 100 МБ, а для функции авторасширения установлено значение 10 МБ. Затем внезапно возникает потребность в очень большом объеме места для нового сайта управления документацией, начальный размер которого составляет 50 ГБ. В этом случае желательно, чтобы расширение осуществлялось с шагом в 500 МБ, а не 10 МБ.

  • Для управляемой производственной системы следует использовать авторасширение только как защитную меру на случай неожиданного роста. Не используйте функцию авторасширения для повседневного управления ростом данных и журналов. Вместо этого настройте авторасширение в соответствии с ожидаемым через год увеличением размера файлов и добавьте 20 % для учета возможных ошибок. Кроме того, настройте оповещения о том, что на диске недостаточно места для базы данных или ее размер приближается к максимальному.

• Поддерживайте процент доступного пространства по всем дискам на уровне не ниже 25 %, чтобы обеспечить возможность роста размеров и работу в условиях пиковых нагрузок. Если для этого вы добавляете диски в массив RAID или выделяете дополнительное место в хранилище, внимательно следите за размерами дискового пространства, чтобы не допустить нехватки места.

Постоянный мониторинг хранилища и производительности SQL Server

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

Используйте комплексное представление отслеживания ресурсов. При отслеживании не ограничивайтесь ресурсами, характерными для SQL Server. Одинаково важно отслеживать следующие ресурсы на компьютерах, на которых выполняется SQL Server: ЦП, память, коэффициент попадания в кэш и подсистема ввода-вывода.

Если какой-либо из этих ресурсов сервера демонстрирует признаки замедления или перегрузки, воспользуйтесь следующими рекомендациями, опираясь на данные о текущей и прогнозируемой рабочей нагрузке.

• Наблюдение и настройка производительности

• Средства для отслеживания и настройки производительности

• Производительность сервера и мониторинг активности

• Системный монитор Windows

Использование сжатия резервных копий для ускорения резервного копирования и уменьшения размера файлов

Сжатие резервных копий позволяет ускорить резервное копирование в SharePoint. Оно доступно в выпусках SQL Server Standard и Enterprise. Если задать сжатие в скрипте резервного копирования или настроить SQL Server для сжатия по умолчанию, можно значительно сократить размер резервных копий базы данных и доставляемых журналов. Дополнительные сведения см. в статьях Сжатие резервных копий (SQL Server) и Сжатие данных или в статье Включение сжатия таблицы или индекса

Благодарности

Группа публикации контента SharePoint Server выражает благодарность указанным ниже авторам, участвовавшим в написании этой статьи.

• Кей Ункрот (Kay Unkroth), ведущий руководитель программы, SQL Server

• Чак Хайнцельман (Chuck Heinzelman), ведущий руководитель программы, SQL Server

See also

Обзор SQL Server в среде SharePoint Server 2016
Настройка и планирование загрузки SQL Server и хранилища (SharePoint Server)

Обеспечение безопасности SharePoint: защита SQL Server в средах SharePoint