Лучшие средства для мониторинга ms sql server. Использование монитора производительности для определения узких мест аппаратных средств, на которых запущен SQL Server. Определение базовых параметров при помощи System Monitor

Начиная с версии 2008 в сборку SQL Server был добавлен монитор производительности системы - Performance Data Collector (PDC). Новый компонент Management Studio, призванный облегчить мониторинг и настройку производительности экземпляров SQL Server"а конечным пользователям.

Компоненты, устанавливаемые по умолчанию, называют набором системы сбора данных, а именно:

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

Преимущества:

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

Ограничения:

Совместимо только с версией SQL Server 2008.
Система сбора данных не отображает информацию о дисковом пространстве в режиме онлайн

Этапы подготовки:

На первом этапе подготовки на сервере должна быть создана папка с правами на чтение/запись для службы SQLSERVERAGENT. Вся техническая информация будет собираться в данной папке, а затем загружаться в базу данных системы мониторинга.
База данных системы мониторинга должна быть создана до того, как вы запустите мониторинг. Данная база данных по сути является обычной базой данных SQL и содержит все данные, полученные с помощью системы мониторинга.
Позаботьтесь заранее о размере дискового пространства. Ожидаемый рост базы данных около 250 - 350 мб в день.
По умолчанию данные очищаются каждые 14 дней. Глубину очистки можно менять в зависимости от заданных требований.
Набор сбора "Занято место на диске" отслеживает рост базы данных и файлов журнала и предоставляет статистику по файлам, такую как средний рост (в мегабайтах) в день. Опрос состояния диска происходит каждые 5 секунд, каждый час данные записываются в базу данных и хранятся в течение 90 дней. Данные интервалы могут быть скорректированы.
Набора сбора "Статистика запросов" собирает данные по статистике запросов, а также тексты отдельных запросов, планы запросов и конкретные запросы. Эти данные в сочетании с системой статистикой и действиями позволяют проводить детализацию углублением ниже уровня сеанса к отдельным запросам. Частота передачи по расписанию - каждые 15 минут, хранение данных в течение 14 дней. Данные интервалы могут быть скорректированы.
Набор сбора "Активность сервера" предоставляет общие сведения об активности SQL Server, использовании ресурсов SQL Server и конфликта между ресурсами SQL Server. Этот набор сбора также дает инкапсулированное представление использования всех системных ресурсов, которые позволяет определить связь проблем производительности с действиями за пределами области SQL Server. Запись статистики активности сервера происходит каждые 60 секунд, для активных сессий и запросов данный интервал составляет 10 секунд
База данных MSDB используется для хранения информации о конфигурации, о времени выполнения, аудита и ведении журнала сбора информации. SSIS пакетов хранятся в MSDB.
Необходимо обязательно установить SQL Server agent.
Служба интеграции SQL Server должна быть запущена, т.к. SSIS пакеты используются для сбора данных. SSIS пакеты также генерируют события во время сбора данных, которые используются для мониторинга и устранения неполадок в процессе сбора.
Data Collector Security. В окне мастера "Configure Data Warehouse Wizard" необходимо сопоставить роли для сборщика данных и учетные записи пользователей. К ним относятся: mdw_admin, mdw_reader и mdw_writer.

mdw_reader - используется для входа пользователям, которым необходимо архивные отчеты;
mdw_writer - роль может загружать и записывать данные в хранилище данных. Поэтому каждая служба SQLServerAgent, используемая на удаленных сборщиках данных, хранит данные в центральном базе данных.
mdw_admin - чтение, запись, обновление и удаление доступа к базе данных. Любая учетная запись пользователя назначенная на роль mdw_admin может изменить схему на mdw-файла и запускать задания по обслуживанию.

Настройка производительности Data Collector

Во-первых, создадим хранилище данных управления

Теперь, давайте настроим хранилище данных управления.

Нажимаем "Next" на экране приветствия

Указываем имя базы данных и место расположения

Присваиваем пользователю роль mdw_admin.

Проверяем конфигурацию. Если все указано правильно, нажимаем "Finish" и переходим к процессу конфигурирования.

Идет процесс конфигурации...

Конфигурация выполнена.

Теперь, после выполнения на сервере запросов к базе данных можно просмотреть отчеты этих выполнений. Для просмотра отчетов разверните вкладку "Management" -> "Data Collection".

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

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

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

