Руководство по настройке производительности SQL Server 7.0 для работы с SAP R/3

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

Документ носит исключительно информационный характер. MICROSOFT НЕ ПРЕДОСТАВЛЯЕТ В ЭТОМ ДОКУМЕНТЕ НИ ЯВНЫХ, НИ ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ

Microsoft, MSDN, Windows и Windows NT являются зарегистрированными товарными знаками или торговыми марками корпорации Microsoft в США и/или в других странах.

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

Серийный номер: 098-82427

Содержание

Целевая аудитория............................................................................................................................................ 4

Введение................................................................................................................................................................. 5

Конфигурация Windows NT........................................................................................................................... 6

Определение размера виртуальной памяти.................................................................................... 6

Оптимизация Windows NT Server VMM для задач SQL Server.................................................. 6

Оптимизация рабочего стола Windows.............................................................................................. 6

Выравнивание сетевой нагрузки на многопроцессорных серверах..................................... 7

Конфигурация SQL Server............................................................................................................................. 9

Размер памяти............................................................................................................................................... 9

Параметр set working set size.................................................................................................................. 9

Параметр network packet size.................................................................................................................. 9

Параметр priority boost........................................................................................................................... 10

Параметр index create memory............................................................................................................. 10

Отключите блокировки страниц в таблицах VBHDR, VBMOD и VBDATA........................ 10

Параметр lightweight pooling................................................................................................................. 10

Параметр affinity mask............................................................................................................................. 11

Формирование и использование индексов...................................................................................... 12

Повышение производительности путем оптимизации индексов........................................... 12

Характеристики анализируемых запросов..................................................................................... 14

Пример анализа работы индексов..................................................................................................... 14

Тестовая таблица данных.................................................................................................................. 14

Тестовые индексы.............................................................................................................................. 15

Тестовые запросы.............................................................................................................................. 15

Выдача в SQL Server Query Analyzer статистики об операциях ввода/вывода при выполнении запросов................................................................................................................. 15

Результаты работы первого набора индексов.................................................................... 16

Выборка одной строки: select * from saptest1 where col3 = 5000......................... 16

Просмотр диапазона: select * from saptest1 where col2 = ‘a’.................................. 17

Рекомендуемые преобразования индексов........................................................................... 18

Результаты работы второго набора индексов.................................................................... 20

Выборка единичной строки с улучшенным индексом: select * from saptest1 where col3 = 5000......................................................................................................................................... 20

Просмотр диапазона с улучшенным индексом: select * from saptest1 where col2 = ‘a’...................................................................................................................................................... 21

Некоторые замечания по результатам анализа работы индексов.............................. 22

Некластеризованный индекс содержит ключ кластеризации................................................. 22

Пример покрывающего запроса по ключу кластеризации...................................... 22

sp_recompile.................................................................................................................................................... 24

Обновление статистики........................................................................................................................... 25

DBCC SHOWCONTIG.................................................................................................................................. 26

FillFactor........................................................................................................................................................... 27

Конфигурация файлов и групп файлов.............................................................................................. 29

Определение размера файлов и использование AutoGrow................................................... 29

Формирование размера журналов транзакций............................................................................ 29

Определение размера tempdb............................................................................................................. 29

Дополнительная информация.................................................................................................................. 30

Целевая аудитория

Назначение представленной в этом документе информации – помочь администраторам баз данных SAP R/3 разобраться в особенностях работы Microsoft SQL Server 7.0. Понимание и использование этих особенностей позволит им добиться максимальной производительности приложений в процессе рабочей эксплуатации баз данных SAP R/3.

Хотя документ предназначен пользователям SAP R/3, важно понимать, что описываемые в нем функциональные особенности и методики настройки SQL Server универсальны. Администраторы сверхбольших баз данных (Very Large DataBase, VLDB), которые имеют дело с большим числом пользовательских сеансов и колоссальными сетевыми нагрузками, смогут почерпнуть в этом документе полезную для себя информацию.

Введение

В этом руководстве обсуждается оптимальная, с точки зрения среды SAP R/3, конфигурация SQL Server 7.0. Документ разбит на четыре логических раздела. В первом разделе рассказывается о параметрах конфигурации Microsoft Windows NT Server. Во втором описываются параметры настройки, существенные для работы SQL Server в среде SAP R/3. Эти разделы довольно просты и посвящены процедурам, которые могут быть произведены всего за несколько минут в ходе начальной установки SQL Server. В третьем разделе рассказывается о построении индексов SQL Server применительно к задачам, решаемым в SAP R/3. Анализ работы индексов – наиболее важная процедура, которая, в целях обеспечения максимальной производительности базы данных, должна реализовываться на постоянной основе. При изучении этого раздела необходимо иметь под рукой руководство Microsoft SQL Server 7.0 Performance Tuning Guide, которое можно загрузить с веб-страницы http://msdn.microsoft.com/developer/sqlserver/sql7perftune.htm . В руководстве обсуждаются проблемы быстродействия аппаратного ввода/вывода, структура индексов и средства настройки производительности SQL Server. Четвертый раздел посвящен вопросам оптимального использования файлов и групп файлов SQL Server в окружении баз данных SAP R/3.

Конфигурация Windows NT

Определение размера виртуальной памяти

Размер файла подкачки Windows NT должен быть как минимум в три раза больше объема оперативной памяти, установленной на сервере, и не может быть меньше 1 Гб.

Ø Чтобы установить размер файла подкачки

1. В меню Start выберите команду Settings, а затем щелкните Control Panel.

2. Два раза щелкните System, а затем, тоже дважды, – вкладку Performance.

