Оптимизация производительности ЦП SQL Server

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

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

Два пути, ведущие в одно место

Если рассматривать в целом, существует два пути
определения заморочек производительности микропроцессора. 1-ый
заключается в анализе производительности оборудования системы, что
помогает найти места для поиска трудности при переходе ко
второму пути, оценке эффективности выполнения сервером запросов.
2-ой путь обычно более эффективен для определения заморочек
производительности SQL Server™. Но если предпосылки заморочек
производительности запросов точно не известны, всегда следует
начинать с анализа производительности системы В конечном счете,
обычно вы оказываетесь на обоих путях. Давайте разглядим некие
главные моменты, чтоб можно было перейти к рассмотрению обоих
путей.

Разработка
гиперпоточности

На технологии гиперпоточности стоит тормознуть из-за того, как
она оказывает влияние на SQL Server. Разработка гиперпоточности практически
предоставляет операционной системе для 1-го физического микропроцессора
два логических микропроцессора. На самом деле, разработка гиперпоточности
арендует время физических микропроцессоров для полного использования
способностей каждого микропроцессора. На веб-узле Intel (intel.com/technology/platform-technology/hyper-threading/index.htm)
представлено еще более подробное описание работы технологии
гиперпоточности.

В системах SQL Server DBMS практически обрабатывает собственные
очень действенные очереди и потоки для операционной системы,
потому в системах с уже имеющейся высочайшей загрузкой микропроцессоров
разработка гиперпоточности только еще более перегружает физические
ЦП. Когда SQL Server производит постановку в очередь нескольких
запросов для работы с несколькими планировщиками, операционной
системе приходится переключать контекст потоков команд для
обеспечения соответствия выполняемым запросам, даже если два
логических микропроцессора принадлежат одному физическому микропроцессору.
Если показатель «Контекстных переключений/сек» превосходит 5000 для
1-го физического микропроцессора, следует серьезно разглядеть вопрос
об выключении гиперпоточности в системе и повторном тестировании
производительности.

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

Главные
моменты

Производительность массивного двухъядерного
микропроцессора всегда будет превосходить производительность ОЗУ
компьютера, скорость которого в свою очередь будет больше скорости
присоединенного запоминающего устройства. Пропускная способность
неплохого микропроцессора примерно в 6 раз превосходит
пропускную способность наилучшей современной памяти DDR2 и
примерно вдвое превосходит пропускную способность наилучшей
памяти DDR3. Пропускная способность обыкновенной памяти более чем в 10
раз превосходит пропускную способность самых стремительных оптоволоконных
приводов. В свою очередь, жесткие диски могут делать только
ограниченное число операций ввода/вывода за секунду (IOPS), это
значение всецело находится в зависимости от количества операций поиска за секунду,
которое может делать привод. Справедливости ради нужно сказать,
что для ублажения всех потребностей в хранении систем баз
данных компаний обычно употребляется несколько устройств хранения.
Сейчас в большинстве установок употребляются сети хранилищ данных
(SAN) на серверах баз данных компаний либо группы RAID большего
размера, которые могут минимизировать либо убрать делему
микропроцессора дискового ввода-вывода. Принципиально держать в голове, что независимо от
особенностей установки системы узенькие места со стороны дисков и
памяти могут воздействовать на производительность микропроцессоров.

Из-за различий в скорости ввода-вывода получение
данных с диска намного дороже, чем получение данных из памяти.
Размер странички данных в SQL Server – 8 КБ. Блок в SQL Server
состоит из восьми страничек размером 8 КБ любая и соответственно
имеет размер 64 КБ. Это принципиально осознавать, так как когда SQL Server
запрашивает определенную страничку данных с диска, производится
получение всего блока, в который заходит страничка данных, а не только лишь
этой определенной странички. Существует ряд обстоятельств, делающих это
более действенным для SQL Server, но в данной статье я не будут
рассматривать этот вопрос тщательно. Получение странички данных, уже
кэшированной из буферного пула, с наибольшей производительностью
производится в течение половины миллисекунды; получение 1-го блока
с диска в хорошей среде занимает от 2 до 4 миллисекунд. Обычно
чтение отлично работающей исправной дисковой подсистемы занимает от 4
до 10 мс. Получение странички данных из памяти обычно производится от
4 до 20 раз резвее, чем получение странички данных с диска.

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

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

Путь 1. Производительность системы