История статистики запросов.

Этот отчет отображает ресурсоемкие запросы по категориям.

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

Внизу расположена подробная информация по выбранному запросу.

Список контрольных вопросов аудита производительности

Введите ваши результаты в таблицу, приведенную выше.

Использование монитора производительности (Performance Monutor) для идентификации узких места аппаратных средств SQL Server

Лучше всего начать аудит производительности SQL Server с монитора производительности (System Monitor). Мониторинг нескольких основных счетчиков за период 24 часов позволит вам получить довольно хорошее представление о любых главных аппаратных проблемах, которые сказываются на производительности SQL Server.

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

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

Как интерпретировать ключевые счетчики монитора производительности

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

Память: Страницы/секунды

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

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

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

В большинстве случаев, на физическом сервере, специализированном под SQL Server, с адекватным количеством оперативной памяти, среднее значение обмена страницами будет меньше чем 20. Адекватное количество оперативной памяти для SQL Server можно определить по следующему критерию: сервер должен иметь коэффициент удачного обращения в кэш буфера (Buffer Hit Cache Ratio) 99 % и выше. Данный счетчик описан ниже в этой статье. Если Вы имеете SQL Server, у которого этот коэффициент имеет значение 99 % или выше в течение 24 часов, но Вы получаете среднее значение обмена страницами более 20 в течение того же самого периода времени, это может указывать на то, что у Вас выполняются и другие приложения на физическом сервере помимо SQL Server. Если дело обстоит именно так, Вы должны в идеальном случае удалить эти приложения, позволив SQL Server быть единственным главным приложением на физическом сервере.

Если ваш Сервер SQL не выполняет никакие другие приложения, и обмен страницами превышает 20 в среднем в течение 24 часов, это может означать, что Вы изменили параметры настройки памяти SQL Server. SQL Server должен быть конфигурирован так, чтобы была установлена опция "Dynamically configure SQL Server memory" (Динамически конфигурировать память SQL Server), а установка "Maximum Memory" должна находиться в наибольшем значении. Для оптимальной работы, SQL Server нужно позволить взять столько оперативной памяти, сколько ему требуется для собственных нужд, не испытывая необходимости конкурировать за оперативную память с другими приложениями.

Память: Доступное пространство

Другой способ выяснить, имеет ли ваш SQL Server достаточно физической оперативной памяти, состоит в том, чтобы проверить счетчик Memory Object: Available Bytes. Его значение должно быть более 5 МБ. В противном случае, ваш Сервер SQL нуждается в большем количестве физической оперативной памяти. На сервере, специализированном под SQL Server, последний пытается удерживать от 4-10MB свободной физической памяти. Оставшаяся физическая оперативная память используется операционной системой и SQL Server. Когда объем доступной памяти близко к 5 МБ или ниже, наиболее вероятно, что SQL Server испытывает перегрузку из-за нехватки памяти. Если это имеет место, Вы должны увеличить количество физической оперативной памяти в сервере, уменьшить нагрузку на сервер или изменить параметры настройки конфигурации памяти вашего SQL Server соответственно.

Физический диск: Время работы диска %

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

Как эмпирическое правило, счетчик времени диска должен показывать менее 55 %. Если показания счетчика превышают 55 % в течение непрерывных периодов (свыше 10 минут в течение ваших 24 часов мониторинга), то ваш SQL Server может испытывать проблемы с операциями ввода/вывода. Если Вы наблюдаете это поведение лишь изредка в течение ваших 24 часов мониторинга, я бы не волновался слишком сильно, но если бы это случалось часто (скажем, несколько раз час), то я начал бы искать способы увеличить производительность операций ввода/вывода на сервере или уменьшить загрузку сервера. Некоторые способы увеличивать дисковый ввод/вывод состоят в добавлении новых дисков в массив (если это возможно), замены дисков на более быстрые, добавлении кэш-памяти на плате контроллера (если это возможно), использования различных версий RAID или установки более быстрого контроллера.

Перед использованием этого счетчика под NT 4.0, нужно вручную включить его, введя в Command Prompt следующее: "diskperf-y". После этого нужно будет перезагрузить ваш сервер. Таким образом, требуется сразу включать дисковые счетчики под Windows NT 4.0. Если Вы работаете под Windows 2000, этот счетчик включен по умолчанию.