3. Щелкните Change, а затем, в поле ввода Initial Size (MB), введите размер файла подкачки в мегабайтах (МВ).

4. Щелкните ОК.

Оптимизация Windows NT Server VMM для задач SQL Server

Обычно диспетчер виртуальной памяти VMM (Virtual Memory Manager) по умолчанию уже сконфигурирован под установку SQL Server.

Ø Чтобы проверить и/или изменить настройку VMM

1. В меню Start выберите команду Settings, а затем щелкните Control Panel.

2. Дважды щелкните Network, а затем - вкладку Services.

3. Дважды щелкните Server, выберите Maximize Throughput for Network Applications, а затем щелкните ОК.

Оптимизация рабочего стола Windows

Ø Чтобы установить наименее ресурсоемкие программу-заставку и фон

1. В меню Start выберите команду Settings, а затем щелкните Control Panel.

2. Дважды щелкните Display, а затем – вкладку Background.

3. Выберите (None) для рисунка и (None) для фонового узора.

4. Щелкните Apply, а затем – вкладку Screen Saver.

5. В раскрывающемся списке Screen Saver выберите Blank Screen, а затем установите Password Protection.

6. Щелкните Apply.

Выравнивание сетевой нагрузки на многопроцессорных серверах

Некоторые многопроцессорные серверы могут в аппаратном режиме динамически перенаправлять сетевые запросы ввода/вывода на наименее загруженный процессор, что предотвращает дефицит процессорных ресурсов и снижение пропускной способности сети в системах, обслуживающих большое число таких запросов. Указанная аппаратная функция, которую часто называют симметричным распределением прерываний, позволяет повысить уровень масштабирования системы и исключить ситуацию дефицита доступа к одному процессору при неполной загрузке остальных. Подобный алгоритм реализован на HAL-уровне (Hardware Abstraction Layer) Windows NT 4.0 для процессоров Pentium. Аналогичная возможность реализована в Windows 2000.

Поскольку различные процессорные платформы используют разные методы распределенной обработки прерываний, то HAL отвечает за индивидуальное распределение прерываний от сетевых адаптеров для каждой из них. При этом реализуемая в HAL схема обработки прерываний зависит от возможностей процессора. Так, некоторые процессоры оборудованы микросхемами управления прерываниями – APIC (Advanced Programmable Interrupt Controller), которые дают им возможность перенаправлять прерывания на другие процессоры компьютера. Для получения более подробной информации о методах распределения прерываний на конкретных аппаратных платформах, необходимо обращаться к их разработчикам.

В стандартной конфигурации, Windows NT 4.0 не предоставляет функций симметричного распределения прерываний и приписывает инициированный платой сетевого адаптера (Network Interface Card, NIC) отложенный процедурный вызов (Deferred Process Call, DPC) процессору с наибольшим порядковым номером. В системах, где функционирует сразу несколько NIC, исходящий от каждой из них очередной вызов приписывается следующему процессору с наибольшим номером.

Если процессор часто работает на пределе возможностей (об этом говорят показания счетчика Processor: %Processor Time = 100% системной утилиты Performance Monitor) и более половины времени занят обслуживанием вызовов DPC (значение счетчика Processor: %DPC Time > 50%), то производительность системы можно поднять путем настройки параметра реестра ProcessorAffinityMask.

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

При работе с многопроцессорным сервером, который может использовать режим симметричного распределения прерываний, установите значение параметра ProcessorAffinityMask реестра Windows NT в ноль. В результате, сетевые запросы ввода/вывода будут динамически перенаправляться на наименее загруженный процессор. Указанный параметр расположен в разделе реестра HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NDIS\Parameters.

Ø Чтобы запустить Registry Editor

1. В меню Start щелкните команду Run.

2. В поле ввода введите regedt32.

Ø Чтобы найти указанный раздел реестра в Registry Editor

3. В меню Window выберите пункт HKEY_LOCAL_MACHINE

4. В левой панели Registry Editor дважды щелкните System.

5. Последовательно раскройте двойным щелчком мыши разделы CurrentControlSet, Services, NDIS и Parameters.

Ø Чтобы ввести новое значение параметра ProcessorAffinityMask

6. В правой панели Registry Editor дважды щелкните ProcessorAffinityMask.

7. Введите 0 (нуль) и щелкните OK.

8. В меню Registry щелкните Exit.

Конфигурация SQL Server

Размер памяти

Предпочтительные значения параметров настройки памяти для SQL Server зависят от характера использования сервера базы данных системой R/3. Если SQL Server установлен как выделенный сервер баз данных, то рекомендуется, чтобы он работал в установленном по умолчанию режиме динамической настройки объема требуемой памяти.

Конфигурация R/3	Минимальная величина	Максимальная величина
Выделенный сервер баз данных	По умолчанию	По умолчанию
Синхронизируемая станция (Update Instance)	40% установленного ОЗУ	65% установленного ОЗУ
Центральный сервер SAP (Central Instance)	45% установленного ОЗУ	45% установленного ОЗУ

Ø Пример установки размера памяти на центральном сервере SAP с объемом ОЗУ в 2 Гб (из Enterprise Manager)

1. Дважды щелкните на правой панели значок SQL Server Group.

2. Дважды щелкните значок SQL Server в разделе сервера баз данных R/3.

3. Щелкните вкладку Memory, а затем – Use a fixed memory size (MB).

4. Переместите ползунок по шкале Use a fixed memory size (MB) до значения 900.

5. Выберите Reserve Physical memory for SQL Server, щелкните Apply, а затем – OK.

Параметр set working set size

