Меня зовут Любовь Волкова, я системный архитектор отдела разработки бизнес-решений.
В предыдущей статье я говорил о мониторинг счетчиков производительности SharePoint Server 2013/2016 .
Сегодня мы поговорим о не менее важной задаче — обслуживании баз данных SharePoint 2013/2016. Любая ферма Microsoft SharePoint 2013/2016 должна включать в себя SQL-сервер, обеспечивающий хранение данных для различных сервисов и компонентов, развернутых для работы корпоративного портала.
Как известно, производительность работы с базами данных оказывает существенное влияние на работу корпоративного портала в целом.
Если не уделять внимание обслуживанию баз данных SharePoint или делать это неграмотно, то на практике встречаются следующие очевидные проблемы: снижение производительности на корпоративном портале, что очень часто выражается в постепенном увеличении времени ожидания загрузка страниц, форм, данных на веб-страницах, а также дублирование действий и их несогласованность с точки зрения администрирования.
Очень часто разработка планов сопровождения вызывает значительные трудности у администраторов порталов из-за сложности, сложности и необходимости обладать компетенциями не только в администрировании SharePoint, но и в администрировании SQL-сервера.
Поэтому в этой статье я рассмотрел все ключевые операции по обслуживанию базы данных, привел примеры скриптов и практические советы.
Используя предоставленные описания, вы найдете множество рекомендаций к действию.
Отмечу, что материалы статьи не являются исчерпывающими, т.к.
нет возможности включить в нее описание абсолютно всех деталей и тонкостей обслуживания баз данных SharePoint. Для предоставления вам более подробной информации по той или иной теме предоставляются ссылки на дополнительные публикации.
Введение
Разнообразие баз данных, от которых зависит SharePoint, можно разделить на три группы:- Системные базы данных SQL-сервера (master, model, msdb, tempdb).
- Базы данных системы SharePoint (база данных конфигурации и контента Центра администрирования).
- Базы данных SharePoint Server, которые обеспечивают хранилище данных для развернутых сервисных приложений (например, служб управления метаданными, служб профилей пользователей, служб подключения к бизнес-данным и других).
Ниже приведен список рекомендуемых задач по обслуживанию базы данных SharePoint:
- Проверка целостности базы данных.
- Дефрагментация индексов.
- Оптимизация производительности индекса с использованием коэффициента заполнения.
- Сжатие баз данных SharePoint.
- Настройка режима восстановления баз данных;
- Резервное копирование системных баз данных;
- Разработка планов обслуживания.
Общую информацию о назначении, требованиях к расположению, моделях восстановления по умолчанию и другую информацию для каждой из баз данных можно прочитать Здесь .
Эта статья предназначена для системных администраторов, администраторов баз данных и технических специалистов, поддерживающих работу корпоративных порталов SharePoint.
Проверка целостности базы данных
Команда DBCC CHECKDB обеспечивает комплексную проверку логической и физической целостности всех объектов указанной базы данных и включает в себя следующий набор проверок:- согласованность структур распределения дискового пространства для указанной базы данных;
- целостность всех страниц и структур, составляющих таблицу или индексированное представление;
- согласованность каталогов в указанной онлайн-базе данных;
- содержимое каждого индексированного представления в базе данных;
- согласованность между таблицами метаданных, файлами в системных папках и файлами на уровне ссылок при хранении данных varbinary(max) в файловой системе с использованием FILESTREAM;
- Данные Service Broker в базе данных.
Пример результатов выполнения скрипта, указывающий на отсутствие ошибок:DBCC CHECKDB ('WSS_Content') WITH PHYSICAL_ONLY, ALL_ERRORMSGS GO
Пример результатов, указывающих на наличие ошибок и необходимость решения проблемы для конкретной базы данных:
Команда DBCC CHECKDB интенсивно использует ресурсы ввода-вывода, ЦП и памяти.
Чтобы уменьшить нагрузку по проверке согласованности в вашей производственной системе, мы рекомендуем запускать команду DBCC CHECKDB для восстановленных резервных копий базы данных SharePoint на отдельном сервере.
Если вы запускаете команду DBCC CHECKDB в производственной базе данных, рекомендуется запускать ее в нерабочие часы, ограничиваясь проверкой целостности физической структуры страниц и заголовков записей, а также целостности выделения пространства базы данных.
Дефрагментация индексов
Введение
Фрагментация индекса — это состояние, при котором определяемый ключом логический порядок страниц в индексе отличается от физического порядка страниц в файлах данных.Это также может указывать на низкую плотность данных на страницах файлов данных, что приводит к неэффективному использованию дискового пространства, памяти и ресурсов подсистемы ввода-вывода.
Основными причинами фрагментации индекса являются множественные вставки, обновления и удаления таблиц.
На рисунках 1 и 2 показана разница между новым нефрагментированным индексом и тем же индексом после большого количества вставок, обновлений и удалений.
Красная стрелка определяет физический порядок индекса, а черная стрелка — логический порядок страниц.
Рисунок 1. Нефрагментированный индекс (источник: Пол С.
Рэндал) 
Рисунок 2. Фрагментированный индекс (источник: Пол С.
Рэндал) 
Поскольку данные вставляются, обновляются и удаляются неравномерно по строкам таблицы и индекса, каждая страница в разное время будет иметь разные уровни полноты (плотности данных).
В этом случае при обработке запроса, требующего сканирования части или всех индексов таблицы, высокая фрагментация приведет к большему количеству чтений страниц, что, в свою очередь, предотвратит параллельное сканирование данных и приведет к значительному снижению производительности.
Фрагментация индекса может привести к снижению производительности и неэффективному использованию пространства.
Однако даже в малоиспользуемых базах данных фрагментация индекса может быстро расти.
Реорганизовать и перестроить индексы
Поддерживаются два метода уменьшения фрагментации индекса:- Реорганизация индекса, которая дефрагментирует и уплотняет кластерные и некластеризованные индексы таблиц и представлений, что может значительно повысить производительность индекса.
Реорганизация всегда выполняется онлайн, чтобы базовая таблица была доступна пользователям.
- Перестроение индекса, при котором выполняется полное перестроение индекса с использованием тех же столбцов, типов индексов, уникальности атрибутов и порядка сортировки.
Перестроение повышает производительность сканирования индекса.
Вы можете перестроить индекс онлайн или офлайн.
Оперативное перестроение может быть недоступно для индекса, содержащего столбцы больших объектов, например столбцы с типом данных NVARCHAR(MAX), IMAGE и т. д. Процесс автономной перестройки блокирует таблицы на определенном уровне, делая их недоступными для записи или даже просмотра.
Многие индексы базы данных SharePoint содержат столбцы больших объектов и поэтому всегда перестраиваются в автономном режиме.
Обратите внимание, что во время онлайн-перестроения таблицы могут быть заблокированы на короткий период времени, что препятствует выполнению любых операций, кроме SELECT. Базы данных SharePoint 2013/16 особым образом используют кластеризованные индексы.
Когда такой индекс перестраивается в автономном режиме, к таблице применяется монопольная блокировка, которая полностью запрещает доступ к нему пользователей .
Предпочтительный метод дефрагментации индекса зависит от того, насколько он фрагментирован и может ли он оставаться в сети или его необходимо обрабатывать в автономном режиме.
В следующей таблице описаны рекомендуемые методы дефрагментации для индексов с различной степенью фрагментации для баз данных SharePoint:
| Степень фрагментации | Рекомендуемые действия |
|---|---|
| От 5 до 10% | Реорганизация (режим работы) |
| От 10 до 75% | Восстановление (рабочий режим) с параметром ALTER INDEX REBUILD With (ONLINE=ON) |
| Более 75% | Смена полосы движения (автономный режим) с параметром ALTER INDEX REBUILD With (ONLINE=OFF) |
Автоматизируйте обслуживание индекса с помощью системных заданий.
Правила анализатора работоспособности
В SharePoint 2013/2016 процесс мониторинга служб и компонентов можно частично автоматизировать с помощью правил анализатора работоспособности SharePoint ( проверка статистики индекса И проверки фрагментации индекса для баз данных сканирования службы поиска).Их использование позволяет ежедневно оценивать состояние, а также автоматически вести индексы по следующим базам данных:
- Базы данных конфигурации.
- Базы данных контента SharePoint, включая базу данных контента центра администрирования.
- Базы данных профилей пользователей.
- Базы данных социальных тегов приложений службы профилей пользователей.
- Базы данных автоматизации Word.
Примеры системных задач: 
Правила, проверяющие фрагментацию индекса
- Индексы баз данных, используемых SharePoint, фрагментированы.
При выполнении этого правила выполняются следующие задачи:
- Правило сообщает о фрагментированных индексах.
Это связано с важностью состояния индекса.
В соответствии с правилами анализатора работоспособности это правило всегда будет сообщать о фрагментированных индексах для запуска операций восстановления.
- Для каждой базы данных SharePoint операция восстановления выполняет поиск и, если поиск успешен, выполняет хранимую процедуру.
proc_DefragmentIndices хранимая процедура.
Эта хранимая процедура создает список всех индексов в базе данных.
Каждый индекс оценивается на текущем уровне фрагментации.
Любые фрагментированные индексы рассматриваются для восстановления.
более 30 процентов .
- Если версия SQL Server поддерживает перестроение индекса в режиме онлайн, попытка перестроения соответствующего индекса производится отдельно для каждого индекса.
Если это не удается, выполняется автономное восстановление индекса.
- Правило сообщает о фрагментированных индексах.
- Поиск.
Одна или несколько баз данных сканирования могут иметь фрагментированные индексы.
Это правило поддерживает индексы базы данных обхода контента поиска SharePoint. По умолчанию это правило настроено на запуск только по требованию.
Правило выполняется с любого сервера фермы.
При выполнении этого правила выполняются следующие задачи:
- Правило подтверждает, что среда находится в состоянии, в котором можно безопасно дефрагментировать индексы.
- Для каждой базы данных обхода, настроенной для приложений поиска в локальной ферме, правило выполняет хранимую процедуру.
proc_MSS_DefragGathererIndexes .
- Каждый индекс базы данных обхода контента в списке будет перестроен.
Если ваша версия SQL Server поддерживает перестроение индексов в режиме онлайн, индексы будут перестроены соответствующим образом.
Если перестроить индексы в этом режиме не удастся, индекс будет перестроен в автономном режиме.
- Правило подтверждает, что среда находится в состоянии, в котором можно безопасно дефрагментировать индексы.
Запуск хранимых процедур дефрагментации индекса
Многие базы данных SharePoint содержат хранимые процедуры, которые анализатор работоспособности использует для дефрагментации индексов.Хотя эти правила выполняют дефрагментацию автоматически, вам может потребоваться запустить дефрагментацию вручную.
Например, этого могут требовать ваши соглашения об уровне обслуживания или некоторые корпоративные правила.
Вы можете запланировать выполнение этих хранимых процедур ежедневно, еженедельно или ежемесячно в зависимости от ваших потребностей и общей скорости изменений в вашей среде.
Рекомендуется разрешить SharePoint управлять собственными индексами базы данных.
Если вам необходимо вручную выполнить этот шаг, рекомендуется, как минимум, настроить график ежедневного обслуживания, чтобы процедура выполнялась.
proc_DefragmentIndice и еженедельное выполнение процедуры proc_MSS_DefragSearchIndexes .
Мониторинг фрагментации индекса с помощью SQL-сервера
Прежде чем приступить к реализации плана обслуживания фрагментированного индекса, необходимо определить наиболее фрагментированные таблицы и индексы и только затем разработать для них план.восстановление и реорганизация .
Например, в SharePoint 2013/2016 таблица очень подвержена фрагментации.
ВсеДокументы , который содержит библиотеки документов, связанные с ними документы, списки и элементы списков, а также связанные метаданные.
Несмотря на наличие автоматизированных системных задач для анализатора производительности, их работа не всегда эффективна.
Степень фрагментации индекса определяется как доля страниц индекса, логический порядок которых отличается от физического порядка.
Чтобы определить его в SQL Server 2014 и SQL Server 2016, необходимо использовать представление динамического управления.
sys.dm_db_index_physical_stats .
Вы можете использовать следующий сценарий (на примере базы данных контента SharePoint «WSS_Content»): USE [WSS_Content];
GO
SELECT obj.type_desc
Теги: #ИТ-инфраструктура #Системное администрирование #Администрирование баз данных #sharepoint #sharepoint 2013 #sharepoint 2016 #обслуживание баз данных #Базы данных SharePoint
-
Поиск Потенциальных Клиентов В Интернете
19 Oct, 24 -
Питон За Месяц
19 Oct, 24 -
Нейрокоп Часть 0. Или Нейро- Без Курятника
19 Oct, 24 -
Как Не Стоит Делать Сайты На Netcat
19 Oct, 24 -
Аккредитация На Этп – Для Тех, Кому Нужно
19 Oct, 24 -
Роботизированная Рука, Управляемая Мыслью
19 Oct, 24
