Рекомендации по проектированию SQL Server

System Center Operations Manager требует доступа к экземпляру сервера под управлением Microsoft SQL Server для поддержки операционной, хранилища данных и базы данных аудита ACS. При развертывании первого сервера управления в группе управления требуются операционные базы данных и базы данных хранилища данных, а база данных ACS создается при развертывании сборщика ACS в группе управления.

В лабораторной среде или в маломасштабном развертывании Operations Manager SQL Server может находиться на первом сервере управления в группе управления.

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

Не рекомендуется использовать базы данных Operations Manager из экземпляра SQL с другими базами данных приложений. Это позволяет избежать потенциальных проблем с ограничениями ввода-вывода и других аппаратных ресурсов.

Внимание

Operations Manager не поддерживает экземпляры SQL платформы как службы (PaaS), включая такие продукты, как Управляемый экземпляр SQL Azure или Amazon Relational Database Service (AWS RDS). Используйте экземпляр SQL Server, установленный на компьютере с Windows. Единственным исключением из этого является Управляемый экземпляр SCOM в Azure Monitor, который использует Azure SQL MI и не настраивается повторно.

требования SQL Server

Следующие версии SQL Server Enterprise и выпуск Standard поддерживаются для существующей установки версии System Center Operations Manager для размещения сервера отчетов, операционной, хранилища данных и базы данных ACS:

• SQL Server 2022

• SQL Server 2019 с накопительным обновлением 8 (CU8) или более поздней версии, как описано здесь

  Примечание.

  • Operations Manager 2022 поддерживает SQL 2019 с накопительным пакетом обновления 8 или более поздней версии; Однако она не поддерживает SQL 2019 RTM.
  • Используйте ODBC 17.3 или 17.10.6 и MSOLEDBSQL 18.2 или 18.7.2.

• Обновления SQL Server 2017 и накопительные обновления, как описано здесь

Перед обновлением SQL Server см . сведения об обновлении 2017 года и сведения об обновлении ДЛЯ SQL 2019.

Примечание.

• Каждый из следующих компонентов SQL Server, поддерживающих инфраструктуру SCOM, должен находиться в одной основной версии SQL Server:
  • Экземпляры ядра СУБД SQL Server, в котором размещаются все базы данных SCOM (т. е. OperationManager, OperationManagerDW и базы данных SSRS ReportServer и ReportServerTempDB).
  • экземпляр SQL Server Reporting Services (SSRS).
• Параметр сортировки SQL Server должен быть поддерживаемого типа, как описано в разделе Параметр сортировки SQL Server ниже.
• Функция полнотекстового поиска SQL Server требуется для всех экземпляров ядра СУБД SQL Server, в которых размещены базы данных SCOM.
• Параметры установки Windows Server 2016 (Server Core, сервер с возможностями рабочего стола и Nano Server), поддерживаемые компонентами базы данных Operations Manager, основаны на параметрах установки Windows Server, поддерживаемых службой SQL Server.

Примечание.

System Center Operations Manager Reporting не может быть установлен параллельно с предыдущей версией роли создания отчетов и должен быть установлен только в собственном режиме (не поддерживается интегрированный режим SharePoint).

Дополнительные рекомендации по оборудованию и программному обеспечению применяются в планировании проектирования:

• Рекомендуется запускать SQL Server на компьютерах с форматом файлов NTFS.
• Для операционной базы данных и базы данных хранилища данных должно быть не менее 1024 МБ свободного места на диске. Оно применяется во время создания базы данных и, скорее всего, значительно увеличится после установки.
• Требуется платформа .NET Framework 4.
• Платформа .NET Framework 4.8 поддерживается в Operations Manager 2022.
• Сервер отчетов не поддерживается в Windows Server Core.

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

Примечание.