После конфигурирования распределения памяти для SQL Server рекомендуется, с помощью параметра set working set size, зарезервировать для него физическую память, что делается так же, как и при настройке памяти SQL Server. Установка этого параметра означает, что Windows NT не будет выгружать на диск страницы памяти SQL Server.

Ø Пример установки параметра set working set size (из Enterprise Manager)

1. На правой панели дважды щелкните значок SQL Server Group.

2. Дважды щелкните значок SQL Server в разделе сервера баз данных R/3.

3. Щелкните вкладку Memory, а затем выберите Reserve physical memory for SQL Server.

4. Щелкните Apply, а затем – OK.

Параметр network packet size

C помощью этого параметра устанавливается размер используемых сервером, сетевых пакетов. Как показало тестирование, оптимальный их размер, с точки зрения производительности большинства серверных систем баз данных R/3, равен 8192 байтам. Установка параметра производится с помощью SQL Server Query Analyzer.

Ø Чтобы установить параметр network packet size (из Query Analyzer)

1. Введите exec sp_configure ‘network packet size’, 8192

2. Введите reconfigure with override.

3. Для выполнения введенных команд нажмите клавиши CTRL+E.

Параметр priority boost

При работе с выделенными серверами баз данных рекомендуется, чтобы SQL Server работал в режиме priority boost.

Ø Чтобы установить режим priority boost (из Enterprise Manager)

1. На правой панели дважды щелкните значок SQL Server Group.

2. Дважды щелкните значок SQL Server в разделе сервера баз данных R/3.

3. Щелкните вкладку Processor, а затем в списке Processor Control выберите Boost SQL Server priority on Windows NT.

Параметр index create memory

Рекомендуется, чтобы значение параметра index create memory SQL Server было равно 16 Мб. Этот параметр устанавливается с помощью SQL Server Query Analyzer.

Ø Чтобы установить значение параметра index create memory (из Query Analyzer)

1. Введите exec sp_configure ‘index create memory’, 16000

2. Введите reconfigure with override.

3. Для выполнения введенных команд нажмите клавиши CTRL+E.

Отключите блокировки страниц в таблицах VBHDR, VBMOD и VBDATA

Ø Чтобы отключить блокировки страниц в таблицах VBHDR, VBMOD и VBDATA (из Query Analyzer)

1. В окне Query введите следующие команды:

exec sp_indexoption 'VBHDR','allowpagelocks','false'

exec sp_indexoption 'VBMOD','allowpagelocks','false'

exec sp_indexoption 'VBDATA','allowpagelocks','false'

2. Для выполнения введенных команд нажмите клавиши CTRL+E.

Параметр lightweight pooling

Если все процессоры сервера баз данных очень сильно загружены (Performance Monitor информирует об их загрузке более чем на 95%), то будет правильным включить режим lightweight pooling. Это позволит высвободить от 5 до 7% мощности процессоров.

Ø Чтобы перевести SQL Server в режим lightweight pooling (из Enterprise Manager)

1. На правой панели дважды щелкните значок SQL Server Group.

2. Дважды щелкните значок SQL Server в разделе сервера баз данных R/3.

3. Щелкните вкладку Processor, выберите Use Windows NT Fibers, а затем щелкните Apply.

4. После появления приглашения на перезагрузку SQL Server, щелкните Yes, а затем – OK.

Параметр affinity mask

affinity mask – это параметр конфигурации SQL Server, который позволяет указать процессоры, на которых не будут исполняться потоки SQL Server. Наилучший вариант – оставить без изменения изначально установленный в нулевое значение параметр, при котором потокам SQL Server предоставлено право исполнения на всех процессорах. Почти во всех случаях это позволяет достичь наилучшей производительности, поскольку предотвращает передачу обработки интенсивных сеансов связи SQL Server на один процессор в обход других, загруженных в меньшей степени. Данный вывод был сделан на основе положительных результатов тестирования указанной конфигурации, проведенного Microsoft совместно с пользователями SAP R/3, участвующими в программе SQL Server Early Adopter.

Формирование и использование индексов

Повышение производительности путем оптимизации индексов

В руководстве Microsoft SQL Server 7.0 Performance Tuning Guide приводится важная информация об индексах и настройке производительности. Загрузить этот документ Вы сможете с веб-страницы, адрес которой указан в разделе “Дополнительная информация”.

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

Операции, в ходе которых происходит поиск и обработка одной или нескольких строк конкретной базы данных, должны использовать некластеризованные (nonclustered) или кластеризованные (clustered) индексы, базирующихся на одном или нескольких столбцах, обеспечивающих повышенный уровень селективности. Благодаря индексам, процессор запросов SQL Server и ядро базы данных могут минимизировать число операций ввода/вывода, необходимых для выборки строк. Например, если выборка одной записи заказа должна регулярно производиться из очень большой таблицы Orders, базирующейся на номере заказа (order id), то, для ускорения запросов, имеет смысл определить индекс на основе столбца orderid.

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

Ожидаемая к выпуску версия SAP R/3 4.5В будет включать важную функцию, влияющую на гибкость выбора кластеризованного индекса SQL Server – пассивную поддержку в R/3 Data Dictionary кластеризованных индексов, не базирующихся на столбцах первичного ключа. Пассивная поддержка означает, что SAP R/3 Dictionary сможет распознавать и запоминать расположение кластеризованного индекса SQL Server при изменении таблицы базы данных, в результате которого произошло смещение кластеризованного индекса со столбца первичного ключа на другой столбец, или ряд других столбцов. Хотя создание кластеризованных индексов должно производиться с помощью инструментария SQL Server в противовес инструментарию R/3, информация об их расположении не будет потеряна в ходе преобразований базы данных и установки новых версий R/3.

