Разрешение наиболее распространенных проблем производительности

Для сохранения данных производительности в файле журнала выполните следующие шаги:

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

Enterprise Manager

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

В окне Enterprise Manager раскройте Microsoft SQL Server, раскройте SQL Server Group, раскройте сервер, раскройте папку Management и раскройте папку Current Activity (рис. 36.7). Папка Current Activity (Текущие операции) содержит три папки: Process Info (Информация о процессах), Locks/Process ID (Блокировки/Идентификаторы процессов) и Locks/Object (Блокировки/Объекты).

Щелкните на папке Process Info, чтобы увидеть следующую информацию: имена пользователей, подсоединенных в данный момент к SQL Server (колонка User); идентификатор процесса пользователя (Process ID); состояние процесса пользователя (running [выполняется], sleeping [неактивное состояние] или background [фоновый режим]); базу данных, к которой подсоединен каждый пользователь (Database); команды (Commands) и приложения (Application), выполняемые каждым пользователем; время ожидания (Wait time), то есть время, которое ждет пользователь, пока не получит доступ к какому-либо ресурсу; показатели использования ЦП, физического ввода-вывода и памяти каждым процессом; и состояние блокировки каждого процесса (блокирует ли данный процесс другие процессы или блокирован другими процессами). Чтобы увидеть всю эту информацию, вам придется выполнить прокрутку вправо. На рис 36.8(рис 36.8) Раскрытая папка Current Activity (Текущие операции) в окне Enterprise Manager(рис 36.7) Информация папки Process Info (Информация о процессах) в окне Enterprise Manager

Щелкните на папке Locks / Process ID для просмотра в правой панели списка системных идентификационных номеров процессов (SPID) для текущих активных процессов (рис. 36.9). Дважды щелкните на каком-либо из SPID-номеров в правой панели, чтобы появилось диалоговое окно Process Details (Подробности процесса) (рис. 36.10). В этом диалоговом окне показан последний оператор T-SQL, выполненный выбранным процессом.(рис 36.10) SPID-номера, показанные в панели Locks / Process ID(рис 36.9) Диалоговое окно Process Details

Раскройте папку Locks / Process ID для просмотра в левой панели SPID-номеров текущих процессов (рис. 36.11).

Щелкните на каком-либо SPID-номере в левой панели, чтобы увидеть информацию о блокировках для этого процесса в правой панели (рис. 36.11). В эту информацию включен тип блокировки (Lock type), режим блокировки (Mode), состояние блокировки (Status) и владелец блокировки (Owner). Может быть указан один из следующих типов блокировки.

RID. Блокировка строк.

KEY.Блокировка строк внутри индекса.

PAG. Блокировка страницы данных или индекса.

(рис 36.11) Раскрытая папка Locks / Process ID

TAB. Блокировка таблицы, включая все страницы данных и индекса для этой таблицы.

DB. Блокировка базы данных.

Хранимая процедура sp_who

Вы можете также просматривать информацию об активных процессах, запустив следующую команду в Query Analyzer или с помощью OSQL:

sp_who active
GO

Результаты выполнения этой команды в Query Analyzer показаны на рис. 36.14. Если какой-либо процесс блокирован, то в колонке "blk" показан SPID-номер процесса, который его блокирует.

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

Вам следует время от времени выполнять мониторинг блокировок, чтобы выявлять процессы, которые удерживают блокировку слишком долго, и процессы, которые бывают блокированы слишком часто (находятся в состоянии WAIT ) из-за монопольных блокировок или блокировок по таблицам, которые удерживаются другими процессами. Но обычно в случае проблемы блокировки ваши пользователи будут жаловаться на слишком большое время отклика. Если блокирование возникает слишком часто или длится слишком долго, то вам потребуется определить, какие процессы удерживают монопольные блокировки или блокировки по таблицам (что может быть причиной блокирования), и выполнить мониторинг операторов SQL Server, которые запускают эти процессы. Затем попытайтесь оптимизировать, если возможно, эти операторы, чтобы они быстрее освобождали эти блокировки и не захватывали монопольные блокировки по таблицам. Обычно для выполнения процесса требуется больше времени, если этому процессу приходится ждать освобождения какой-либо блокировки. Поэтому снижение конкуренции блокировок может способствовать сокращению времени отклика.

