Поделиться через

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

  • Статья

ОБЛАСТЬ ПРИМЕНЕНИЯ:yes-img-132013 yes-img-162016 yes-img-192019 yes-img-seSubscription Edition no-img-sopSharePoint в Microsoft 365

При настройке и обслуживании реляционных баз данных SharePoint Server 2016 и 2019 в SQL Server 2014 с пакетом обновления 1 (SP1), SQL Server 2016 или SQL Server 2017 RTM необходимо выбрать варианты, которые повышают производительность и безопасность. Эти параметры также необходимо выбрать при настройке и обслуживании реляционных баз данных 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 в ферме SharePoint Server 2016, необходимо использовать SQL Server 2016 CTP 3.1 или более поздней версии. Теперь можно скачать SQL Server 2016 CTP 3.1 или более поздней версии для надстройки SQL Server PowerPivot для SharePoint. Кроме того, вы можете использовать Power View, установив Службы SQL Server Reporting Services (SSRS) в режиме интеграции с SharePoint и внешнюю надстройку SSRS с помощью установочного носителя SQL Server.

Чтобы узнать больше, скачайте новый технический документ Развертывание SQL Server 2016 PowerPivot и Power View в SharePoint 2016. Чтобы узнать больше о настройке и развертывании бизнес-аналитики в ферме SharePoint Server 2016 с несколькими серверами, скачайте документ Развертывание SQL Server 2016 PowerPivot и Power View во многоуровневой ферме SharePoint 2016.

Примечание.

Если вы планируете использовать компоненты бизнес-аналитики SQL Server в ферме SharePoint Server 2013, необходимо использовать SQL Server 2012 с пакетом обновления 1 (SP1) или SQL Server 2014. Сведения о SQL Server 2012 с пакетом обновления 1 (SP1) и SharePoint Server 2013 см. в статье Установка компонентов бизнес-аналитики SQL Server с SharePoint 2013 (SQL Server 2012 с пакетом обновления 1 (SP1) . Дополнительные сведения о SQL Server 2014 и SharePoint Server 2013 см. в статье Установка компонентов бизнес-аналитики SQL Server 2014.

Важно!

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

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

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

Примечание.

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

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

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

  • Из-за потенциальных проблем с производительностью при обслуживании нескольких экземпляров SQL рекомендуется использовать один экземпляр SQL Server для каждого развернутого сервера базы данных.

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

  • Для SharePoint Server 2013 планы обслуживания управляются SharePoint:

    • Статистика SQL управляется правилом работоспособности "Базы данных, используемые SharePoint, имеют устаревшую статистику индекса", которое вызывает proc_updatestatics
    • Для баз данных контента для свойства Статистика автоматического обновления задано значение False.

  • Для SharePoint Server 2016 и 2019 администратор SQL должен создать планы обслуживания для баз данных контента SharePoint:

    • Статистика SQL не управляется правилом работоспособности "Базы данных, используемые SharePoint, имеют устаревшую статистику индексов"
    • Для баз данных содержимого для свойства Статистика автоматического обновления задано значение True. `

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

    Важно!

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

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

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

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

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

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

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

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

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

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

Примечание.

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

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

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

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

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

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

    РАНГ Элемент
    1 Файлы данных tempdb и журналы транзакций
    2 Файлы журнала транзакций базы данных контента
    3 Базы данных поиска, кроме базы данных администрирования поиска
    4 Файлы данных базы данных контента

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

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

    РАНГ Элемент
    1 Файлы данных tempdb и журналы транзакций
    2 Файлы данных базы данных контента
    3 Базы данных поиска, кроме базы данных администрирования поиска
    4 Файлы журнала транзакций базы данных контента

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

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

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

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

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

    Примечание.

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

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

Совет

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

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

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

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

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

    Важно!

    Вам необходимо учитывать проблемы с производительностью и операциями, связанные с использованием автоматическим увеличением. Дополнительные сведения см. в разделе Рекомендации по параметрам "autogrow" и "autoshrink" в 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: ЦП, память, коэффициент попадания в кэш и подсистема ввода-вывода.

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

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

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

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

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

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

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

См. также

Понятия

Обзор SQL Server в среде SharePoint Server 2016 и 2019

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

Другие ресурсы

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