Будущие, более старшие чем 4.5В, версии SAP R/3 скорее всего будут гарантировать активную поддержку кластеризованных индексов SQL Server, когда в дополнение к упомянутой поддержке R/3 Data Dictionary, инструментарий R/3 сможет создавать для таблиц SQL Server кластеризованные индексы, не включающие столбцы первичного ключа.

Эти изменения в поддержке кластеризованных индексов имеют большое значение для администраторов баз данных R/3, желающих повысить скорость выдачи отчетов по выполняемым запросам. Как известно, вывод ежемесячных и ежеквартальных отчетов крупных компаний требует регулярного просмотра разделов таблиц на сервере базы данных. Довольно часто такой просмотр выполняется в большой таблице, не включающей столбцы первичного ключа базовой таблицы. В настоящее время, реализация баз данных SQL Server в составе SAP R/3 конфигурирует первичные ключи всех таблиц в виде кластеризованных первичных ключей. Однако, могут возникать ситуации, когда очень удобно проверить работу кластеризованного индекса, базирующегося на столбце, не являющимся частью первичного ключа, но часто используемым в большой таблице для создания отчетов. Преобразование кластеризованного первичного ключа в некластеризованный выполняется с помощью команды ALTER TABLE.

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

Более подробно о порядке выбора кластеризованных и некластеризованных индексов рассказывается в Microsoft SQL Server 7.0 Performance Tuning Guide.

Характеристики анализируемых запросов

В целях помощи администраторам баз данных R/3 при анализе объема ресурсов, которые потребляют хранимые процедуры SQL Server в ходе своего исполнения на сервере базы данных, SAP R/3 предоставляет в рамках R/3 Performance Monitor (Transaction ST04) инструмент MSSTATS. Как известно, все стандартные транзакции R/3 с сервером баз данных выполняются с помощью хранимых процедур. MSSTATS выдает информацию, позволяющую провести дифференциацию таких процедур в зависимости от потребления ими ресурсов. Среди такой информации – число вызовов процедуры; среднее и максимальное время, затраченное на вызов процедуры; среднее и общее число строк, переданных с помощью данной процедуры; факты использования хранимой процедурой курсоров; время активности и простоя процедуры; и другие сведения.

MSSTATS – важный инструмент выявления ресурсоемких хранимых процедур, работающих на сервере баз данных R/3. Разбор особенностей запросов, которые реализуют самые ресурсоемкие процедуры, лежит в основе анализа производительности баз данных SAP R/3.

Пример анализа работы индексов

Используемая в этом примере таблица SQL Server является наиболее типичным образцом таблиц данных SAP R/3. Цель примера – путем анализа двух запросов продемонстрировать, как наиболее эффективно применять индексы SQL Server в среде серверов баз данных R/3.

Тестовая таблица данных

Рассматриваемый здесь сценарий создает таблицу saptest1 и загружает в нее 100 000 записей. Все строки первого столбца coll содержат одно и то же значение – “000”. Это позволяет имитировать часто встречающийся в базах данных SAP R/3 столбец MANDT, который обычно не характеризуется высоким уровнем избирательности. Второй столбец col2 включает более неоднородную информацию, поскольку в каждую сотую его строку включен символ ‘a’. В целях поиска каждой сотой заполняемой строки используется оператор деления по модулю (%) в SQL Server. В последнем столбце col3 избирательность данных значительно более высока – все его строки содержат уникальные числа.

Ø Чтобы сформировать тестовую таблицу данных (из Query Analyzer)

1. В окне Query введите следующие команды:

create table saptest1 (

col1 char(4) not null default '000',

col2 char(4) not null default 'zzzz',

col3 int not null, filler char(300) default 'abc' )

declare @counter int

set nocount on

set @counter = 1

while (@counter <= 100000)

begin

if (@counter % 1000 = 0)

PRINT 'loaded ' + CONVERT (VARCHAR(10),@counter)

+ ' of 100000 record'

if (@counter % 100 = 0)

begin

insert saptest1 (col2,col3) values ('a',@counter)

end

else

insert saptest1 (col3) values (@counter)

set @counter = @counter + 1

end

2. Для выполнения введенных команд нажмите клавиши CTRL+E

Тестовые индексы

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

Кластеризованный первичный ключ таблицы saptest1 является типичным для среды баз данных R/3, поскольку помещает имеющий нулевую избирательность столбец coll (смоделированный по MANDT обычной системы R/3) в начало индекса.

Некластеризованный индекс nkey2 смоделирован на основе типовых индексов R/3, поскольку создан на базе нескольких столбцов.

Ø Чтобы создать тестовые индексы (из Query Analyzer)

1. Введите в окне Query следующие команды:

alter table saptest1 add constraint sapt_c1

PRIMARY KEY clustered (col1,col2,col3)

create index nkey2 on saptest1(col2,col3)

2. Для выполнения команд нажмите клавиши CTRL+E

Тестовые запросы

select * from saptest1 where col3 = 5000

Запрос 1 извлекает одну строку тестовой таблицы, базируясь на заданном значении в столбце col3:

select * from saptest1 where col2 = 'a'

Запрос 2 выполняет просмотр раздела таблицы (диапазона), извлекая из него 1000 строк, базируясь на заданном значении столбца col2.

Выдача в SQL Server Query Analyzer статистики об операциях ввода/вывода при выполнении запросов

SQL Server Query Analyzer способен предоставить ценные статистические данные по операциям ввода/вывода каждого запроса, выполняемого в его окне Query. Эти возможности описываются в документации SQL Server в подразделе Statistics IO. Чтобы включить данную функцию, нужно либо выполнить команду T-SQL, либо определить нужные параметры в меню Query Analyzer.