Физический диск: Средняя длина очереди диска

Помимо наблюдения за значением счетчика "Физический Диск: Время работы диска", желательно также отслеживать значения счетчика средней длины очереди диска (Avg. Disk Queue Length). Если это значение превышает значение 2 для непрерывных периодов (свыше 10 минут в течение вашего 24 часового мониторинга) для каждого дисковода в массиве, то этот массив может оказаться узким местом производительности системы. Подобно счетчику времени работы диска, если это происходит изредка в течение 24 часов периода мониторинга, я не сильно бы волновался, но если это происходит часто, тогда я бы начал искать способы увеличить производительность системы ввода/вывода сервера, как это описано выше.

Вам придется вычислить этот показатель, поскольку Performance Monitor не знает, сколько физических дисков находится в вашем массиве. Например, если у вас имеется массив из 6 физических дисков, и средняя длина очереди равна 10 для этого массива, тогда фактическое среднее значение дисковой очереди для каждого диска составляет 1.66 (10/6=1.66), что хорошо укладывается в рекомендованный показатель 2 на один физический диск.

Перед использованием этого счетчика под NT 4.0, не забудьте вручную включить его, набрав на приглашение к вводу команд NT (Command Prompt) следующее: "diskperf-y" с последующей перезагрузка вашего сервера. Поэтому требуется включать дисковые счетчики сразу после установки Windows NT 4.0. Если Вы используете Windows 2000, то этот счетчик будет включен по умолчанию.

Используйте оба описанных выше счетчика, чтобы точно выяснить, испытывает ли ваш сервер проблемы с системой ввода/вывода. Например, если Вы видите много периодов времени, в течение которых время работы диска более 55 %, и когда среднее значение длины очереди диска составляет более 2 на один физический диск, Вы можете быть уверенными, что сервер имеет проблемы с системой ввода - вывода.

Процессор: Процессорное время %

Счетчик Processor Object: % Processor Time имеется для каждого центрального процессора и оценивает использование каждого отдельного центрального процессора. Аналогичный счетчик имеется также для всей совокупности центральных процессоров (общее количество). Это ключевой счетчик для слежения за использованием центрального процессора. Если общее время загрузки процессоров по этому счетчику превышает 80 % в течение непрерывных периодов (свыше 10 минут в течение 24 часового периода мониторинга), то Вы можете считать центральный процессор узким местом системы. Если эти периоды сильной загрузки происходят изредка, и Вы полагаете, что можете смириться с этим, то все в порядке. Но если они возникают часто, Вам следует рассмотреть такие варианты снижения загрузки сервера, как приобретение более быстрых центральных процессоров, установку большего количества центральных процессоров, или приобретение центральных процессоров, которые имеют больший встроенный кэш второго уровня (L2).

Система: Длина очереди процессора

Наряду со счетчиком процессорного времени, Вам следует также контролировать счетчик длины очереди процессора (Processor Queue Length). Если этот показатель превышает значение 2 на один центральный процессор в течение непрерывных периодов (свыше 10 минут в течение вашего 24 часового периода мониторинга), то вероятно это является узким звеном системы. Например, если на Вашем сервере имеется 4 центральных процессора, длина очереди процессора не должна превышать в общей сложности значение 8.

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

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

Буфер SQL Server: Коэффициент удачного обращения в кэш буфера

Этот счетчик (SQL Server Buffer: Buffer Cache Hit Ratio) показывает, как часто SQL Server обращается к буферу, а не к жесткому диску, чтобы получить данные. В приложениях OLTP, этот коэффициент должен превышать 90 %, а в идеале быть выше 99 %. Если ваш коэффициент удачного обращения в буферный кэш ниже 90 %, Вам следует пойти и купить больше оперативной памяти уже сегодня. Если этот коэффициент лежит в диапазоне между 90 % и 99 %, то Вы должны серьезно рассмотреть вариант покупки дополнительной оперативной памяти, так как чем ближе Вы приближаетесь к 99 %, тем быстрее ваш SQL Server будет работать. В некоторых случаях, если ваша база данных является очень большой, Вам не удастся приблизиться к 99 %, даже если Вы поставите максимально допустимое количество оперативной памяти на вашем сервере. Тогда все, что Вы можете сделать, - это добавить память по максимуму и смириться с существующим положением вещей.

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

