|
 |
|
| | |
| |
Заметки по оптимизации и быстродействию MSSQL
Основные этапы:
Выявление узких мест в конфигурации оборудования и опциях MSSQL
Выявление ресурсоемких операций
- выборки с неоптимальным планом (отсутствие необходимых индексов)
- наличие циклов или курсоров
- последовательные операции обновления/вставки
- перекомпиляции хранимых процедур
- динамический sql
Выявление взаимоблокирующих процессов
При обнаружении задержек в работе сервера первое с чего имеет смысл начать исследование
- наблюдение за счетчиками производительности.
Основные из них
загрузка CPU вцелом и экземпляром MSSQL в частности (% Processor Time)
очередь операций чтения/записи HDD (Average Disk Queue Length)
Использование RAM и файла подкачки. (Total Server Memory, Pages/Sec)
Использование сетевого адаптера (Bytes Total/sec)
Соответственно, в зависимости от полученных результатов, существует два способа решения проблем:
обновить компоненты оборудования, которые являются узкими местами или оптимизировать
программное обеспечение ( серверную и/или клиентскую часть)
для запуска монитора счетчиков производительности запустите из командной строки: Perfmon.exe
описание наиболее важных счетчиков счетчики
Выявление ресурсоемких операций.
Для выявления ресурсоемких операций происходящих на MSSQL используют инструмент
SQL Server Profiler. Чтобы выявить какие запросы от реального клиентского приложения являются
наиболее трудными для сервера следует в моменты "существенных задержек" обратить внимание на строки
с большими значениями Duration.
Для автоматизированого выявления недостающих индексов используют Инструменты mssql 2000 Index Tuning Wizard (ITW)
и SQL Server 2005 Database Tuning Advisor (DTA). Суть процесса в сохранении инструментом Profiler трассы (перечня запускаемых батчей) в таблицу на сервере с тем чтобы затем эти данные проанализировать утилитой тюнинга индексов и при необходимости автоматически создать недостающие.
В случае наличия трудоемкой процедуры которая содержит курсор или цикл while следует, по возможности,
попытаться переделать запрос без использования этих компонентов за счет использования подзапросов или UDF.
Избежать задержек или увеличить скорость вставки (обновления) данных в случае если эти обновления выполняится ввиде последовательности одиночных комманд возможно достичь следующими способами:
- включение кэширования записи на дисках (в случае наличия бесперебойного питания и надежного оборудования)
на которых расположены файлы данных и лога может дать прирост быстродействия в десятки раз для некоторых операций.
- включение нескольких (возм. Десятков или сотен) отдельных команд обновления в один пакет обернутый транзакцией.
Использование одной транзакции для пакета может дать хороший выигрыш за счет меньшего количества дисковых операций по фиксации лога и данных на диске, особенно если кэширование записи запрещено.
Дело в том что даже если транзакция явно не объявлена то любая операция изменения данных вызывает на сервере микротранзакцию которая должна быть зафиксирована на диске до следующей операции по изменению данных.
Следует отметить что важно обеспечить чтобы транзакция не происходила длительное время и не блокировала критически важные ресурсы.
- замена одиночных вставок массовыми: DTS импорт, подключение внешнего источника данных как linked server
Ожидание освобождения блокировок может стать причиной достаточно большой продолжительности даже простейшего запроса.
Поэтому в случае если для запроса не критично что в него могут попасть данные из незавершенной транзакции
то следует указать хинт with (nolock) в предложении from после имени таблицы.
Если для всех операций пакета или хранимой процедуры допускаются "грязные данные" то возможно в начале установить
уровень изоляции транзакции read uncommitted и начать транзакцию,при этом важно не забыть в конце батча или процедуры откатить или подтвердить транзакцию.
Статьи:
Статьи по тюнингу MSSQL на русском языке
| |
| | |