Ø Чтобы включить вывод статистики с помощью команды T-SQL (из Query Analyzer)

1. В окне Query введите следующую команду:

set statistics io on

2. Для выполнения команды нажмите клавиши CTRL+E

Ø Чтобы включить вывод статистики с помощью меню (из Query Analyzer)

3. В меню Query Analyzer щелкните Query, а затем – Current Connection Options.

4. Выберите Show Stats I/O, а затем щелкните Apply.

5. Щелкните OK.

Результаты работы первого набора индексов

Выборка одной строки: select * from saptest1 where col3 = 5000

Текстовый вывод ShowPlan:

|--Bookmark Lookup(BOOKMARK:([Bmk1000]), OBJECT:([pubs].[dbo].[saptest1]))

|--Index Scan(OBJECT:([pubs].[dbo].[saptest1].[nkey2]), WHERE:([saptest1].[col3]=5000))

Эквивалентный графический вывод ShowPlan:

Вывод запроса и статистики ввода/вывода (окно Query Analyzer)

col1 col2 col3 filler

000 a 5000 abc

(1 row(s) affected)

Table 'saptest1'. Scan count 1, logical reads 240, physical reads 0, read-ahead reads 0.

Вывод ShowPlan показывает, что процессор запросов выполнил просмотр некластеризованного индекса nkey2. Просмотр индекса (index scan) означает, что для нахождения ключевого значения 5000, SQL Server должен был полностью или частично прочитать содержимое структуры двоичного дерева nkey2 (В-дерева) на уровне листьев. Для этого было необходимо произвести 240 операций ввода/вывода через кэш данных SQL Server, то есть прочитать из буферного кэша SQL Server 240 страниц размером 8 Кб. Нулевые значения для операций физического чтения (physical reads) и опережающего чтения (read-ahead reads) означают, что для получения данных по этому запросу не потребовалось читать информацию с диска.

Замечание: Статистика ввода/вывода меняется в режиме исполнения. Так, если при первом исполнении запроса все операции чтения выполнялись из буферного кэша и расценивались как логические (logical reads), то при следующих прогонах того же самого запроса могут потребоваться операции опережающего чтения и/или физического чтения. Хотя такие изменения статистики ввода/вывода объясняются многими причинами, наиболее распространенной является необходимость обслуживания конкурирующих запросов, в результате чего происходит замещение, ранее размещенных в кэше, страниц данных отслеживаемого запроса. Поэтому, при анализе запросов, очень полезно запускать их несколько раз при включенном выводе статистических данных и производить сравнение полученной информации.

Отображаемые в графическом окне ShowPlan процентные значения с именем Cost означают долю времени, затраченного на выполнение каждой отдельной операции запроса, от полного времени его прохождения.

Просмотр диапазона: select * from saptest1 where col2 = ‘a’

Текстовый вывод ShowPlan:

|--Clustered Index Scan(OBJECT:([pubs].[dbo].[saptest1].[sapt_c1]), WHERE:([saptest1].[col2]='a'))

Эквивалентный графический вывод ShowPlan:

Вывод запроса и статистики ввода/вывода (окно Query Analyzer)

col1 col2 col3 filler

000 a 100 abc

000 a 200 abc

000 a 300 abc

000 a 99800 abc

000 a 99900 abc

000 a 100000 abc

(1000 row(s) affected)

Table 'saptest1'. Scan count 1, logical reads 4500, physical reads 1, read-ahead reads 4010.

Вывод ShowPlan показывает, что процессор запросов выполнил просмотр кластеризованного индекса sapt_cl. Просмотр индекса означает, что для нахождения ключевых значений ‘a’, SQL Server должен был полностью или частично прочитать содержимое структуры B-дерева sapt_cl на уровне листьев (содержащего реальные строки таблицы). Для этого потребовалось прочитать из буферного кэша 4500 страниц размером 8 Кб. Наличие 4010 операций опережающего чтения говорит о том, что SQL Server с помощью Read-Ahead Manager (блоками по 64 Кб) прочитал 4010 страниц размером 8 Кб. При этом следует понимать, что опережающее чтение намного более эффективно, чем физическое чтение, которое, как видно из статистики, SQL Server выполнил всего один раз, прочитав с диска одну страницу размером 8 Кб. Поскольку в ходе операций физического и опережающего чтения происходит непосредственное обращение к жесткому диску, эти операции намного медленнее операций логического чтения, когда чтение осуществляется из буферного кэша. Именно поэтому, главной задачей настройки производительности должно быть ограничение числа обращений к жесткому диску и, в идеале, чтение всех страниц базы данных через буферный кэш.

Результаты работы второго набора индексов

Выборка единичной строки с улучшенным индексом: select * from saptest1 where col3 = 5000

Текстовый вывод ShowPlan:

|--Bookmark Lookup(BOOKMARK:([Bmk1000]), OBJECT:([pubs].[dbo].[saptest1]) WITH PREFETCH)

|--Index Seek(OBJECT:([pubs].[dbo].[saptest1].[nkey1]), SEEK:([saptest1].[col3]=5000) ORDERED)

Эквивалентный графический вывод ShowPlan:

Вывод запроса и статистики ввода/вывода (окно Query Analyzer)

col1 col2 col3 filler

000 a 5000 abc

(1 row(s) affected)

Table 'saptest1'. Scan count 1, logical reads 5, physical reads 0, read-ahead reads 0.