Хотя Operations Manager использует только проверка подлинности Windows во время установки, параметр проверки подлинности в смешанном режиме SQL по-прежнему будет работать, если локальная учетная запись не имеет роли db_owner. Локальные учетные записи с ролью db_owner, как известно, вызывают проблемы с System Center Operations Manager. Удалите роль db_owner из всех локальных учетных записей перед установкой продукта и не добавляйте роль db_owner к любой из локальных учетных записей после установки.

Параметр сортировки SQL Server

Следующие параметры сортировки SQL Server и Windows поддерживаются System Center Operations Manager.

Примечание.

Чтобы избежать проблем совместимости при сравнении или копировании операций, рекомендуется использовать те же параметры сортировки для базы данных SQL и Operations Manager.

Параметры сортировки SQL Server

• SQL_Latin1_General_CP1_CI_AS

параметры сортировки Windows

• Latin1_General_100_CI_AS
• French_CI_AS
• French_100_CI_AS
• Cyrillic_General_CI_AS
• Chinese_PRC_CI_AS
• Chinese_Simplified_Pinyin_100_CI_AS
• Chinese_Traditional_Stroke_Count_100_CI_AS
• Japanese_CI_AS
• Japanese_XJIS_100_CI_AS
• Traditional_Spanish_CI_AS
• Modern_Spanish_100_CI_AS
• Latin1_General_CI_AS
• Cyrillic_General_100_CI_AS
• Korean_100_CI_AS
• Czech_100_CI_AS
• Hungarian_100_CI_AS
• Polish_100_CI_AS
• Finnish_Swedish_100_CI_AS

Если экземпляр SQL Server не настроен с одним из поддерживаемых параметров сортировки, перечисленных ранее, выполнение новой установки Operations Manager завершится ошибкой. Однако обновление на месте завершится успешно.

Настройка брандмауэра

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

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

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

Сценарий	Порт	Направление	Роль Operations Manager
SQL Server, в котором размещаются базы данных Operations Manager	TCP 1433 *	Входящий трафик	сервер управления и веб-консоль (для помощника по приложениям и диагностики приложений)
служба «SQL Server, браузер»	UDP 1434	Входящий трафик	сервер управления
Подключение выделенного администратора SQL Server	TCP 1434	Входящий трафик	сервер управления
Дополнительные порты, используемые SQL Server — Вызовы удаленной процедуры Майкрософт (MS RPC) — Инструментарий управления Windows (WMI) — Координатор распределенных транзакций Майкрософт (MS DTC)	TCP 135	Входящий трафик	сервер управления
Прослушиватель группы доступности AlwaysOn SQL Server	Настроенный администратором порт	Входящий трафик	сервер управления
SQL Server Reporting Services, на котором размещается Operations Manager Reporting Server	TCP 80 (по умолчанию)/443 (SSL)	Входящий трафик	сервер управления и консоль управления

* TCP 1433 — стандартный порт для экземпляра ядра СУБД по умолчанию. Но если создать именованный экземпляр на автономном сервере SQL Server или развернуть группу доступности SQL AlwaysOn, будет определен пользовательский порт, который нужно зафиксировать документально, чтобы правильно настроить брандмауэры и ввести соответствующую информацию во время настройки.

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

Рекомендации по емкости и хранилищу

база данных Operations Manager

База данных Operations Manager — это база данных SQL Server, содержащая все данные, необходимые Operations Manager для повседневного мониторинга. Размер и настройка сервера базы данных критически важны для общей производительности группы управления. Наиболее критически важный ресурс, используемый базой данных Operations Manager, является подсистемой хранения, но ЦП и ОЗУ также являются значительными.

Факторы, влияющие на нагрузку базы данных Operations Manager, включают:

• Скорость сбора операционных данных. Операционные данные состоят из всех событий, оповещений, изменений состояния и данных производительности, собранных агентами. Большинство ресурсов, используемых базой данных Operations Manager, используются для записи этих данных на диск по мере его ввода в систему. Скорость сбора операционных данных, как правило, увеличивается по мере импорта дополнительных пакетов управления и добавления дополнительных агентов. Тип компьютера, который отслеживает агент, также является важным фактором, используемым при определении общей скорости сбора операционных данных. Например, агент, отслеживающий критически важный для бизнеса компьютер, может собирать меньше данных, чем агент, отслеживающий сервер, на котором выполняется экземпляр SQL Server с большим количеством баз данных.
• Скорость изменения пространства экземпляра. Обновление этих данных в базе данных Operations Manager является дорогостоящим относительно записи новых операционных данных. Кроме того, при изменении данных пространства экземпляра серверы управления выполняют дополнительные запросы к базе данных Operations Manager для вычисления конфигурации и группирования изменений. Скорость изменения пространства экземпляра увеличивается при импорте дополнительных пакетов управления в группу управления. Добавление новых агентов в группу управления также временно увеличивает скорость изменения пространства экземпляров.
• Количество консольов управления и других подключений к пакету SDK, выполняющихся одновременно. Каждая консоль управления считывает данные из базы данных Operations Manager. Запросы к этим данным используют потенциально большие объемы ресурсов операций ввода-вывода хранилища, времени ЦП и ОЗУ. Консоли управления, отображающие большие объемы операционных данных в представлении событий, представлении состояния, представлении оповещений и представлении данных производительности, обычно вызывают большую нагрузку на базу данных.

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

Вы можете настроить и обновить базы данных Operations Manager с помощью существующей настройки Always-On SQL без необходимости вносить изменения после конфигурации.

Включение SQL Broker в базе данных Operations Manager

System Center Operations Manager зависит от sql Server Service Broker для реализации всех операций задачи. Если sql Server Service Broker отключен, все операции задачи будут затронуты. Результирующее поведение может отличаться в зависимости от задачи, инициированной. Поэтому важно проверить состояние sql Server Service Broker всякий раз, когда непредвиденное поведение наблюдается вокруг задачи в System Center Operations Manager.

Чтобы включить sql Server Service Broker, выполните следующие действия.

1. Выполните следующий запрос SQL:

   SELECT is_broker_enabled FROM sys.databases WHERE name='OperationsManager'
   

2. Пропустите этот шаг, если значение, отображаемое в is_broker_enabled поле, равно 1 (одно). В противном случае выполните следующие запросы SQL:

   ALTER DATABASE OperationsManager SET SINGLE_USER WITH ROLLBACK IMMEDIATE
   ALTER DATABASE OperationsManager SET ENABLE_BROKER
   ALTER DATABASE OperationsManager SET MULTI_USER
   

База данных хранилища данных Operations Manager

System Center — Operations Manager вставляет данные в хранилище данных отчетов практически в режиме реального времени, важно иметь достаточную емкость на этом сервере, который поддерживает запись всех данных, собираемых в хранилище данных отчетов. Как и в базе данных Operations Manager, наиболее критически важный ресурс в хранилище данных отчетов — это подсистема ввода-вывода хранилища. В большинстве систем нагрузки на хранилище данных отчетов похожи на базу данных Operations Manager, но могут отличаться. Кроме того, рабочая нагрузка, помещаемая в хранилище данных отчетов, по отчетам отличается от нагрузки, вложенной в базу данных Operations Manager по использованию консоли управления.

Факторы, влияющие на нагрузку на хранилище данных отчетов, включают:

• Скорость сбора операционных данных. Чтобы обеспечить более эффективную отчетность, хранилище данных отчетов вычисляет и сохраняет агрегированные данные в дополнение к ограниченному количеству необработанных данных. Выполнение этой дополнительной работы означает, что сбор операционных данных в хранилище данных отчетов может быть немного дороже, чем в базе данных Operations Manager. Эта дополнительная стоимость обычно распределяется по сниженной стоимости обработки данных обнаружения хранилищем данных отчетов и базой данных Operations Manager.
• Число одновременных пользователей отчетов или запланированного создания отчетов. Так как отчеты часто суммируют большие объемы данных, каждый пользователь отчетов может добавить значительную нагрузку на систему. Количество отчетов, выполняемых одновременно, и тип отчетов, выполняемых, влияют на общую потребность в емкости. Как правило, отчеты, запрашивающие большие диапазоны дат или большое количество объектов, требуют дополнительных системных ресурсов.

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

