Главная » Microsoft SQL Server, Базы данных » Параметры конфигурации – ЧАСТЬ 3

0

Сервер

Management Studio

EXEC sp_configure ‘query wait’

Во вкладке Processors диалогового окна Server Proeprties (рис. 34.6) определяется режим работы сервера баз данных в симметричных многопроцессорных системах. Большая часть этих параметров не влияет на работу сервера в однопроцессорных компьютерах.

Назначение потоков процессорам

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

Рис. 34.6. На странице Processors отображаются доступные в системе процессоры и определяется порядок их использования сервером баз данных

П     Так как процесс переключения между процессами создает дополнительную на-

грузку на систему, Windows получит определенные преимущества, если в системе If     существует один процессор, недоступный серверу баз данных. Если на сервере

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

В Management Studio взаимосвязь с процессорами конфигурируется посредством установки флажков во вкладке Processors (см. рис. 36.4).

В программном коде доступность отдельных процессоров для сервера баз данных конфигурируется установкой соответствующих битов в параметре маски родства affinity mask с помощью хранимой процедуры sp_conf igure. Поскольку в битовом представлении число 3 выглядит как 0000011, в следующем примере серверу баз данных становятся доступными процессоры с номерами 0 и 1:

ЕХЕС sp_configure ‘affinity mask’, 3 RECONFIGURE

Нулевое значение параметра affinity mask определяет доступность серверу На заметку баз данных всех процессоров компьютера.

Максимальное число рабочих потоков

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

?               По одному потоку для каждого сетевого подключения.

?               Один поток для обслуживания контрольных точек базы данных.

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

В зависимости от количества подключений и доли времени, в течение которого соединение активизировано (а не простаивает), установка количества рабочих потоков в значение, меньшее числа подключений, может форсировать создание пула подключений, экономию памяти и увеличение производительности.

В программном коде максимальное количество рабочих потоков устанавливается путем присвоения значения параметру max worker threads с помощью хранимой процедуры sp_conf igure:

ЕХЕС sp_configure ‘max worker threads’, 64 RECONFIGURE

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

Повышение приоритета

Различные процессы в операционной среде Windows выполняются с разными уровнями приоритета, варьирующимися от 0 до 31. Процессы с большим уровнем приоритета выполняются первыми, поэтому эти уровни резервируются для процессов операционной системы. Обычно система Windows выделяет для приложений следующие уровни приоритетов: 4 (низкий), 7 (обычный), 13 (высокий) и 24 (реального времени). По умолчанию SQL Server устанавливается с обычным уровнем приоритета — 7.

В однопроцессорных компьютерных системах, а также когда наряду с SQL Server в системе выполняются другие фоновые приложения, желательно установить обычный уровень приоритета. Искусственное завышение приоритета в этой ситуации может нарушить гладкость операций. В то же время в условиях многопроцессорного выделенного сервера баз данных рекомендуется установить для приоритета значение 13. Для этого параметру повышения приоритета priority boost следует присвоить значение 1:

ЕХЕС sp_configure ‘priority boost’, 1 RECONFIGURE

Параметр Lightweight Pooling

Еще один параметр, предназначенный для симметричных многопроцессорных систем, позволяет уменьшить нагрузку, вызываемую частым переключением процессов с одного процессора на другой. Включение поддержки волокон Windows NT приводит к уменьшению числа рабочих потоков, так как некоторые потоки ассоциируются с дополнительными волокнами. Уменьшение количества рабочих потоков уменьшает дополнительную нагрузку, вызываемую частым переключением потоков, и, следовательно, повышает общую производительность. В Management Studio этот параметр носит название Use Windows NT Fibres; в программном коде он соответствует параметру lightweight pooling.

ЕХЕС sp_configure ‘lightweight pooling’, 1 RECONFIGURE

Параллелизм

Редакция SQL Server Enterprise Edition (а также редакции Developer и Evaluation, поскольку они отличаются от Enterprise только условиями лицензирования) позволяет выполнять сложные запросы, параллельно используя несколько процессоров. Это может оказаться полезным, особенно в ситуациях, когда запрос консолидирует все строки базы данных объемом в 20 Гбайт. Но что можно сказать об остальных пользователях, которые вынуждены ожидать, пока один пользователь не освободит занятые им процессоры? Решение проблемы лежит в ограничении числа процессоров, которые могут быть задействованы для распараллеливания выполнения одного запроса, и в установке порога стоимости (в секундах оценочного времени выполнения), после выхода за который запрос становится кандидатом на распараллеливание вычислений.

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

Я рекомендую для распараллеливания вычисления запросов сделать доступными половину доступных процессоров за исключением одного (см. раздел “Назначение потоков процессорам”). Например, если сервер имеет восемь процессоров и семь из них доступны SQL Server, для параллельных вычислений лучше использовать три процессора. Так как распараллеливание вычислений может существенно повысить производительность, вы можете немного занизить порог времени выполнения, чтобы как можно большее количество запросов могло выиграть от параллелизма.

В программном коде параллелизм запросов настраивается с помощью параметра max degree of parallelizm и cost threshold for parallelizm. Установка первого из них в значение 0 позволяет сделать доступными для распараллеливания выполнения запросов все процессоры:

EXEC sp_configure ‘max degree of parallelism’, 1 EXEC sp_configure ‘cost threshold for parallelism’, 1 RECONFIGURE

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

Параметры конфигурирования системы безопасности

Параметры конфигурирования системы безопасности, показанные в табл. 34.4, используются для управления функциями защиты SQL Server.

Параметры системы безопасности, установленные в процессе инсталляции сервера, представлены во вкладке Security диалогового окна Server Properties (рис. 34.7), поэтому их конфигурацию можно скорректировать уже после установки сервера. Параметры модели аутентификации и учетных записей Windows в SQL Server — такие же, как и при установке.

Таблица 34.4. Параметры конфигурации системы безопасности

Параметр

Уровень

Графический интерфейс установки

Программная

установка

Режим аутентификации

Сервер

Management Studio

-

Уровень аудита системы безопасности

Сервер

Management Studio

-

Учетная запись автозапуска

Сервер

Management Studio

-

Режим аудита С2

Сервер

EXEC sp_configure ‘C2 audit mode’

Цепочки собственности между базами данных Сервер

Management Studio

-

Puc. 34.7. Страница Security диалогового окна Management Studio

Уровень аудита системы безопасности

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

Защита С2

При конфигурировании SQL Server для уровня защиты С2 включение свойства С2 Audit Mode приведет к отказу в работе сервера, если он не будет способен записать информацию в журнал аудита системы безопасности. Этот параметр можно установить только программным путем — он недоступен в интерфейсе Management Studio:

Источник: Нильсен, Пол. Microsoft SQL Server 2005. Библия пользователя. : Пер. с англ. — М. : ООО “И.Д. Вильямс”, 2008. — 1232 с. : ил. — Парал. тит. англ.

По теме:

  • Комментарии