На этот раз, ShowPlan информирует, что SQL Server, вместо просмотра индекса, использовал поиск по индексу nkey1. Поиск по индексу (index seek) означает, что SQL Server имел возможность быстрой навигации по структуре В-дерева nkey1 (вместо просмотра уровня листьев индекса как в предыдущем случае) и для выборки строки данных, связанной с ключевым значением 5000, использовал операцию Bookmark Lookup (переход по указателю). Изменение технологии запроса оказало существенное влияние на производительность ввода/вывода, поскольку для выполнения запроса потребовалось всего 5 операций чтения кэша данных SQL Server, а не 240, как в предыдущем случае.

Просмотр диапазона с улучшенным индексом: select * from saptest1 where col2 = ‘a’

Текстовый вывод ShowPlan:

|--Clustered Index Seek(OBJECT:([pubs].[dbo].[saptest1].[ckey1]), SEEK:([saptest1].[col2]='a') ORDERED)

Эквивалентный графический вывод ShowPlan:

Вывод запроса и статистики ввода/вывода (окно Query Analyzer)

col1 col2 col3 filler

000 a 100 abc

000 a 200 abc

000 a 300 abc

000 a 99800 abc

000 a 99900 abc

000 a 100000 abc

(1000 row(s) affected)

Table 'saptest1'. Scan count 1, logical reads 48, physical reads 0, read-ahead reads 0.

И опять, ShowPlan показывает, что SQL Server использовал поиск по индексу ckey1 вместо просмотра индекса. В случае поиска по кластеризованному индексу, не требуется выполнять операцию bookmark lookup, поскольку уровень листьев B-дерева кластеризованного индекса уже содержит все необходимые табличные данные. В данном случае, переход от просмотра индекса к поиску по индексу также позволил получить существенный выигрыш в производительности ввода/вывода. Для выборки 1000 строк теперь потребовалось всего 48 операций чтения из буферного кэша SQL Server, в то время как ранее на это уходило 4500 таких операций. Благодаря столь резкому сокращению объема ввода/вывода, для выполнения запроса не потребовалось физическое чтение жесткого диска, поскольку все необходимые страницы были записаны в кэш данных SQL Server. Об этом говорит тот факт, что число операций физического чтения и опережающего чтения равно нулю. Имейте в виду, что операции опережающего чтения (read-ahead reads) являются операциями физического чтения жесткого диска блоками по 64 Кб, а собственно операции физического чтения (physical reads) считывают с диска по 8 Кб данных.

Некоторые замечания по результатам анализа работы индексов

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

Некластеризованный индекс содержит ключ кластеризации

Чем больше столбцов и байт включается в кластеризованный индекс SQL Server 7.0, тем больше становятся некластеризованные индексы конкретной таблицы. Это связано с тем, что формирующие кластеризованный индекс столбцы (или столбец) используются не только этим индексом, но также некластеризованными индексами той же таблицы. Некластеризованные индексы содержат ключ кластеризации, который используют для адресации содержимого строк. Если же в таблице нет кластеризованного индекса, то ситуация меняется и таблица обрабатывается как неупорядоченный динамический массив. Более подробная информация по этому вопросу находится в SQL Server Books Online.

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

Пример покрывающего запроса по ключу кластеризации

В этом примере рассмотрен случай, когда ключ кластеризации содержит лишь ту информацию, которая необходима для выполнения запроса с помощью некластеризованного индекса. При этом, процессор запросов использует некластеризованный индекс в качестве покрывающего индекса (covering index) и не нуждается в выполнении адресных переходов для выборки данных из таблицы. Более подробная информация о покрывающих индексах и их структуре приведена в Microsoft SQL Server 7.0 Performance Tuning Guide.

Ø Создайте таблицу данных (из Query Analyzer)

1. В окне Query введите следующие команды:

create table saptest2 (col1 int, col2 char(4) default 'a', filler char(300) default 'zzzz')

declare @counter int

set @counter = 1

while (@counter <= 1000)

begin

insert saptest2 (col1) values (@counter)

set @counter = @counter + 1

end

insert saptest2 values (1001,'sap','R/3')

create clustered index sap_CK1 on saptest2(col1)

create nonclustered index sap_NCK1 on saptest2(col2)

2. Для выполнения команд нажмите клавиши CTRL+E.

Ø Выведите на экран и сравните планы двух запросов (из Query Analyzer)

3. В окне Query введите следующие команды:

select * from saptest2 where col2 = 'sap'

select col1,col2 from saptest2 where col2 = 'sap'

4. Поочередно выберите каждый запрос, а затем, для отображения графического окна ShowPlan, нажмите клавиши CRTL+L.

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

sp_recompile

При диагностировании долговременных процессов R/3 иногда полезно помнить о команде sp_recompile, которая дает возможность быстро пометить хранимые процедуры для перекомпиляции. Команда выполняется очень быстро и позволяет сгенерировать для хранимой процедуры новый план запроса, отражающий текущее состояние таблицы, индексов и собранной статистики.

Замечание: в большинстве стандартных ситуаций работы окружения R/3 нет необходимости запускать sp_recompile, поскольку SQL Server автоматически перекомпилирует хранимые процедуры по мере необходимости. Тем не менее, специалисты SAP и Microsoft обнаружили, что в случаях длительного доступа к таблицам, когда частота запуска обслуживающих их пакетных и синхронизирующих процессов снижается, применение этой команды весьма эффективно.

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

Ø Пример запуска sp_recompile (из Query Analyzer)

1. Введите exec sp_recompile ‘VBRP’.

2. Для выполнения команды нажмите клавиши CTRL+E.

Обновление статистики

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

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

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

Предотвратить генерацию статистики по таблицам VBHDR, VBMOD и VBDATA позволяют приведенные ниже команды.