SQL Server: Пользовательские подключения

Поскольку число пользователей Сервер SQL, влияет на его производительность, рекомендуется следить за счетчиком пользовательских подключений (SQL Server General Statistics Object: User Connections counter). Он показывает число пользовательских подключений, а не число пользователей, которые подключены к SQL Server в данный момент времени.

Если показания этого счетчика превышают 255, то Вам следует увеличить значение конфигурационного параметра "Maximum Worker Threads" (максимальное число рабочих нитей), значение по умолчанию которого равно 255. Если число подключений превышает имеющееся число рабочих нитей, то SQL Server начнет совместно использовать рабочие нити, что может отрицательно сказаться на производительности. Установка этого параметра должна быть выше, чем максимальное число подключений, которое может быть достигнуто на вашем сервере.

Что дальше

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

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

и еще, как можно проследить за действиями пользователей?

Что ты хочешь отслеживать?

Если историю посомтреть с графиками то это Data Collection

Если надо на данный момент посомреть то можно пользоваться Data management View а ля

SELECT * FROM sys.dm_exec_sessions AS des

SELECT * FROM sys.dm_exec_requests AS der

или по старинке exec sp_who

либо запустить монитор активности =)

Судя по тому что ты там ничего не видишь, то на сервере у вас 1 запрос в час, который SQL смело делает.

Спрашивается зачем что-то завершать? Если уж на то пошло сессии ниже 50 - это системные службы и на них думаю пока не стоит замахиватьсяч если не понимаешь что делаешь.

Для начала попробуй вот так

SELECT * FROM sys.dm_exec_requests AS der WHERE der.session_id > 50

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