Наиболее характерные узкие места, снижающие производительность

Теперь, узнав, как использовать средства мониторинга производительности, такие как System Monitor, Enterprise Manager, Query Analyzer и Profiler, вы готовы к тому, чтобы справляться с проблемами узких мест, снижающих производительность. В этом разделе мы рассмотрим некоторые из наиболее характерных узких мест, снижающих производительность, и различные решения этих проблем. Многие из этих узких мест тесно связаны друг с другом, и одно узкое место может "маскироваться" под другое. Вы должны искать как аппаратные, так и программные узкие места, поскольку причиной многих проблем производительности являются комбинации узких мест. Причиной аппаратных узких мест могут становиться такие компоненты оборудования, как ЦП, память и подсистема ввода-вывода; причиной программных узких мест могут становиться приложения SQL Server и операторы SQL. Мы рассмотрим подробнее каждый из этих типов проблем в следующих разделах.

Центральный процессор (ЦП)

Одной из наиболее распространенных проблем производительности является просто недостаток мощности. Процессорная мощность системы определяется количеством, типом и скоростью центральных процессоров (ЦП) в этой системе. Если вашей системе недостает мощности ЦП, то она не может достаточно быстро обрабатывать транзакции, как это требуется пользователям. Чтобы использовать System Monitor для определения процента использования ЦП, проверяйте счетчик %Processor Time объекта Processor. (Выберите все экземпляры ЦП, если у вас многопроцессорная система.) Если ваши ЦП работают с загрузкой 75% или выше в течение длительных периодов времени (75 % – желательный максимум согласно правилам лекции 6), то в вашей системе, скорее всего, имеется проблема узкого места, связанного с ЦП. Если вы постоянно видите процент использования ЦП не ниже 60 %, то вам, видимо, поможет добавление более быстрых ЦП или увеличение количества ЦП.

Выполните мониторинг других характеристик системы, прежде чем увеличивать мощность ЦП. Например, если ваши операторы SQL сформированы неэффективно, то ваша система, видимо, выполняет намного больше операций обработки, чем это требуется, и оптимизация этих операторов, возможно, снизит степень использования ЦП. Или, предположим, что коэффициент попадания в кэш-память (счетчик Cache hit ratio) для кэша данных SQL Server ниже 90 %. Возможно, вы должны добавить память для кэша данных (увеличив значение параметра max server memory или добавив физическую память к системе). Это позволит увеличить количество данных, помещаемых в кэш, и, тем самым, снизить объем дисковых физических операций ввода-вывода, что приведет к снижению процента использования ЦП, поскольку на обработку запросов ввода-вывода будет уходить меньше времени. Вы можете иногда повышать производительность системы, просто за счет добавления процессоров, особенно в том случае, если вы начинаете работу с однопроцессорной системы. Однако не все приложения допускают масштабирование на многопроцессорные системы. SQL Server предусматривает масштабирование, но не все операторы SQL, которые могут у вас использоваться, допускают масштабирование. На одном ЦП будет одновременно выполняться только один процесс, и одного ЦП достаточно для одного оператора SQL Server. Чтобы повысить производительность за счет использования нескольких процессоров, ваша система SQL Server должна параллельно выполнять несколько операторов, которые могут одновременно обрабатываться на различных ЦП.

