Рассылка закрыта
При закрытии подписчики были переданы в рассылку "Вопросы и ответы по MS SQL Server" на которую и рекомендуем вам подписаться.
Вы можете найти рассылки сходной тематики в Каталоге рассылок.
MS SQL Server - дело тонкое...
Информационный Канал Subscribe.Ru |
#149<< #150 |
СОДЕРЖАНИЕ
Счётчики производительности SQL Server и Windows
1. Введение
Анализ проблем с производительностью сервера стоит начинать с мониторинга счётчиков памяти. Особое внимание
стоит уделить свопингу, т.е. подкачке страниц памяти. Большой свопинг может существенно утилизировать ресурсы
компьютера и очень сильно повлиять на время отклика системы.
5.1. Поиск узких мест использования памяти Windows 2000 Следующие счетчики позволяют обнаружить узкие места в ресурсах памяти Windows 2000:
При мониторинге производительности экземпляра Microsoft SQL Server необходимо выяснить, используется ли им память
в допустимых пределах и не испытывает ли SQL Server и другие процессы недостаток памяти или же он потребляет её
слишком много.
5.2. Наборы счётчиков мониторинга памяти Для контроля производительность физической и виртуальной памяти Windows 2000, используйте следующий набор счётчиков:
Для контроля производительность кэша Windows 2000, используйте следующий набор счетчиков:
Для контроля производительность использования памяти SQL Server, используйте следующий набор счетчиков:
По умолчанию, SQL Server захватывает необходимую ему память динамически, при наличии доступных системных ресурсов.
Если SQL Server нуждается в увеличении используемого объёма памяти, он делает запрос к операционной системе, чтобы
определить, является ли свободная физическая память доступной и если это так, он её использует. Если SQL Server
больше не нуждается в памяти, которая была ему распределена, он отдаёт её операционной системе. Однако, опция
динамического использования памяти может быть отменена через параметры конфигурации min server memory, max server
memory и set working set size.
5.3. Системная таблица sysperfinfo
Кроме System Monitor, для получения значений счётчиков производительности, можно использовать системную таблицу
базы данных master - sysperfinfo. Нужно только помнить, что значения, которые хранятся в колонке cntr_value, не
являются теми значениями, которые Вы можете наблюдать на графики монитора производительности. Эти значения нужно
подставить в формулу для данного типа счётчика, масштабировать соответствующим образом и тогда получатся привычные
цифры. Необходимые формулы были приведены при описании типов счётчиков. SQL Server\Buffer Manager\Buffer Cache Hit Ratio вычисляется по следующей формуле из значений sysperfinfo: SQL Server\Buffer Manager\Buffer Cache Hit Ratio = (Buffer Cache Hit Ratio / Buffer cache hit ratio base)*100 Значение Buffer Cache Hit Ratio относится к типу с кодом 537003008, а значение Buffer cache hit ratio base относится к типу с кодом 1073939459 Далее, по аналогии, напишем формулу для расчёта удобного для анализа формата значения счётчика SQL Server\Cache Manager Object\Cache Hit Ratio: SQL Server\Cache Manager Object\Cache Hit Ratio = (Cache Hit Ratio с типом 537003008 / Cache Hit Ratio с типом 1073939459)*100 Как Вы видите, поскольку типы обоих счётчиков совпадают и это тип: PERF_RAW_FRACTION с кодом 537003008, вычисления выполняются по одинаковой формуле: (N0 / D0). Для масштабирования также подходит одинаковый коэффициент 100, который позволяет увидеть процентное соотношение текущего и базового показателя. Из оставшихся двух, рекомендуемых для поиска узких мест счётчиков, значение Process\Working Set в таблице sysperfinfo отсутствует, т.к. эта таблица содержит только счётчики, относящиеся к SQL Server. Значение счётчика SQL Server\Memory Manager\Total Server Memory (KB) - может быть использовано без изменений, т.к. хранит текущий размер занимаемой памяти в килобайтах.
5.4. Диагностика всплесков отложенной записи
Вы можете наблюдать задержки физического дискового чтения и записи при запросах на I/O разделяемого между процессами дискового контроллера. Вызвано это может быть действиями клиентов, которые провоцируют повторное заполнение страницами буферного кэша, записываемые после этого на диск. Также, к подобным эффектам может привести массовое и продолжительное размещение страниц, которые должны быть записаны из буферного кэша на диск. Ещё одной причиной может быть то, что системный процесс отложенной записи совпадает или близок по времени с контрольной точкой базы данных, или если контрольная точка исполняется на базе данных, которая содержит подлежащие записи на диск страницы. В отличии от предыдущих версий, SQL Server 2000 имеет более высокую склонность к активности отложенной записи. Именно по этому, в SP3 был введён новый флаг трассировки T809, который как раз и призван решить эту проблему. Более подробно об этом флаге написано в статье FIX: SQL Server 2000 May Be More Aggressive with Lazy Writes Than SQL Server 7.0 ПРОДОЛЖЕНИЕ СЛЕДУЕТ Эффективный метод постраничной выборки. Предлагаемый метод не претендует на звание самого лучшего. Он, может быть, и не лучше, но уж точно не хуже других. Поиск решения основывался на следующих пожеланиях:
1. Обращение к новой странице выборки не должно приводить к перезапросу всей выборки. Решение, удовлетворяющее всем этим пожеланиям стразу, было найдено. Вот оно: 1. Имеем запрос, который мы хотим выбирать постранично select * from BigTable мы его не запускаем, а переходим к шагу 2. 2. Инициализируем таким образом:
declare @handle int,@rows int При этом получаем пустой рекордсет, содержащий метаданные-описания колонок, которые можно использовать для получения названия полей (и типов). После NextRecordset также получаем хендл получившегося курсора и кол-во строк во всей выборке. Хендл нам понадобиться для подстановки в следующие вызовы, и его надо сохранить на клиенте в глобальную переменную, а кол-во строк может быть использовано для определения кол-ва страниц. 3. Получаем нужную страницу из выборки: exec sp_cursorfetch @handle,16,@rowid,@rowcount Где в @handle подставляем сохраненное значение хендла, в @rowid подставляется номер строки, с которой начинается интересующая нас страница, а в @rowcount подставляется кол-во строк на данной странице. Шаг 3 повторяем столько сколько нужно раз. 4. Освобождаем ресурсы после того, как страницы уже больше не понадобятся exec sp_cursorclose @handle
Глеб Уфимцев Статьи на русском языке
Мобильный OLAP
Новые и обновлённые технические статьи Microsoft
BUG: DBO User Does Not Display in Enterprise Manager
Who Are You? (as a DBA)
Самые популярные темы недели
Междумордие
печально все это... (SELECT... FOR XML) Рассылка: Вопросы и ответы по Microsoft SQL Server
Автор рассылки: Сергей Кошкин
Выпуск No. 18 от 2003-06-20
|
http://subscribe.ru/
E-mail: ask@subscribe.ru |
Отписаться
Убрать рекламу |
В избранное | ||