SELECT = s.session_id, = CONVERT(CHAR(1), s.is_user_process), = s.login_name, = ISNULL(db_name(p.dbid), N""), = ISNULL(t.task_state, N""), = ISNULL(r.command, N""), = ISNULL(s.program_name, N""), = ISNULL(w.wait_duration_ms, 0), = ISNULL(w.wait_type, N""), = ISNULL(w.resource_description, N""), = ISNULL(CONVERT (varchar, w.blocking_session_id), ""), = CASE -- session has an active request, is blocked, but is blocking others or session is idle but has an open tran and is blocking others WHEN r2.session_id IS NOT NULL AND (r.blocking_session_id = 0 OR r.session_id IS NULL) THEN "1" -- session is either not blocking someone, or is blocking someone but is blocked by another party ELSE "" END, = s.cpu_time, = (s.reads + s.writes) * 8 / 1024, = s.memory_usage * 8192 / 1024, = ISNULL(r.open_transaction_count,0), = s.login_time, = s.last_request_start_time, = ISNULL(s.host_name, N""), = ISNULL(c.client_net_address, N""), = ISNULL(t.exec_context_id, 0), = ISNULL(r.request_id, 0), = ISNULL(g.name, N"") FROM sys.dm_exec_sessions s LEFT OUTER JOIN sys.dm_exec_connections c ON (s.session_id = c.session_id) LEFT OUTER JOIN sys.dm_exec_requests r ON (s.session_id = r.session_id) LEFT OUTER JOIN sys.dm_os_tasks t ON (r.session_id = t.session_id AND r.request_id = t.request_id) LEFT OUTER JOIN (-- In some cases (e.g. parallel queries, also waiting for a worker), one thread can be flagged as -- waiting for several different threads. This will cause that thread to show up in multiple rows -- in our grid, which we don"t want. Use ROW_NUMBER to select the longest wait for each thread, -- and use it as representative of the other wait relationships this thread is involved in. SELECT *, ROW_NUMBER() OVER (PARTITION BY waiting_task_address ORDER BY wait_duration_ms DESC) AS row_num FROM sys.dm_os_waiting_tasks) w ON (t.task_address = w.waiting_task_address) AND w.row_num = 1 LEFT OUTER JOIN sys.dm_exec_requests r2 ON (s.session_id = r2.blocking_session_id) LEFT OUTER JOIN sys.dm_resource_governor_workload_groups g ON (g.group_id = s.group_id) LEFT OUTER JOIN sys.sysprocesses p ON (s.session_id = p.spid) ORDER BY s.session_id;

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

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

версии 11.0.1 имеет ряд новых важных возможностей, существенно отличающих новую версию от всех предыдущих. 11.0.1 может работать с любой версией SQL Server, начиная с 4.9.2 и кончая System 11.

Однако некоторые наиболее интересные виды информации о характере использования объектов баз данных и взаимодействии сервера с сетью выдаются только при мониторинге SQL Server System 10 и System 11. Естественно, данные о работе именованных кэш-буферов выдаются только при контроле производительности SQL Server System 11.

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

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

При запуске необходимо отменить проверку памяти сервера, выполняемую командой dbcc memusage, поскольку эта команда существенно замедляет работу сервера. Для этого при запуске sqlmon (клиентского модуля) необходимо указать параметр – nomem.

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

Максимальное количество одновременно открытых окон клиентов устанавливается при запуске серверного модуля.

Так, для поддержки 20 окон в командном файле запуска серверного модуля необходимо указать параметр п2 0. При этом потребуется изменить адрес начала разделяемой области памяти сервера с помощью команды buildmaster и некоторых других действий. Эти действия ни в коем случае нельзя производить во время работы SQL Server. (Подробно о процессе расширения количества одновременно поддерживаемых клиентов см. в руководстве по серверному модулю Server Supplement.)

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

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

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

также не позволяет долгое время выдавать на экран динамику изменения показателей производительности.

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

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

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

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

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

Главное окно (Main Window)
Здесь содержится перечень окон, поддерживаемых программой. В случае, если при запуске sglmon - клиентского модуля - не был указан параметр – nomem, в этом окне также будет выдана круговая диаграмма использования памяти серверной машины.

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

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

Дисковый ввод/вывод (Device I/O)
Здесь находятся графики и сводные таблицы по текущему и полному количеству обращений к дискам. Они помогают оптимизировать распределение нагрузки ввода-вывода среди имеющихся серверных устройств. При анализе выдаваемой информации полезно использовать стандартную схему выбора названий серверных устройств по названиям соответствующих разделов физических дисков, поскольку, наблюдая за скоростью обмена с серверными устройствами, следует знать, к какому дисковому контроллеру подключено каждое из этих устройств.

Работа с сетью, только для SQL Server System 10 и 11 (Network Activity)
В окне сообщается статистическая информация о сетевом вводе”выводе - размеры пакетов, объемы трафика и т.п.

Блокировка доступа к объектам, только для SQL Server System 10 и 11 (Object Lock Status)
Здесь выдается информация о блокировках доступа к таблицам данных, включая подробное распределение используемых типов блокировок, названия процессов, удерживающих блокировки и т.д.

Ввод-вывод страниц объектов, только для SQL Server System 10 и 11 (Object Page I/O)
Окно содержит информацию об интенсивности ввода-вывода страниц одной из таблиц данных сервера. Обратите внимание на эффективность при составлении перечня наиболее часто используемых таблиц сервера. Подобные сведения не выдаются процедурой sp_sysmon.

Сводка данных о производительности (Performance Summar)
Здесь представлена общая картина функционирования SQL Server - процент использования времени процессора, количество обрабатываемых транзакций в секунду, объем сетевого трафика, дискового ввода-вывода, а также интенсивность использования блокировок.

Динамика показателей производительности (Performance Trend)
В окне строятся непрерывные графики зависимости от времени показателей производительности сервера, выдаваемых в окне Performance Summary.

Активность серверных процессов (Process Activit)
Окно позволяет выбрать один или несколько серверных процессов и следить за использованием процессора и объемами ввода-вывода по каждому из процессов.

Подробные данные о процессе (Process Detail)
Окно содержит подробную информацию о выбранном серверном процессе.

Список процессов (Process List)
Окно содержит перечень всех имеющихся в данный момент серверных процессов с указанием их состояния. Очень похоже на выдачу серверной команды sp_who.

Использование блокировок (Process Lock Activity)
Окно выдает информацию об использовании блокировок выбранным вами серверным процессом.

Использование хранимых процедур (Stored Procedure Activity)
Окно содержит сведения о выполнении хранимых процедур и времени работы каждой процедуры.

Обработка транзакций (Transaction Activity)
В окне можно увидеть столбчатую диаграмму, показывающую количество обрабатываемых транзакций с распределением по различным типам транзакций. Видно, например, какую часть транзакций удается выполнить с использованием механизма обновления записей на месте (update in place).