Существует всего несколько методов определения
наличия узеньких мест ЦП на сервере и не сильно много вероятных обстоятельств
высочайшей загрузки микропроцессора. Некие из этих заморочек можно
отследить при помощи системного монитора либо схожего средства
наблюдения за системой, другие же трудности можно отследить при помощи
профилировщика SQL либо схожих средств. Другой метод заключается в
использовании команд SQL в Query Analyzer либо SQL Server Management
Studio (SSMS).

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

Одним из самых узнаваемых счетчиков
производительности является счетчик «% загруженности процессора»; во
время работы системного монитора этот счетчик выделяется после
открытия окна «Add Counter» (Добавление счетчика). Счетчик «%
загруженности процессора» показывает время, в течение которого
микропроцессоры остаются занятыми при выполнении операций. Обычно,
загруженность микропроцессоров считается высочайшей, когда это значение
составляет 80 либо более процентов в течение большей части времени
работы с наибольшей загрузкой. Время от времени значение может в один момент
повышаться до 100 процентов, даже если сервер работает с загрузкой
наименее 80 процентов, но это не является неполадкой.

Другим счетчиком, который нужно
использовать, является «Длина очереди процессора», который находится
в объекте «Система» системного монитора. Счетчик «Длина очереди
процессора» указывает количество потоков, ожидающих выполнения на
микропроцессоре. Управление работой SQL Server осуществляется при помощи
планировщиков в механизме СУБД, где сервер помещает в очередь и
обрабатывает собственные запросы. Так как работа SQL Server
управляет им самим, он употребляет только один поток ЦП для каждого
логического микропроцессора. Это значит, что в очереди микропроцессора
системы, созданной для SQL Server, должно находиться
малое количество потоков. Обычно количество потоков на
выделенном сервере SQL Server в 5 раз меньше количества
физических микропроцессоров, но я считаю, что если количество потоков в
дважды превосходит количество физических микропроцессоров, это уже
является неувязкой. На серверах, где не считая СУБД употребляются и
другие приложения, этот счетчик нужно использовать вкупе со
счетчиками производительности «% загруженности процессора» и
«Контекстных переключений/сек» (переключения контекста будут
рассмотрены позднее) для определения необходимости перемещения СУБД
либо приложений на другой сервер.

При появлении очереди микропроцессора и высочайшей
загрузке ЦП я использую счетчики «Compilations/sec» (Компиляций/с) и
«Re-Compilations/sec» (Повторных компиляций/с) объекта
производительности «SQL Server: статистика SQL» (см. рис. 1). Компиляция и повторная компиляция
планов запросов оказывает влияние на загрузку ЦП системы. Значения повторных
компиляций должны быть около нуля, но нужно проверить потоки
системы, чтоб найти обыденное поведение сервера и допустимое
количество компиляций. Не всегда удается избежать повторных
компиляций, но можно улучшить запросы и хранимые процедуры,
чтоб свести к минимуму количество повторных компиляций и
использований планов запросов. Сравните эти значения с фактическими
поступающими в систему инструкциями SQL при помощи счетчика «Пакетных
запросов/с», который также находится в объекте «SQL Server:
статистика SQL». Если компиляции и повторные компиляции составляют
значимый процент поступающих в систему запросов пакетов, это
место нужно проверить. Время от времени разработчики SQL могут не
осознавать, как и почему их код может оказывать влияние на эти типы заморочек
системных ресурсов. Дальше в этой статье я приведу ссылки, которые
посодействуют свести к минимуму деяния такового типа.

Оптимизация производительности ЦП SQL Server
Рис.
1 Выбор счетчиков для отслеживания

В системном мониторе найдите счетчик
производительности «Контекстных переключений/сек» (см. рис. 2).

Рис. 2  Применяемые счетчики производительности