Обычно вы можете почти всегда повысить производительность за счет использования большего количества более быстрых ЦП. Однако в некоторых случаях при добавлении более быстрых ЦП вы должны увеличить память и мощность ввода-вывода, чтобы другие компоненты не стали причиной узкого места. Например, если у вас сначала была проблема узкого места из-за ЦП и вы разрешили эту проблему, добавив еще один ЦП, то ваша система, видимо, сможет выполнять больше работы, что приведет к увеличению количества дисковых операций ввода-вывода. В результате может возникнуть проблема узкого места из-за дисковой подсистемы ввода-вывода. Кроме того, убедитесь, что новые процессоры, которые вы хотите добавить, имеют кэш уровня 2 (Level 2 [L2]). Чем больше кэш ЦП, тем выше производительность, особенно в многопроцессорной системе.

Если вы действительно решили увеличить процессорную мощность, то можете добавить новые ЦП или заменить существующие ЦП на более мощные. Например, если в вашей системе два ЦП, но ее можно расширить до четырех ЦП, добавьте еще два ЦП того же типа или установите четыре новых, более быстрых ЦП. Если ваша система уже содержит максимальное количество ЦП и вам нужно увеличить процессорную мощность, постарайтесь получить более быстрые ЦП для их замены. Например, предположим, что у вас четыре ЦП, работающих со скоростью 200 МГц. Вы можете заменить их четырьмя ЦП со скоростью 500 МГц. Более быстрые ЦП способствуют сокращению времени обработки.

Память

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

В некоторых случаях недостаточное количество памяти может приводить к узкому месту за счет диска из-за увеличения количества дисковых физических операций ввода-вывода, связанного с тем, что система не может эффективно использовать кэш. Чтобы увидеть, сколько системной памяти использует SQL Server, запустите System Monitor, чтобы проверить счетчик общей памяти сервера Total Server Memory (KB) для объекта SQL Server: Memory Manager. Если SQL Server не использует ожидаемого количества памяти, то вам, возможно, требуется изменить параметры конфигурирования памяти, описанные в разделе "Параметры конфигурирования SQL Server" ниже в этой лекции.

Чтобы определить, хватает ли кэш-памяти для SQL Server, используйте System Monitor, чтобы проверить счетчик Buffer Cache Hit Ratio объекта SQL Server: Buffer Manager. Общее правило состоит в том, что счетчик Cache hit ratio должен давать значения не меньше 90%. Увеличьте размер памяти для кэша, если этот показатель меньше 90%. Отметим, что в некоторых системах счетчик Cache hit ratio никогда не достигает 90% из-за особенностей используемого приложения. Это может быть в случаях, когда повторное использование страниц данных происходит редко и система часто очищает страницы данных в кэше для размещения новых страниц.

Подсистема ввода-вывода

Узкие места, возникающие в подсистеме ввода-вывода, – это наиболее распространенные проблемы оборудования для систем баз данных. Плохо сконфигурированные подсистемы ввода-вывода уступают по своему влиянию на производительность только неэффективным операторам SQL. К счастью, проблемы подсистемы ввода-вывода относятся к тем проблемам производительности, которые наиболее легко поддаются разрешению. Во многих случаях добавление дисков полностью устраняет эти проблемы.

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

В большинстве случаев проблемы производительности подсистем ввода-вывода возникают потому, что был неправильно спланирован состав соответствующей подсистемы ввода-вывода. О планировании состава системы см. лекции 5 и 6, но мы все же дадим здесь краткий обзор этой темы.

Планирование состава (sizing) подсистемы ввода-вывода необходимо, как уже говорилось, из-за ограниченности количества операций ввода-вывода в секунду, которые могут выполняться одним дисководом. Если на диске выполняются преимущественно последовательные операции ввода-вывода, как это происходит с журналом транзакций, то он может осуществлять, например, более 150 операций в секунду без какой-либо перегрузки. (Как уже говорилось, перегрузки приводят к длительным задержкам.) С другой стороны, если на диске выполняются операции ввода-вывода с произвольным доступом, что характерно для файлов данных, то его производительность может составлять только 85 операций в секунду. При высоких требованиях к вводу-выводу все более возрастает время задержек.