• Выберите соответствующую подсистему хранения. Так как хранилище данных отчетов является неотъемлемой частью общего потока данных через группу управления, важно выбрать соответствующую подсистему хранения для хранилища данных отчетов. Как и в базе данных Operations Manager, RAID 0 + 1 часто является лучшим выбором. Как правило, подсистема хранения для хранилища данных отчетов должна быть похожа на подсистему хранения для базы данных Operations Manager, а рекомендации, применимые к базе данных Operations Manager, также применяются к хранилищу данных отчетов.
• Рассмотрите возможность соответствующего размещения журналов данных и журналов транзакций. Что касается базы данных Operations Manager, разделение данных SQL и журналов транзакций часто является подходящим выбором по мере увеличения числа агентов. Если база данных Operations Manager и хранилище данных отчетов расположены на одном и том же сервере, и вы хотите разделить журналы данных и транзакций, необходимо поместить журналы транзакций для базы данных Operations Manager на отдельный физический том и диски спиндя из хранилища данных отчетов, чтобы получить любое преимущество. Файлы данных для базы данных Operations Manager и хранилища данных отчетов могут совместно использовать тот же физический том, если том обеспечивает достаточную емкость и производительность операций ввода-вывода диска не негативно влияет на функции мониторинга и отчетов.
• Рассмотрите возможность размещения хранилища данных отчетов на отдельном сервере из базы данных Operations Manager. Хотя развертывания с меньшим масштабом часто могут консолидировать базу данных Operations Manager и хранилище данных отчетов на одном сервере, можно разделить их по мере увеличения числа агентов и объема входящих операционных данных. Когда хранилище данных отчетов и сервер отчетов находятся на отдельном сервере из базы данных Operations Manager, вы можете повысить производительность отчетов.

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

Always On в SQL Server

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

При использовании System Center 2016 и более поздних версий — Operations Manager sql AlwaysOn предпочтительнее использовать отказоустойчивую кластеризацию, чтобы обеспечить высокий уровень доступности для баз данных. Все базы данных, кроме установки служб Reporting Services в собственном режиме, которые используют две базы данных для разделения постоянного хранилища данных от требований к временному хранилищу, можно разместить в группе доступности AlwaysOn.

Operations Manager 2022 позволяет вам настраивать и обновлять имеющиеся базы данных Operations Manager, используя текущую конфигурацию SQL Always-On без необходимости ее дополнительного изменения.

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

• Дополнительные сведения о предварительных требованиях AlwaysOn.
• Дополнительные сведения о настройке WSFC для групп доступности AlwaysOn.
• Дополнительные сведения о настройке группы доступности.

Примечание.

После развертывания Operations Manager на узлах SQL Server, участвующих в SQL AlwaysOn, чтобы включить строгую безопасность СРЕДЫ CLR, запустите скрипт SQL в каждой базе данных Operations Manager.

Строка Multisubnet

Operations Manager не поддерживает ключевые слова строка подключения (MultiSubnetFailover=True). Так как группа доступности имеет имя прослушивателя (известное как сетевое имя или точка доступа клиента в диспетчере кластеров WSFC) в зависимости от нескольких IP-адресов из разных подсетей, таких как при развертывании в конфигурации отработки отказа между сайтами, запросы на подключение клиента с серверов управления к прослушивателю группы доступности попадут во время ожидания подключения.

Рекомендуемый подход к работе с этим ограничением при развертывании узлов сервера в группе доступности в среде с несколькими подсетями состоит в следующем:

1. Задайте сетевое имя прослушивателя группы доступности, чтобы зарегистрировать только один активный IP-адрес в DNS.
2. Настройте кластер для использования низкого значения TTL для зарегистрированной записи DNS.

Эти параметры позволяют при отработке отказа на узел в другой подсети для быстрого восстановления и разрешения имени кластера с новым IP-адресом.

Выполните следующие команды PowerShell на любом из узлов SQL, чтобы изменить его параметры:

Import-Module FailoverClusters
Get-ClusterResource "Cluster Name"|Set-ClusterParameter RegisterAllProvidersIP 0
Get-ClusterResource "Cluster Name"|Set-ClusterParameter HostRecordTTL 300
Stop-ClusterResource "Cluster Name"
Start-ClusterResource "Cluster Name"
Start-ClusterGroup "Cluster Name"

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

Выполните следующие команды PowerShell на узле SQL, в котором размещен прослушиватель, чтобы изменить его параметры:

Import-Module FailoverClusters
Get-ClusterResource <Listener Cluster Resource name> | Set-ClusterParameter RegisterAllProvidersIP 0
Get-ClusterResource <Listener Cluster Resource name> | Set-ClusterParameter HostRecordTTL 300
Stop-ClusterResource <Listener Cluster Resource name>
Start-ClusterResource <Listener Cluster Resource name>
Start-ClusterGroup <Listener Cluster Group name>

Если кластеризованный или экземпляр AlwaysOn SQL используется для обеспечения высокой доступности, необходимо включить функцию автоматического восстановления на серверах управления, чтобы избежать перезапуска службы доступа к данным Operations Manager в любое время при отработки отказа между узлами. Дополнительные сведения о настройке см. в следующей статье базы знаний: служба управления System Center перестает отвечать на запросы после того, как экземпляр SQL Server переходит в автономный режим.

Оптимизация SQL Server

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

• Недостаточно распределения спинделей для LUN для поддержки требований операций ввода-вывода Operations Manager.
• Размещение журналов транзакций и файлов базы данных на одном томе. Эти две рабочие нагрузки имеют разные характеристики ввода-вывода и задержки.
• Неправильной конфигурацией TempDB является размещение, изменение размера и т. д.
• Неправильное разделение дисков томов, в котором размещаются журналы транзакций базы данных, файлы базы данных и TempDB.
• Используйте базовую конфигурацию SQL Server, например autoGROW для файлов базы данных и журналов транзакций, параметр MAXDOP для параллелизма запросов, создание нескольких файлов данных TempDB на ядро ЦП и т. д.

Конфигурация хранилища является одним из критически важных компонентов развертывания SQL Server для Operations Manager. Серверы баз данных, как правило, сильно привязаны к ввода-выводам из-за строгой операции чтения и записи базы данных и обработки журналов транзакций. Шаблон поведения ввода-вывода Operations Manager обычно составляет 80 % операций записи и 20 % операций чтения. В результате неправильной настройки подсистем ввода-вывода может привести к низкой производительности и работе систем SQL Server и становится заметной в Operations Manager.

Перед развертыванием SQL Server важно проверить структуру SQL Server, проверив проверку пропускной способности подсистемы ввода-вывода. Убедитесь, что эти тесты могут достичь требований ввода-вывода с приемлемой задержкой. Используйте служебную программу Diskspd для оценки емкости ввода-вывода подсистемы хранилища, поддерживающей SQL Server. В следующей статье блога, созданной членом группы файлового сервера в группе продуктов, приведены подробные рекомендации и рекомендации по выполнению стресс-тестирования с помощью этого средства с помощью кода PowerShell и записи результатов с помощью PerfMon. Первоначальные инструкции также приводятся во вспомогательном приложении для изменения размера Operations Manager.

Размер единицы выделения NTFS