Счетчик производительности Объект счетчика Пороговое значение Примечания
«% применяемого времени процессора» Микропроцессор > 80% Вероятные предпосылки включают недочет памяти, редчайшее повторное внедрение плана запроса, неоптимизированные запросы.
«Контекстных переключений/сек» Система > 5000 x (число микропроцессоров) Вероятные предпосылки включают другие приложения на сервере, несколько экземпляров SQL Server на одно сервере, включение технологии hyper-threading.
«Длина очереди процессора» Система > 5 x (число микропроцессоров) Вероятные предпосылки включают другие приложения на сервере, огромное количество компиляций либо перекомпиляций, несколько экземпляров SQL Server на одно сервере.
«Compilations/sec» (Компиляций/с) SQLServer:статистика SQL Тенденция Сопоставление со счетчиком «Запросов пакетов/с»
«Re-Compilations/sec» (Перекомпиляций/с) SQLServer:статистика SQL Тенденция Сопоставление со счетчиком «Запросов пакетов/с»
«Запросов пакетов/с» SQLServer:статистика SQL Тенденция Сопоставление с количеством компиляций и перекомпиляций за секунду.
«Ожидаемый срок жизни страницы» SQLServer:диспетчер буферов < 300 Вероятная нехватка памяти.
«Отложенных записей/с» SQLServer:диспетчер буферов Тенденция Вероятный сброс огромного кэша данных либо нехватка памяти.
«Checkpoints/sec» (Контрольных точек/с) SQLServer:диспетчер буферов Тенденция Оценка контрольных точек при помощи счетчиков «Ожидаемый срок жизни страницы» и «Отложенных записей/с».
Коэффициент попадания в кэш: планы SQL SQLServer:кэш планов < 70% Показывает на редчайшее повторное внедрение плана.
Коэффициент попадания в буферный кэш SQLServer:диспетчер буферов < 97% Вероятная нехватка памяти.

Этот счетчик показывает количество
получений потоков из планировщиков операционной системы (не из
планировщиков SQL) для выполнения операций для других потоков в
состоянии ожидания. Нередко переключения контекста происходят
существенно почаще в системах база данных, использующихся вместе с
другими приложениями, к примеру IIS либо компонентами сервера
приложений посторониих производителей. Для счетчика «Контекстных
переключений/сек» я использую пороговое значение примерно в
5000 раз большее количества микропроцессоров в сервере. Это значение
также может быть высочайшим в системах с включенной гиперпоточностью и
низкой загрузкой ЦП. Если пороговые значения загрузки ЦП и
переключений контекста часто превышаются, это гласит о наличии
узенького места, связанного с ЦП. Если такие ситуации появляются
часто, и ваша система устарела, нужно запланировать
приобретение дополнительных либо более стремительных микропроцессоров.
Дополнительные сведения приведены на боковой панели
«Гиперпоточность».

Модуль отложенной записи SQL Server (как он
именуется в SQL Server 2000) либо монитор ресурсов (как он
именуется в SQL Server 2005) – это другая область для наблюдения
при высочайшей загрузке ЦП. Сброс буфера и кэши процедур могут
наращивать процессорное время через поток ресурсов, именуемый
монитором ресурсов. Монитор ресурсов – это процесс SQL Server,
определяющий странички для сохранения и странички для записи из
буферного пула на диск. Всем страничкам в буфере и кэшах процедур
вначале присвоены цены, представляющие ресурсы, потребляемые
при помещении этой странички в кэш. Эти значения стоимостей
уменьшаются при каждой проверке монитором ресурсов. При
необходимости для запроса места в кэше странички удаляются из
памяти на базе присвоенных для всех страничек издержек; странички с
самыми низками значениями будут удаляться сначала. Операции
монитора ресурсов можно отследить при помощи счетчика
производительности «Отложенных записей/с» объекта «SQL Server:
диспетчер буферов» системного монитора. Нужно отследить
изменение этого значения, чтоб найти обыденное для вашей системы
пороговое значение. Обычно этот счетчик употребляется вкупе со
счетчиками «Ожидаемый срок жизни страницы» и «Checkpoints/sec»
(Контрольных точек/с) для определения наличия нехватки памяти.

Счетчик «Ожидаемый срок жизни страницы» помогает
найти наличие нехватки памяти. Счетчик «Ожидаемый срок жизни
страницы» указывает продолжительность нахождения странички данных в
буферном кэше. Принятое в отрасли пороговое значение для этого
счетчика – 300 секунд. Значение ниже среднего значения в 300 секунд,
сохраняющееся в течение долгого времени, свидетельствует о том,
что странички данных удаляются из памяти очень нередко. Это
наращивает объем работы монитора ресурсов, что в свою очередь
приводит к повышению загрузки микропроцессоров. Показания счетчика
«Ожидаемый срок жизни страницы» должны оцениваться совместно с
показаниями счетчика «Страниц контрольных точек/с». При
появлении в системе контрольной точки «грязные» странички данных
в буферном кэше записываются на диск, вызывая уменьшение значения
счетчика «Ожидаемый срок жизни страницы». Процесс «Монитор ресурсов»
– это механизм, практически записывающий эти странички на диск,
потому при появлении контрольных точек также возрастает
значение счетчика «Отложенных записей/с». Если значение счетчика
«Ожидаемый срок жизни страницы» возрастает сходу после выполнения
контрольной точки, на это временное явление можно не обращать
внимание. С другой стороны, при обнаружении того, что значение
счетчика «Ожидаемый срок жизни страницы» часто находится ниже
порогового значения, велика возможность, что повышение объема
памяти приведет к устранению заморочек и освобождению части ресурсов
для ЦП. Все эти счетчики находятся в объекте производительности «SQL
Server: диспетчер буферов».