Чтобы определить, не перегружены ли ваши диски, выполняйте мониторинг счетчиков объектов PhysicalDisk и LogicalDisk в System Monitor. Эти счетчики (некоторые из них описаны более подробно ниже в этом разделе) выполняют сбор данных об интенсивности физических и логических операций ввода-вывода на диске, таких как число операций чтения и записи в секунду. Эти счетчики активизируются во время инсталляции операционной системы, но вам следует знать, как их активизировать и отключать. Они используют системные ресурсы, такие как время ЦП, когда они собирают статистику, поэтому вам следует активизировать их, только если вам нужен мониторинг ввода-вывода в системе. Чтобы активизировать или отключить эти счетчики, вам нужно активизировать или отключить оператор Windows NT/2000 DISKPERF.

Чтобы определить, активизирован ли оператор DISKPERF, запустите следующий оператор в командной строке:

diskperf

Если DISKPERF активизирован, то появится следующее сообщение: "Physical Disk Performance counters on this system are currently set to start at boot" (Счетчики производительности физических дисков в этой системе в настоящее время установлены для запуска при загрузке системы). Если DISKPERF отключен, то появится следующее сообщение: "Both Logical and Physical Disk Performance counters on this system are now set to never start" (Оба счетчика производительности [для логического и физического диска] не будут запускаться).

Чтобы активизировать оператор DISKPERF, если он отключен, введите следующий оператор в командной строке:

diskperf -Y

Чтобы отключить DISKPERF, запустите следующий оператор:

diskperf -N

Чтобы начали действовать изменения, внесенные DISKPERF, вы должны перезагрузить компьютер. Чтобы увидеть другие параметры для DISKPERF, введите следующий оператор:

diskperf ?

Особенно важны счетчики Disk Writes/Sec (Число операций записи/сек), Disk Reads/Sec (Число операций чтения/сек), Avg. Disk Queue Length (Средняя длина очереди на диск), Avg. Disk Sec/Write (Среднее время одной операции записи) и Avg. Disk Sec/Read. (Среднее время одной операции чтения). Эти счетчики помогают вам определить, не перегружена ли ваша дисковая подсистема. Эти счетчики включены в оба объекта – PhysicalDisk и LogicalDisk. Чтобы получить подробное описание информации, которую предоставляют эти счетчики, щелкните на кнопке Explain (Объяснить) в диалоговом окне Add Counters, когда вы добавляете соответствующий счетчик в System Monitor.

Рассмотрим пример использования этих счетчиков. Предположим, вы считаете, что у вас имеется проблема узкого места подсистемы ввода-вывода. Вам следует проверить счетчики Avg. Disk Sec/Transfer (Средняя длительность одной передачи на диске), Avg. Disk Sec/Read и Avg. Disk Sec/Write объекта PhysicalDisk, поскольку они отражают задержку (ожидание) на диске (время, которое требуется диску для выполнения операции чтения или записи), а повышение длительности задержки является признаком того, что у вас перегружены дисководы или дисковая матрица. Общее правило состоит в том, что нормальные показания этих счетчиков должны составлять от 1 до 15 миллисекунд (от 0,001 до 0,015 секунды), но вам не следует беспокоиться, если в периоды пиковой нагрузки задержка составит 20 миллисекунд (0,020 секунды). Но если значения более 20 миллисекунд, то в вашей системе явно имеется проблема производительности, связанная с подсистемой ввода-вывода.

Вы должны также проверять счетчики Disk Writes/Sec и Disk Reads/Sec. Предположим, эти счетчики показывают, что на диске выполняется 20 операций записи и 20 операций чтения в секунду, то есть всего 40 операций ввода-вывода в секунду, а мощность диска составляет 85 операций ввода-вывода в секунду. И если в то же самое время диск дает большие задержки, то, возможно, это говорит о неисправности данного диска. А теперь предположим, что на этом диске выполняется 100 операций в секунду и длительность задержек составляет 20 миллисекунд или больше. В этом случае вам требуется увеличить количество дисков, чтобы повысить производительность.