Выравнивание тома, обычно называемое выравниванием сектора, должно выполняться в файловой системе (NTFS) всякий раз, когда на устройстве RAID создается том. Сбой в этом случае может привести к значительному снижению производительности и, как правило, результатом несоответствия секции с границами блока полосы. Это также может привести к неправильному использованию кэша оборудования, что приводит к неэффективному использованию кэша массива. При форматировании секции, которая будет использоваться для файлов данных SQL Server, рекомендуется использовать размер единицы выделения размером 64 КБ (то есть 65 536 байт) для данных, журналов и tempdb. Тем не менее следует учитывать, что использование размеров единиц выделения больше 4 КБ приводит к невозможности использовать сжатие NTFS на томе. Хотя SQL Server поддерживает только для чтения данные о сжатых томах, не рекомендуется.

Резервная память

Примечание.

Большая часть информации в этом разделе поступает от ДжонатанА Кехайяса в своем блоге , сколько памяти на самом деле требуется моему SQL Server? (sqlskills.com).

Не всегда легко определить нужный объем физической памяти и процессоров, выделяемых для SQL Server в поддержке System Center Operations Manager (или для других рабочих нагрузок за пределами этого продукта). Калькулятор размера, предоставляемый группой продуктов, предоставляет рекомендации на основе масштаба рабочей нагрузки, но их рекомендации основаны на тестировании, выполняемом в лабораторной среде, которая может или может не соответствовать фактической рабочей нагрузке и конфигурации.

SQL Server позволяет настроить минимальный и максимальный объем памяти , который будет зарезервирован и использован в процессе. По умолчанию SQL Server может динамически изменять требования к памяти на основе доступных системных ресурсов. Значение по умолчанию для минимальной памяти сервера равно 0, а значение по умолчанию для максимальной памяти сервера — 2 147 483 647 МБ.

Проблемы, связанные с производительностью и памятью, могут возникнуть, если не задано соответствующее значение для максимальной памяти сервера. Многие факторы влияют на то, сколько памяти необходимо выделить SQL Server, чтобы обеспечить поддержку других процессов, выполняемых в этой системе, таких как карточка HBA, агенты управления и антивирусная проверка в режиме реального времени. Если недостаточно памяти, ОПЕРАЦИОННая система и SQL будут страницы на диск. Это может привести к увеличению производительности дискового ввода-вывода, снижению производительности и созданию эффектов рябь, когда он становится заметным в Operations Manager.

Рекомендуется указать не менее 4 ГБ ОЗУ для минимальной памяти сервера. Это необходимо сделать для каждого узла SQL, в котором размещена одна из баз данных Operations Manager (операционные, хранилище данных, ACS).

Для максимальной памяти сервера рекомендуется изначально зарезервировать общую сумму:

• 1 ГБ ОЗУ для ОС
• 1 ГБ ОЗУ на каждые 4 ГБ установленной ОЗУ (до 16 ГБ ОЗУ)
• 1 ГБ ОЗУ на каждые 8 ГБ ОЗУ (выше 16 ГБ ОЗУ)

После установки этих значений отслеживайте счетчик Memory\Available MBytes в Windows, чтобы определить, можно ли увеличить объем памяти, доступной для SQL Server. Windows сигнализирует о низком уровне физической памяти в 96 МБ, поэтому в идеале счетчик не должен выполняться менее 200–300 МБ, чтобы обеспечить наличие буфера. Для серверов с 256 ГБ ОЗУ или выше, вероятно, потребуется убедиться, что он не выполняется менее 1 ГБ.

Имейте в виду, что эти вычисления предполагают, что SQL Server сможет использовать всю доступную память, если только вы не измените их на учет для других приложений. Рассмотрите конкретные требования к памяти для ос, других приложений, стека потоков SQL Server и других многопликаторов. Типичная формула будет ((total system memory) – (memory for thread stack) – (OS memory requirements) – (memory for other applications) – (memory for multipage allocators)), где память для стека потоков = ((max worker threads) (stack size)). Размер стека составляет 512 КБ для систем x86, 2 МБ для систем x64 и 4 МБ для систем IA64, и вы можете найти значение для максимальных рабочих потоков в столбце max_worker_count столбца sys.dm_os_sys_info.