Ø Чтобы выключить генерацию статистики для VBHDR, VBMOD и VBDATA (из Query Analyzer)

1. В окне Query введите следующие команды:

exec sp_autostats VBHDR,'OFF'

exec sp_autostats VBMOD,'OFF'

exec sp_autostats VBDATA,'OFF'

2. Для выполнения команд нажмите клавиши CTRL+E

Ранее созданная по таблицам VBHDR, VBMOD и VBDATA статистика может быть удалена из базы данных с помощью следующих команд:

Ø Чтобы удалить существующую статистику (из Query Analyzer)

1. С помощью команды sp_helpindex определите имя удаляемой статистики. Например, для отображения имен существующих для VBMOD статистик, введите в окне Query следующую команду:

exec sp_helpindex VBMOD

2. Для выполнения команды нажмите клавиши CTRL+E. В столбце index_name панели результатов Query Analyzer будут отображены имена всех индексов и статистик.

3. Введите команду drop statistics с указанием имени статистики. Например, для удаления статистики _WA_Sys_VBELN_0AEA10A3, в окне Query введите следующую команду:

drop statistics VBRP._WA_Sys_VBELN_0AEA10A3

4. Для выполнения команды нажмите клавиши CTRL+E.

5. Для удаления всех статистик таблиц VBMOD, VBHDR и VBDATA повторите шаги с 1 по 4.

DBCC SHOWCONTIG

Команда DBCC SHOWCONTIG используется для оценки уровня физической фрагментации (если таковая имеется) таблицы данных.

Ø Пример исполнения команды DBCC SHOWCONTIG (из Query Analyzer)

1. В окне Query введите следующие команды.

declare @id int

select @id = object_id('saptest1')

dbcc showcontig (@id)

2. Для выполнения команд нажмите клавиши CTRL+E

3. На экране будет отображен следующий результат:

DBCC SHOWCONTIG scanning 'saptest1' table...

Table: 'saptest1' (933578364); index ID: 1, database ID: 5

TABLE level scan performed.

- Pages Scanned................................: 4167

- Extents Scanned..............................: 521

- Extent Switches..............................: 520

- Avg. Pages per Extent........................: 8.0

- Scan Density [Best Count:Actual Count].......: 100.00% [521:521]

- Logical Scan Fragmentation ..................: 11.21%

- Extent Scan Fragmentation ...................: 0.96%

- Avg. Bytes Free per Page.....................: 198.6

- Avg. Page Density (full).....................: 97.55%

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Параметры Scan Density и Extent Scan Fragmentation помогут оценить, насколько оптимально размещена на диске таблица. 100% для Scan Density является наилучшим значением, поскольку говорит об оптимальном числе используемых экстентов (когда в каждом экстенте присутствует ровно 8 страниц). Extent Scan Fragmentation предоставляет дополнительную информацию о разрыве страниц (page splitting), указывая, имеет ли таблица экстенты, которые физически отделены от других экстентов на диске. Эта информация может быть полезна лишь в том случае, если для таблицы определен кластеризованный индекс.

Параметр Avg.Page Density (full) показывает в процентах среднее количество информации на каждой странице данных SQL Server. Иногда этот параметр называют степенью заполнения страниц данных. Высокое его значение говорит о том, что в буферный кэш SQL Server, при каждом чтении 8-Кб блока данных, будет занесен сравнительно больший объем информации. Большой процент как правило означает, что кэш содержит более значимый блок данных. Например, рассмотрим случай, когда DBCC SHOWCONTIG обнаружила в базе данных несколько таблиц со средней плотностью страниц 50%. Если эти страницы включают большую часть запрашиваемых данных, то в буферный кэш SQL Server будут загружены страницы, лишь наполовину заполненные полезной информацией. Это говорит о том, что в кэше размером 1 Гб будет находиться только 500 Мб данных SQL Server. В том случае, если среднюю плотность, считываемых в буферный кэш, табличных страниц удастся приблизить к 100%, указанный буфер сможет содержать почти 1 Гб полезной информации.

Если время ответов на запросы данных из таблицы вырастает до неприемлемо высокого уровня, запустите команду DBCC SHOWCONTIG, указав имя этой таблицы. В том случае, когда значение параметра Avg.Pages per Extent значительно меньше 8.0, параметр Extent Scan Fragmentation превышает 10-20%, или же Avg.Page Density (full) намного меньше 100%, то, для размещения содержимого таблицы в физически непрерывной последовательности экстентов, необходимо выполнить перестроение ее кластеризованного индекса. Процедура перестроения индекса также дает возможность повысить степень заполнения 8-Кб страниц путем выбора параметра их уплотнения.

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

FillFactor

FillFactor – это параметр команды CREATE INDEX, позволяющий управлять степенью заполнения индекса на уровне листьев. Поскольку уровень листьев кластеризованного индекса таблицы состоит из табличных страниц, то FillFactor дает возможность контролировать уровень заполнения страниц тех таблиц, которые имеют кластеризованный индекс.

По умолчанию, значение FillFactor равно нулю, что обеспечивает заполнение всех страниц данных таблицы на 100%. Поскольку специалисты Microsoft убедились, что такое значение параметра позволяет получить максимальную производительность для большинства таблиц SQL Server в средах SAP R/3, то оно рекомендуется в качестве исходного при настройке сервера баз данных R/3.