Чтобы определить, сколько операций ввода-вывода выполняет ваша система, когда вы используете RAID-матрицу, разделите количество операций ввода-вывода в секунду, которое вы видите в System Monitor, на количество дисков этой матрицы, и умножьте на дополнительный коэффициент для матрицы RAID. В табл. 36.1 приводится количество физических операций, генерируемых для чтения и записи при использовании технологии RAID.

Обычно наилучшим способом устранения узкого места подсистемы ввода-вывода является просто добавление дисков. Но не забудьте проверить другие возможные причины узкого места в подсистеме ввода-вывода, такие как низкое значение коэффициента попадания в кэш и транзакции, в которых выполняется больше операций ввода-вывода, чем это необходимо. (Как уже говорилось, в большинстве случаев коэффициент попадания в кэш меньше 90% считается слишком низким.) Если вы нашли узкое место подсистемы ввода-вывода, посмотрите указания в лекции 6, чтобы определить количество дисков, необходимое вашей системе.

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

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

Приложения

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

Оптимизируйте планы исполнения

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

Используйте индексы осмысленно

Правильное использование индексов является критически важным для получения высокой производительности (см лекции 17 и 35). Для поиска нужных данных с помощью индекса может потребоваться всего лишь 10–20 операций ввода-вывода, в то время как для поиска нужных данных путем сканирования таблиц могут потребоваться тысячи или миллионы операций ввода-вывода. Однако индексы следует использовать с осторожностью. Напомним, что при модифицировании данных таблицы с помощью оператора INSERT, UPDATE или DELETE происходит автоматическое обновление индекса или индексов, связанных с этими данными, что требует выполнения соответствующих операций ввода-вывода в дополнение к операциям непосредственного модифицирования таблицы. Следите за тем, чтобы не создавать слишком много индексов; иначе дополнительная нагрузка, связанная с поддержкой этих индексов, будет приводить к снижению производительности.

Используйте хранимые процедуры

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

Параметры конфигурирования SQL Server

SQL Server 2000 является практически самонастраиваемой системой, но вы все же можете изменять способ работу вашей системы, модифицируя значения определенных параметров конфигурирования. В этом разделе вы узнаете, как конфигурировать эти параметры и как они влияют на работу вашей системы. Скорее всего, вам не потребуется изменять эти параметры, но знание их возможностей позволяет вам решать, нужно ли вам их изменение. Вы можете конфигурировать эти параметры с помощью Enterprise Manager или с помощью хранимой процедуры T-SQL sp_configure.

Чтобы использовать Enterprise Manager, щелкните правой кнопкой мыши на имени сервера, который вы хотите конфигурировать, и выберите из контекстного меню пункт Properties (Свойства), чтобы появилось окно SQL Server Properties. Это окно содержит девять вкладок, и каждая вкладка содержит параметры, которые вы можете конфигурировать. Эти вкладки и соответствующие параметры описаны в следующих разделах.

Используя sp_configure для конфигурирования этих параметров, вы должны помнить, что определенные параметры считаются дополнительными (advanced options). (В следующих разделах указывается, какие параметры являются дополнительными.) Для изменения какого-либо дополнительного параметра с помощью sp_configure вы должны задать для параметра show advanced options (показать дополнительные параметры) значение 1 (активизировать). Для этого параметра по умолчанию задано значение 0 (деактивизировать). (Этот параметр не оказывает влияния на дополнительные параметры, если вы используете Enterprise Manager.) Чтобы активизировать параметр show advanced options, используйте следующий оператор:

sp_configure "show advanced options", 1 
GO

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

sp_configure "имя параметра", значение

Параметр affinity mask

Параметр affinity mask (маска "родственности") используется, чтобы указывать, на каких ЦП могут выполняться потоки SQL Server в многопроцессорной среде. Значение 0 (принятое по умолчанию) указывает, что родственность потоков определяется алгоритмами планировщика Windows 2000. Ненулевое значение задает битовую маску, определяющую ЦП, на которых могут выполняться потоки SQL Server. Десятичное значение 1 (или двоичное значение маски 00000001) указывает, что может использоваться только ЦП 1; значение 2 (или 00000010) указывает использование только ЦП 2; 3 (или 00000011) указывает использование ЦП 1 и ЦП 2, и т.д.