Эти рекомендации также применяются к требованиям к памяти для SQL Server для запуска в виртуальной машине. Так как SQL Server предназначен для кэширования данных в буферном пуле, и обычно используется как можно больше памяти, может быть трудно определить идеальный объем ОЗУ. При снижении памяти, выделенной для экземпляра SQL Server, вы в конечном итоге достигнет точки, в которой объем памяти распределяется за более высокий доступ к диску ввода-вывода.

Чтобы настроить память SQL Server в среде, которая была чрезмерно подготовлена, начните с мониторинга среды и текущих метрик производительности, включая продолжительность жизни страницы диспетчера буферов SQL Server и чтение страниц/с, а также значения чтения на диске физического диска/с. Если в среде есть избыточный объем памяти, продолжительность жизни страницы увеличится на одну секунду без какого-либо уменьшения в рабочей нагрузке, из-за кэширования; значение страницы диспетчера буферов SQL Server будет низким после увеличения объема кэша. Кроме того, диск физического диска останется низким.

Понять базовые показатели среды можно уменьшить максимальный объем памяти сервера на 1 ГБ, а затем узнать, как это влияет на счетчики производительности (после утихает очистка исходного кэша). Если метрики остаются приемлемыми, уменьшите еще 1 ГБ, а затем снова выполните мониторинг, повторяясь по мере необходимости, пока не определите идеальную конфигурацию.

Дополнительные сведения см. в разделе "Параметры конфигурации памяти сервера".

Оптимизация TempDB

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

• Задайте для модели восстановления tempdb значение SIMPLE. Эта модель автоматически освобождает пространство журналов для уменьшения требований к пространству.
• Заранее выделите место для всех файлов tempdb, установив размер файла в значение, достаточное, чтобы гарантировать обычную рабочую нагрузку в среде. Он предотвращает слишком частое расширение tempdb, что может повлиять на производительность. База данных tempdb может быть настроена для автоматического увеличения, но это необходимо использовать для увеличения места на диске для незапланированных исключений.
• Создайте столько файлов, сколько необходимо для максимальной пропускной способности диска. Использование нескольких файлов снижает количество параметров хранения tempdb и повышает масштабируемость. Однако не создавайте слишком много файлов, так как это может снизить производительность и увеличить затраты на управление. В качестве общего руководства создайте один файл данных для каждого логического процессора на сервере (учет любых параметров маски сходства), а затем настройте количество файлов вверх или вниз по мере необходимости. Как правило, если число логических процессоров меньше или равно 8, используйте то же число файлов данных, что и логические процессоры. Если число логических процессоров больше 8, используйте восемь файлов данных, а затем, если состязание продолжается, увеличьте число файлов данных на несколько 4 (до числа логических процессоров), пока не будет сокращено до допустимых уровней или внести изменения в рабочую нагрузку или код. Если состязание не уменьшается, возможно, потребуется увеличить количество файлов данных.
• Сделайте каждый файл данных одинаковым размером, что позволяет обеспечить оптимальную производительность пропорциональной заливки. Равный размер файлов данных имеет решающее значение, так как алгоритм пропорциональной заливки основан на размере файлов. Если файлы данных создаются с неравными размерами, алгоритм пропорциональной заливки пытается использовать самый большой файл для распределения GAM вместо распространения выделения между всеми файлами, тем самым побеждая цель создания нескольких файлов данных.
• Поместите базу данных tempdb в быструю подсистему ввода-вывода с помощью твердотельных дисков для оптимальной производительности. Если имеется много непосредственно присоединенных дисков, то используйте чередование дисков.
• Расположите базу данных tempdb на дисках, отличных от используемых пользовательскими базами данных.

Чтобы настроить tempdb, можно выполнить следующий запрос или изменить его свойства в Management Studio.