Отслеживание SP

При трассировке приложения SQL Server имеет смысл ознакомиться с
применяемыми для трассировки хранимыми процедурами. Внедрение
для трассировки графического интерфейса (SQL Server Profiler) может
прирастить нагрузку на систему на 15 – 25 процентов. Внедрение
для трассировки хранимых процедур может понизить процент роста
нагрузки приблизительно наполовину.

Если мне понятно о наличии в системе узеньких мест и нужно
найти текущие аннотации SQL, являющиеся причинами заморочек на
сервере, я выполняю приведенный ниже запрос. Этот запрос помогает
получить представление об отдельных инструкциях и применяемых ими в
реальный момент ресурсах, также об инструкциях, которые
нужно изучить для увеличения производительности. Дополнительные
сведения о трассировках SQL приведены на интернет-странице msdn2.microsoft.com/ms191006.aspx.

SELECT
substring(text,qs.statement_start_offset/2
,(CASE
WHEN qs.statement_end_offset = -1 THEN len(convert(nvarchar(max), text)) * 2
ELSE qs.statement_end_offset
END – qs.statement_start_offset)/2)
,qs.plan_generation_num as recompiles
,qs.execution_count as execution_count
,qs.total_elapsed_time – qs.total_worker_time as total_wait_time
,qs.total_worker_time as cpu_time
,qs.total_logical_reads as reads
,qs.total_logical_writes as writes
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
LEFT JOIN sys.dm_exec_requests r
ON qs.sql_handle = r.sql_handle
ORDER BY 3 DESC

Путь 2. Производительность запросов

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

Ниже приведены некие принципиальные моменты,
касающиеся оптимизации ЦП для T-SQL.

Повторное внедрение плана запроса
Уменьшение количества компиляций и повторных компиляций
Операции сортировки
Недопустимые соединения
Отсутствующие индексы
Просмотры таблиц/индексов
Внедрение функций в предложениях SELECT и WHERE
Многопоточные операции

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

1-ый пример – это ситуация с огромным
количеством транзакций, в какой повторное внедрение плана
находится в зависимости от приложения. Редчайшее повторное внедрение плана
обуславливает огромное число компиляций инструкций SQL, зачем
требуется значимый объем процессорной обработки. Во 2-м
примере высочайшая загрузка ресурсов может привести к лишней
активности системного ЦП, так как требуется неизменное удаление
имеющихся данных из буферного кэша для освобождения места
для новых страничек данных огромного объема.

Разглядим систему с высочайшей интенсивностью
транзакций, в какой аннотация SQL, схожая показанной ниже,
производится 2000 раз в течение 15 минут для получения инфы о
транспортной упаковке. Гипотетически, без повторного использования
плана запроса время выполнения одной аннотации составляет около 450
мс. При использовании этого же плана запроса после первого
выполнения время выполнения следующего запроса может составлять
около 2 мс, а общее время выполнения – около 5 секунд.

USE SHIPPING_DIST01;
SELECT
Container_ID
,Carton_ID
,Product_ID
,ProductCount
,ModifiedDate
FROM Container.Carton
WHERE Carton_ID = 982350144;

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

Задачи пакетной компиляции, перекомпиляции и кэширования
плана в SQL Server 2005
(microsoft.com/technet/prodtechnol/sql/2005/recomp.mspx)
Оптимизация хранимых процедур SQL Server для предотвращения
перекомпиляций
(sql-server-performance.com/rd_optimizing_sp_recompiles.asp)
Перекомпиляция запроса в SQL Server 2000
(msdn2.microsoft.com/aa902682.aspx)