Этот параметр относится к группе дополнительных параметров, поэтому для его конфигурирования с помощью sp_configure вы должны задать для параметра show advanced options значение 1. Вы можете также конфигурировать параметр affinity mask с помощью Enterprise Manager. Для этого щелкните на вкладке Processor (Процессор) в окне SQL Server Properties и в секции Processor Control (Управление процессорами) установите флажки перед каждым ЦП (CPU), который хотите использовать для SQL Server. Щелкните на кнопке Apply (Применить) и затем щелкните на кнопке OK, чтобы сохранить данное изменение. Чтобы это изменение начало действовать, вы должны закрыть и перезапустить SQL Server.

В системе, выделенной только для SQL Server, вы должны задать такое значение параметра affinity mask, чтобы использовать для SQL Server все ЦП. В системе, которая не полностью выделена для SQL Server (то есть содержит другие процессы, которым требуется время ЦП) вам, возможно, потребуется задать такую маску, чтобы для SQL Server использовались все ЦП, кроме одного.

Параметр lightweight pooling

Параметр lightweight pooling (упрощенная организация пула) используется чтобы сконфигурировать SQL Server для использования упрощенных потоков (или "волокон" – fibers). Использование "волокон" может снизить количество переключений контекста за счет того, что планирование процессов выполняет SQL Server (а не планировщик Windows NT или Windows 2000). Если ваше приложение выполняется в многопроцессорной системе и вы видите много переключений контекста, то можете попытаться задать для параметра lightweight pooling значение 1, которое активизирует упрощенную организацию пула, и затем снова выполнить мониторинг количества переключений контекста, чтобы убедиться в снижении этого количества. Значение по умолчанию – 0 (запрещение использования "волокон").

Параметр lightweight pooling относится к группе дополнительных параметров, поэтому его можно конфигурировать с помощью sp_configure, если для параметра show advanced options задано значение 1. Вы можете также конфигурировать lightweight pooling с помощью Enterprise Manager. Щелкните на вкладке Processor в окне SQL Server Properties и в секции Processor Control установите флажок Use Windows NT Fibers (Использовать "волокна" Windows NT) для его активизации или сбросьте этот флажок для деактивизации параметра. Щелкните на кнопке Apply, щелкните на кнопке OK и затем закройте и перезапустите SQL Server, чтобы этот параметр начал действовать.

Параметр max server memory

SQL Server динамически выделяет память. Чтобы задать максимальное количество памяти (в мегабайтах), которое SQL Server может выделить для буферного пула, вы можете использовать параметр max server memory (максимальная память для сервера). Поскольку SQL Server требуется определенное время для освобождения памяти, если у вас есть другие приложения, которым периодически нужна память, то для параметра max server memory можно задать такое значение, чтобы SQL Server оставлял определенную часть памяти свободной для других приложений. Значение по умолчанию – 2147483647 – означает, что SQL Server будет забирать у системы максимально возможное количество памяти, динамически освобождая память, когда она требуется другим приложениям, и снова захватывая память, когда эти приложения освобождают ее. Это рекомендованное значение для выделенной системы SQL Server. Если вы хотите изменить это значение, рассчитайте максимальный объем памяти, который вы можете предоставить SQL Server, вычитая из полного объема физической памяти количество памяти, необходимое для Windows 2000, а также для любых приложений, не относящихся к SQL Server.

Этот параметр относится к группе дополнительных параметров, поэтому для его конфигурирования с помощью sp_configure вы должны задать значение 1 для параметра show advanced options. Для задания этого параметра с помощью Enterprise Manager щелкните на вкладке Memory (Память) в окне SQL Server Properties и используйте движок Maximum (MB) (Максимум [Мб]). Затем щелкните опцию Dynamically Configure SQL Server Memory (Динамическое конфигурирование памяти SQL Server). Этот параметр начинает действовать сразу – без необходимости закрытия и повторного запуска SQL Server. (Если щелкнуть опцию Use A Fixed Memory Size [Использовать фиксированный размер памяти], то SQL Server выделит память до указанного объема и затем уже не будет освобождать память.)