USE [tempdb]
GO
DBCC SHRINKFILE (N'tempdev' , 8)
GO
USE [master]
GO
ALTER DATABASE [tempdb] MODIFY FILE ( NAME = N'tempdev', NEWNAME = N'tempdb', SIZE = 2097152KB , FILEGROWTH = 512MB )
GO
ALTER DATABASE [tempdb] ADD FILE ( NAME = N'tempdb2', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\tempdb2.mdf' , SIZE = 2097152KB , FILEGROWTH = 512MB )
GO

Запустите запрос SELECT * from sys.sysprocesses T-SQL, чтобы обнаружить результаты распределения страниц для базы данных tempdb. В выходных данных системной таблицы ресурс ожидания может отображаться как "2:1:1" (страница PFS) или "2:1:3" (страница "Общая глобальная карта выделения"). В зависимости от степени состязания это также может привести к тому, что SQL Server не отвечает на короткие периоды. Другим подходом является изучение динамических административных представлений [sys.dm_exec_request или sys.dm_os_waiting_tasks]. Результаты показывают, что эти запросы или задачи ожидают ресурсов tempdb и имеют аналогичные значения, как выделено ранее при выполнении запроса sys.sysprocesses .

Если предыдущие рекомендации не значительно сокращают распределение, а состязание находится на страницах SGAM, реализуйте флаг трассировки -T1118 в параметрах запуска ДЛЯ SQL Server, чтобы флаг трассировки оставался в силе даже после перезапуска SQL Server. В этом флаге трассировки SQL Server выделяет полные экстенты для каждого объекта базы данных, тем самым устраняя противоречие на страницах SGAM.

Примечание.

Этот флаг трассировки влияет на каждую базу данных в экземпляре SQL Server.

Максимальная степень параллелизма

Конфигурация SQL Server по умолчанию для небольших и средних развертываний Operations Manager подходит для большинства потребностей. Однако, когда рабочая нагрузка группы управления масштабируется вверх к сценарию корпоративного класса (обычно 2000+ управляемых агентом систем и расширенной конфигурации мониторинга, которая включает мониторинг уровня обслуживания с расширенными синтетическими транзакциями, мониторинг сетевых устройств, кроссплатформенный и т. д.) необходимо оптимизировать конфигурацию SQL Server, описанную в этом разделе документа. Один из вариантов конфигурации, которые не обсуждались в предыдущих рекомендациях, — MAXDOP.

Параметр конфигурации Microsoft SQL Server max degree of parallelism (MAXDOP) определяет количество процессоров, используемых для выполнения запроса в параллельном плане. Этот параметр определяет вычислительные и потоковые ресурсы, используемые для операторов плана запросов, которые выполняют работу параллельно. В зависимости от того, настроен ли SQL Server на симметричном многопроцессорном компьютере (SMP), компьютере с неоднородным доступом к памяти (NUMA) или процессорами с поддержкой гиперпотока, необходимо настроить параметр максимального уровня параллелизма соответствующим образом.

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

Хранимые процедуры и запросы, предварительно определенные в Operations Manager, так как они связаны с операционной, хранилищем данных и даже базой данных аудита, не включают параметр MAXDOP, так как во время установки невозможно динамически запрашивать количество процессоров, представленных операционной системе, и не пытается жестко закодировать значение этого параметра, что может иметь негативные последствия при выполнении запроса.

Примечание.

Максимальный уровень конфигурации параллелизма не ограничивает количество процессоров, которые использует SQL Server. Чтобы настроить количество процессоров, используемых SQL Server, используйте параметр конфигурации маски сходства.

• Для серверов, использующих более восьми процессоров, используйте следующую конфигурацию: MAXDOP=8
• Для серверов, использующих восемь или меньше процессоров, используйте следующую конфигурацию: MAXDOP=0 до N

  Примечание.

  В этой конфигурации N представляет количество процессоров.