Полезным источником широких сведений являются
динамические административные представления (DMV). При высочайшей
загрузке ЦП я использую несколько DMV для определения корректности
использования ЦП.

Одним из применяемых DMV является
sys.dm_os_wait_stats, при помощи которого админам баз данных
можно предоставить средства определения всех применяемых сервером
SQL функций и типов ресурсов, также найти время ожидания
системы, связанное с этим ресурсом. Счетчики в этом DMV являются
накопительными. Это значит, что для получения четкого понятия
о ресурсах, которые могут оказывать влияние на разные области системы, после
проверки данных на предмет наличия неразрешенных заморочек до этого
всего нужно выполнить команду DBCC
SQLPERF(‘sys.dm_os_wait_stats’, CLEAR). Динамическое
административное представление sys.dm_os_wait_stats является
эквивалентом команды проверки согласованности базы данных DBCC
SQLPERF(WAITSTATS) в SQL Server 2000. Дополнительные сведения о
разных типах ожидания приведены в электрической документации по SQL
Server на веб-узле msdn2.microsoft.com/ ms179984.aspx.

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

Динамическое административное представление
sys.dm_exec_sessions указывает все открытые сеансы на сервере SQL
Server. Это DMV предоставляет обобщенное представление
производительности всех сеансов и всех действий, выполненных в
каждом сеансе с момента открытия. Сюда прогуливается общее время ожидания
сеанса, общая загрузка ЦП, внедрение памяти и количество
операций чтения и записи. DMV также предоставляет сведения о входе,
времени входа, локальном компьютере и времени последнего запроса
сеансом сервера SQL Server.

Динамическое административное представление the
sys.dm_exec_sessions позволяет определять только активные сеансы,
потому это одно из первых мест для поиска при высочайшей загрузке ЦП.
Поначалу нужно делать проверку сеансов с огромным числом ЦП.
Обусловьте приложение и юзера, выполняющего работу, потом
перейдите к углубленному анализу. Внедрение sys.dm_exec_sessions
вкупе с sys.dm_exec_requests может предоставить огромное количество
инфы, доступной через хранимые процедуры sp_who и sp_who2. При
объединении данных с функцией динамического управления
sys.exec_sql_text в столбце sql_handle можно получить текущий
выполняемый запрос сеанса. Во куске кода на рис. 3 продемонстрировано объединение этих данных
для получения сведений о том, что происходит на сервере.

Рис. 3  Определение активности сервера

SELECT es.session_id
,es.program_name
,es.login_name
,es.nt_user_name
,es.login_time
,es.host_name
,es.cpu_time
,es.total_scheduled_time
,es.total_elapsed_time
,es.memory_usage
,es.logical_reads
,es.reads
,es.writes
,st.text
FROM sys.dm_exec_sessions es
LEFT JOIN sys.dm_exec_connections ec
ON es.session_id = ec.session_id
LEFT JOIN sys.dm_exec_requests er
ON es.session_id = er.session_id
OUTER APPLY sys.dm_exec_sql_text (er.sql_handle) st
WHERE es.session_id > 50 — < 50 system sessions
ORDER BY es.cpu_time DESC

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

Для отслеживания инструкций SQL по журнальчику для
приложения я использую трассы SQL Server. Для этого можно
использовать средство SQL Server Profiler либо системные хранимые
процедуры трассировки, чтоб оценить происходящее. (Дополнительные
сведения по данной теме приведены на боковой панели «Трассировка SP».)
В программке Profiler нужно проверить операторы с высочайшей
загрузкой ЦП, предупреждения хэширования и сортировки, промахи в
кэше и другие красноватые флаги. Это позволяет сузить объекты проверки
до определенных операторов SQL либо периода времени с высочайшей
загрузкой ресурсов. Программка Profiler позволяет выслеживать текст
инструкций SQ, планы выполнения, загруженность ЦП, внедрение
памяти, логические считывания, запись, кэширование планов запросов,
перекомпиляции, извлечение планов запросов из кэша, промахи в кэше,
просмотры таблиц и индексов, отсутствие статистики и огромное количество
других событий.

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

SELECT * INTO trc_20070401
FROM fn_trace_gettable(‘S:MountpointsTRC_20070401_1.trc’, default);
GO

Заключение

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

Аналогичный товар: Комментирование на данный момент запрещено, но Вы можете оставить ссылку на Ваш сайт.

Комментарии закрыты.