Используя FillFactor, следует помнить, что увеличение производительности путем размещения максимального объема информации в каждой странице данных таблиц и индексов необходимо совмещать с предотвращением разрыва страниц. Разрыв страниц имеет место в том случае, когда при записи в страницу необходимой информации та оказывается заполненной. В таком случае, используется новая страница, и данные перераспределяются между старой и новой страницей. Усовершенствованный механизм хранения данных SQL Server 7.0 позволяет процесс разрыва более эффективным, чем это было в SQL Server 6.5, намного снижая связанные с ним потери производительности. Именно по этой причине, нулевое значение параметра FillFactor изначально обеспечивает неплохую производительность. Если же в выводе команды DBCC SHOWCONTIG сообщается о значительной физической фрагментации таблицы и увеличении времени отклика на запросы, то необходимо перестроить ее кластеризованный индекс с целью оптимизации структуры его B-дерева.

Перестроение первичных ключей производится с помощью параметра DROP_EXISTING команды CREATE INDEX и дает возможность повысить производительность работы с ними. В приведенном примере выполняется перестроение индексов ранее описанной таблицы saptest1.

Ø Пример перестроения кластеризованного первичного ключа (из Query Analyzer)

1. В окне Query введите следующую команду:

create unique clustered index sapt_c1 on saptest2(col1,col2,col3) with drop_existing

2. Для выполнения команды нажмите клавиши CTRL+E.

Ø Пример перестроения некластеризованного первичного ключа (из Query Analyzer)

3. В окне Query введите следующую команду:

create unique index sapt_c1 on saptest2(col1,col2,col3) with drop_existing

4. Для выполнения команды нажмите клавиши CTRL+E.

Ø Пример перестроения кластеризованного индекса (из Query Analyzer)

5. В окне Query введите следующую команду:

create clustered index ckey1 on saptest2(col2) with drop_existing

6. Для выполнения команды нажмите клавиши CTRL+E.

В тех системах R/3, где очень часто приходится иметь дело с операциями вставки, может оказаться разумным применение пониженного уровня заполнения табличных и индексных страниц, что позволит минимизировать эффект их разрыва. Более подробная информация о синтаксических особенностях использования FillFactor в команде CREATE INDEX приведена в SQL Server Books Online.

Конфигурация файлов и групп файлов

Определение размера файлов и использование AutoGrow

Рекомендуется, чтобы после начальной конфигурации файлов SQL Server на каждый RAID-массив, как минимум, приходилось бы по три файла одинакового размера, который был бы для них предельным. На случай непредвиденного разрастания файлов, установите параметр Autogrow. Формирование трех файлов полезно для ускорения перенаправления данных, если установлено, что необходима более мощная система ввода/вывода и требуется подключение в сеть нового RAID-массива. Для пересылки данных в новый массив может использоваться команда ALTER DATABASE, позволяющая так модифицировать структуру базы данных, чтобы один из ее файлов был размещен в новом массиве. Быстрое перемещение файла в новый массив осуществляется во время кратковременного останова SQL Server.

Для предотвращения выхода размера файла за пределы емкости RAID-массива в режиме Autogrow, используйте параметр MAXSIZE команды ALTER DATABASE. Перед тем как файл окончательно заполнится, добавьте в файловую группу новый файл с помощью команды ALTER DATABASE.

Формирование размера журналов транзакций

В целях увеличения производительности рекомендуется, чтобы размер журналов транзакций был изначально максимальным, а не увеличивался в ходе работы автоматически в режиме Autogrow. Такое решение позволяет сократить число файлов журналов. Вместе с тем, на случай непредвиденного разрастания журналов транзакций, режим Autogrow должен быть включен. В свою очередь, чтобы не допустить выхода размеров журналов за пределы емкости жесткого диска (или дисков), с помощью параметра MAXSIZE команды ALTER DATABASE, ограничьте верхний предел их роста, как показано ниже для случая tempdb.

Определение размера tempdb

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

Ø Чтобы ограничить автоматический рост tempdb уровнем 4 Гб (из Query Analyzer)

1. В окне Query введите следующую команду:

Exec sp_helpdb tempdb

2. Для выполнения команды нажмите клавиши CTRL+E.

В первой колонке второго раздела результатов вывода команды будут находиться логические имена данных и журналов, связанных с tempdb. Логическое имя файла данных tempdb будет использовано в команде ALTER DATABASE. В данном случае, это имя – tempdev.

3. В окне Query введите следующую команду:

alter database tempdb modify file (name = tempdev, maxsize = 4000)

4. Для выполнения команды нажмите клавиши CTRL+E.

Дополнительная информация

Дополнительную информацию по вопросам создания индексов SQL Server, настройки операций ввода/вывода, RAID-массивам и использованию средств анализа производительности SQL Server можно найти в документе Microsoft SQL Server 7.0 Performance Tuning Guide, который размещен по адресу http://msdn.microsoft.com/developer/sqlservr/sql7perftune.htm. Администраторы SAP, работающие с SQL Server, обязательно должны ознакомиться с этим документом.

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

Самые свежие материалы по SQL Server, включая информационные документы, можно найти по адресу http://www.microsoft.com/sql/.

Подробные сведения о порядке установки систем R/3 в составе Windows NT и процедурах миграции на SQL Server 7.0 с его предыдущей версии приведены в документах корпорации SAP – R/3 Installation on Windows NT - Microsoft SQL Server Database - SAP Release 4.0B (серийный номер 51002828) и Database Conversion: Microsoft SQL Server version 6.5 to 7.0 (серийный номер 51003094).

Большое количество материалов о технологиях Microsoft размещено на компакт-диске MSDN Library. В одном из наиболее полезных, с точки зрения настройки производительности SQL Server, документов – Windows NT Server 4.0 Resource Kit, Supplement 1 – рассказывается о порядке мониторинга серверов Windows NT. О том, как подписаться на MSDN, можно узнать по адресу http://msdn.microsoft.com/developer/join/subscriptions.htm.