Параметр min server memory

Параметр min server memory (минимальная память для сервера) используется для указания минимального количества памяти (в мегабайтах), которое должно выделяться для буферного пула SQL Server. Устанавливать этот параметр полезно в системах, где SQL Server, возможно, резервирует слишком много памяти для других приложений. Например, в среде, где данный сервер используется для служб печати и файловых служб, а также для служб базы данных, SQL Server должен "уступать" слишком много памяти другим приложениям. Это приводит к увеличению времени отклика для пользователей. Значение по умолчанию min server memory равно 0, что позволяет SQL Server динамически забирать и освобождать память. Это рекомендованное значение, но вам может потребоваться его изменение, если ваш сервер не полностью выделен для SQL Server.

Этот параметр относится к группе дополнительных параметров, поэтому для его конфигурирования с помощью sp_configure вы должны задать значение 1 для параметра show advanced options. Вы можете также сконфигурировать его с помощью Enterprise Manager. Щелкните на вкладке Memory (Память) в окне SQL Server Properties, используйте движок Minimum (MB) (Минимум [Мб]) и затем щелкните опцию Dynamically Configure SQL Server Memory. Этот параметр начинает действовать сразу – без необходимости закрытия и повторного запуска SQL Server.

Параметр recovery interval

Вы можете использовать параметр recovery interval (интервал восстановления), чтобы определить максимальное количество минут, которое может потратить система для восстановления после аварии. SQL Server использует значение этого параметра и специальный встроенный алгоритм, определяя, насколько часто следует автоматически создавать контрольные точки, чтобы восстановление занимало только указанное количество минут. SQL Server определяет длительность интервала между контрольными точками в соответствии с объемом работы, выполняемой в системе. Если выполняется много работы, то контрольные точки создаются чаще, чем при небольшом объеме работы. Чем меньше объем выполняемой работы, тем меньше времени требуется SQL Server для восстановления после аварии. И чем больше заданный интервал восстановления, тем больше будет интервал между контрольными точками.

Увеличение интервала восстановления повышает производительность системы за счет снижения количества контрольных точек. (При создании контрольной точки выполняется большое число операций записи на диск, что может несколько замедлять выполнение транзакций пользователей.) Но при этом также увеличивается количество времени, которое SQL Server потратит на восстановление. Значение по умолчанию равно 0, указывая на то, что этот интервал будет определять для вас SQL Server и время восстановления будет составлять примерно 1 минуту. Увеличивайте параметр recovery interval на свое усмотрение. Значение от 5 до 15 (минут) находится в обычных пределах, но ваш выбор зависит только от вашего согласия, чтобы пользователи ждали от 5 до 15 минут для восстановления базы данных в случае аварии системы. Обычно значение параметра recovery interval требуется увеличить, чтобы снизить частоту создания контрольных точек, предоставляя пользователям возможность более свободного выполнения операций ввода-вывода для их транзакций без прерывания.

Параметр recovery interval входит в группу дополнительных параметров: для его конфигурирования с помощью sp_configure вы должны задать значение 1 для параметра show advanced options. Вы можете задать этот параметр с помощью Enterprise Manager, щелкнув на вкладке Database Settings (Параметры базы данных) окна SQL Server Properties и задав нужное значение в поле-счетчике Recovery Interval (min). Изменение этого параметра начинает действовать сразу – без необходимости закрытия и повторного запуска SQL Server.

Заключение

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

Этот курс провел вас через все "как, что и почему" в администрировании SQL Server 2000. Теперь вы сможете эффективно управлять своей системой и конфигурировать ее, а также легко и эффективно выполнять задачи повседневного администрирования. Авторы надеются, что вы с удовольствием прочитали этот курс.