Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: ←Ctrl  назад   1 2 [3] 4 5 6   вперед  Ctrl→      все
 Re: Рестарт служб sql влияет на производительность бизнес приложения.  [new]
Ondayl
Member

Откуда:
Сообщений: 231
 		Мне счетчики пустить одновременно с трасой ? Траса же нагрузит сервер, не ?
3 июл 14, 08:37    [16252686]     Ответить | Цитировать Сообщить модератору
 Re: Рестарт служб sql влияет на производительность бизнес приложения.  [new]
Ondayl
Member

Откуда:
Сообщений: 231
 		Прочитал вот тут. Ваше мнение ? Насколько это справедливо ? У меня среднее значение этих счетчиков по 4-8, но всплески бывают до 70.
4 июл 14, 11:16    [16258866]     Ответить | Цитировать Сообщить модератору
 Re: Рестарт служб sql влияет на производительность бизнес приложения.  [new]
Ondayl
Member

Откуда:
Сообщений: 231
 		Итак, то что у меня крупные проблемы с дисковой подсистемой я осознал. Каковы мои шаги дальше ? Бежать тратить средства на другую дисковую, или пытаться заняться каким то "тюнигом" запросов ? Как мне понять, что в моей ситуации делать ?
7 июл 14, 11:38    [16268549]     Ответить | Цитировать Сообщить модератору
 Re: Рестарт служб sql влияет на производительность бизнес приложения.  [new]
gandjustas
Member

Откуда:
Сообщений: 857
Блог
Ondayl
Итак, то что у меня крупные проблемы с дисковой подсистемой я осознал. Каковы мои шаги дальше ? Бежать тратить средства на другую дисковую, или пытаться заняться каким то "тюнигом" запросов ? Как мне понять, что в моей ситуации делать ?


Это симптом, а проблемы могут быть совсем в другом месте. Почему при старте работает быстро? У вас же та же самая дисковая подсистема.

Надо анализировать wait statistics и memory statistics, смотреть запросы, а вот когда оптимизировать уже некуда, то докупать диски.
7 июл 14, 15:01    [16269942]     Ответить | Цитировать Сообщить модератору
 Re: Рестарт служб sql влияет на производительность бизнес приложения.  [new]
rahzer
Member

Откуда:
Сообщений: 2317
 		Аккумулятор для кэша стоит тысяч 6 рублей, не думаю, что это сильно подорвет бюджет компании, по крайней мере, немного выправит производительность, пока Вы не найдете причину затыков.
7 июл 14, 17:01    [16270832]     Ответить | Цитировать Сообщить модератору
 Re: Рестарт служб sql влияет на производительность бизнес приложения.  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4974
Ondayl
Траса же нагрузит сервер, не ?


Лично я никогда не боялся пуска профайлер на боевых серверах. Естественно надо включить какой-то фильтр, чтобы ловить не все запросы и естественно не надо сохранять трассу в БД напрямую из профайлера. Простой запуск трассы тормозит сервер не более чем на 5 %.
7 июл 14, 17:57    [16271177]     Ответить | Цитировать Сообщить модератору
 Re: Рестарт служб sql влияет на производительность бизнес приложения.  [new]
Ondayl
Member

Откуда:
Сообщений: 231
 		gandjustas,

автор
Почему при старте работает быстро?

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

автор
смотреть запросы

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

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

a_voronin, хорошо, понял. Спасибо.
7 июл 14, 18:52    [16271516]     Ответить | Цитировать Сообщить модератору
 Re: Рестарт служб sql влияет на производительность бизнес приложения.  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
Ondayl
Мне счетчики пустить одновременно с трасой ? Траса же нагрузит сервер, не ?
Если и делать трейсинг на рабочей высоконагруженной базе, то конечно нужно очень хорошо выбрать фильтры и обязательно использовать Server-Side Tracing and Collection вместо тормозного SQL Profiler'а.

А еще учитывайте то, что SQL trace это по сути уже устаревшая технология, от которой майкрософт решил отказаться и в один прекрасный день ее может не быть в новой версии сервера.
7 июл 14, 21:31    [16272011]     Ответить | Цитировать Сообщить модератору
 Re: Рестарт служб sql влияет на производительность бизнес приложения.  [new]
Ondayl
Member

Откуда:
Сообщений: 231
Mind
А еще учитывайте то, что SQL trace это по сути уже устаревшая технология, от которой майкрософт решил отказаться и в один прекрасный день ее может не быть в новой версии сервера.

А что ;е нынче в тренде ?
7 июл 14, 22:57    [16272276]     Ответить | Цитировать Сообщить модератору
 Re: Рестарт служб sql влияет на производительность бизнес приложения.  [new]
gandjustas
Member

Откуда:
Сообщений: 857
Блог
 		Ondayl,

Extended events
7 июл 14, 23:01    [16272296]     Ответить | Цитировать Сообщить модератору
 Re: Рестарт служб sql влияет на производительность бизнес приложения.  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
gandjustas
Ondayl,

Extended events
Но к сожалению в 2008 они даже UI не удосужились сделать, да и вообще много чего недоделано :(
8 июл 14, 02:04    [16272835]     Ответить | Цитировать Сообщить модератору
 Re: Рестарт служб sql влияет на производительность бизнес приложения.  [new]
Ondayl
Member

Откуда:
Сообщений: 231
 		Mind, а зачем мне вообще такие сложности ? Почему я не могу посмотреть "Последние ресурсоемкие запросы" а мониторе ресурсов ?
9 июл 14, 09:08    [16279033]     Ответить | Цитировать Сообщить модератору
 Re: Рестарт служб sql влияет на производительность бизнес приложения.  [new]
gandjustas
Member

Откуда:
Сообщений: 857
Блог
Ondayl
Mind, а зачем мне вообще такие сложности ? Почему я не могу посмотреть "Последние ресурсоемкие запросы" а мониторе ресурсов ?


Если проблема упирается в локи или в кеш планов, то покажет совершенно не то, что надо.
9 июл 14, 10:16    [16279358]     Ответить | Цитировать Сообщить модератору
 Re: Рестарт служб sql влияет на производительность бизнес приложения.  [new]
Ondayl
Member

Откуда:
Сообщений: 231
 		Понятно. Сейчас вот потыкался, заметил, если запустить клиент приложения на сервере, там все побыстрее бегает, нежели если у сетевых клиентов. Что это может означать ?

Профайлер сегодня вечером запущу. Не додумался сразу приложить статистику ожиданий, она во вложении. О чем такая статистика может говорить ?
9 июл 14, 16:07    [16282036]     Ответить | Цитировать Сообщить модератору
 Re: Рестарт служб sql влияет на производительность бизнес приложения.  [new]
Ondayl
Member

Откуда:
Сообщений: 231
 		Отклеилось.

К сообщению приложен файл. Размер - 19Kb
9 июл 14, 16:08    [16282046]     Ответить | Цитировать Сообщить модератору
 Re: Рестарт служб sql влияет на производительность бизнес приложения.  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
Ondayl
Mind, а зачем мне вообще такие сложности ? Почему я не могу посмотреть "Последние ресурсоемкие запросы" а мониторе ресурсов ?
Можете, но как вам это поможет найти причину почему до перезагрузки медленно, а после быстро?
9 июл 14, 20:53    [16283409]     Ответить | Цитировать Сообщить модератору
 Re: Рестарт служб sql влияет на производительность бизнес приложения.  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
Ondayl
О чем такая статистика может говорить ?

О том что у вас кривой запрос.

1. Почему wait_time_ms <> (signal_wait_time_ms + resource_wait_time_ms) ???
2. Не отфильтрован мусор. В Итоге у вас 90% это SQLTRACE_INCREMENTAL_FLUSH_SLEEP.

Возьмите запрос для статистики хотя бы с Glenn Berry's SQL Server Diagnostic Information Queries
9 июл 14, 21:11    [16283459]     Ответить | Цитировать Сообщить модератору
 Re: Рестарт служб sql влияет на производительность бизнес приложения.  [new]
gandjustas
Member

Откуда:
Сообщений: 857
Блог
Ondayl
Отклеилось.


Трассировка статистику испоганила...
9 июл 14, 21:14    [16283464]     Ответить | Цитировать Сообщить модератору
 Re: Рестарт служб sql влияет на производительность бизнес приложения.  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
gandjustas
Ondayl
Отклеилось.


Трассировка статистику испоганила...
Пальцем в небо, и мимо. К вашему сведению трассировка на сервере по-умолчанию всегда запущена. Эти ожидания нужно просто отфильтровывать, как и многие другие впрочем.
9 июл 14, 21:43    [16283531]     Ответить | Цитировать Сообщить модератору
 Re: Рестарт служб sql влияет на производительность бизнес приложения.  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
 		Заранее прошу прощения, за темой следил "абы-как". Но может быть мой ответ из этой темы проблемы производительности, с чего начать поможет ТС (извиняюсь за само цитирование, перепечатывать лень):
Вопрос бы о том, как подходить к проблеме производительности на практике, когда вводные неизвестны.
SomewhereSomehow
Вы задаете нетривиальный вопрос, который не имеет однозначного ответа. На эту тему написаны статьи, и даже целые книги (поищите всякие Performance Guide). Теорию тоже желательно знать, чтобы понимать и интерпретировать какие-то практические результаты. Новичку будет трудно.

Так что простые решения, может просто апегрейдить железо? =)

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

Прежде всего, необходимо четко определить проблему.

1. Простой случай
Есть конкретный запрос/модуль, который работает медленно.

Попробуйте воспроизвести ситуацию, когда будете пытаться воспроизводить - помните об эффекте прослушивания параметров и то, что локальная переменная оценивается сервером иначе, чем параметр модуля. Т.е. если вы просто достанете запрос из модуля, и попробуете его выполнить, то можете получить другой план, не такой как у пользователя, это ничего не даст. Даже простой вызов модуля (например, процедуры) из SSMS может отличаться по времени от того что делает пользователь из-за разных планов, которые возникают из-за разных настроек соединения. Читать про это можно тут Медленно в приложении, быстро в SSMS

Самый простой способ отловить план, это использовать профайлер и события:
Performance: Showplan XML Statistics profile, Stored Procedures: SP: Starting, SP: Completed, SP: StmtCompleted. Обязательно поставьте фильтр на ObjectID по ID процедуры, иначе, в случае высокой нагрузки, вы еще больше затормозите сервер. Главное помнить, если вы что-то меряете вы влияете на то, что меряете. Кроме того, с последним SP: StmtCompleted нужно быть очень аккуратным! Это событие может сильно нагрузить сервер, т.к. если у вас в процедуре есть не in-line функции, то это событие будет вызываться каждый раз когда вызывается функция. Есть 1 000 000 строк для которых вызывается функция – получите 1 000 000 событий в Profiler, что абсолютно бесполезно и сильно нагружает сервер (признак – возрастают ожидания TRACEWRITE), по этому, возможно придется в фильтр добавить исключающее условие по ID функций.

Как только вы поймали долгую операцию (поле Duration отражает длительность), то смотрите план. Далее все зависит от вашего умения тюнинговать запросы. Но в целом проблема будет понятна. Если сами не справитесь – публикуйте здесь.

2. Сложный случай
Проблема неизвестна, нет конкретного запроса или модуля, который нужно мониторить. Более того, сама система для вас черный ящик, делалась не вами и вам не знакома.

Далее, ситуацию можно разделить на два сценария.

2.1 Проблема есть постоянно, т.е. какая-то операция всегда работает медленно

В таком случае, самый быстрый способ – запустить на короткое время профайлер и попросить пользователя выполнить действие, в зависимости от того, как у вас организована работа клиента с БД, можно мониторить события RPC:Completeed, Batch:Completed. Вы увидите все вызовы процедур или запросов которые инициировал клиент. Находите тот, что долго выполняется, и далее пытаетесь воспроизвести. Действия из п.1.

2.2 Проблема появляется периодически, в разных местах и операциях

В таком случае, необходим комплекс мер.

2.2.1 Собрать общую информацию о системе

Соберите общую информацию о системе:
  • - сервер физический/виртуальный
  • - число ядер, памяти, дисковая подсистема
  • - есть ли на сервере софт помимо сиквела, возможно сиквел испытывает внешнее давление
  • - сколько БД на сервере, и как они расположены, как расположены файлы данных БД, файлы журнала транзакций, tempdb
  • - соберите более конкретную статистическую информацию из административных представлений, лучший набор запросов для этого, который я знаю это SQL Server Diagnostic Information Queries for March 2014 и sp_Blitz™ – Free SQL Server Health Check Scrip.

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

    2.2.2 Контакт с пользователями

    Попросите их записывать в течение дня действие, которое «подвисло», хотя обычно выполняется быстро, и время окончания этого действия, и собственно рабочую станцию или логин, под которым пользователь ходит в БД. Точность времени зависит от нагрузки, но в целом, чем точнее будет время, тем вам будет потом легче. До минуты пользователь точно может записывать, просто по экранным часам.

    2.2.3 Сбор счетчиков Perfmon

    Поищите поисковиком следующий плакат по счетчикам, называется «SQL Server Perfmon Counters Of Interest» . Почитайте, выберете несколько, наиболее интересных. Можете начать, хотя бы с общих:
  • Processor: % Processor Time (если сервер не виртуальный)
  • Memory: Available Mbytes
  • SQL Server:Buffer Manager Page life expectancy
  • SQLServer: SQL Statistics : Batch Requests/sec
  • SQLServer: Locks: Lock Waits / Sec: _Total
  • Physical Disk: Avg. Disk sec/Read
  • Physical Disk: Avg. Disk sec/Write
  • System : Processor Queue Length
  • etc.
    Вообще там много разного есть, у каждого свой набор, вот например что советует собирать Brent Ozar: SQL Server Perfmon (Performance Monitor) Best Practices

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

    2.2.4 Наладьте долгосрочную трассировку запросов и вызовов

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

    В идеале, если у вас сервер 2012, то используйте xEvents, они меньше нагружают мониторингом систему и имеют более тонкие настройки.

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

    Собираете те же события, что и профайлером в п.2.1, но не забудьте:
  • поставить фильтр на Reads > 0 (отсечете всякие set запросы и много другого шума), Duration > 10 000 (отсчете запросы длительностью менее 10 мс, можете еще увеличить это значение, но помните, что может быть очень много мелких запросов, которые сильно нагружают сервер, и выставляя слишком большое время в фильтре, вы просто пропустите проблему). Кстати, насчет Duration – нюанс, в профайлере он отображается в миллисекундах, в трассе и фильтре в микросекундах – нужно учитывать.
  • выбрать только необходимые колонки, чтобы не писать лишнего (я выбирал: EndTime, EventClass, ApplicationName, HostName, SessionLoginName, SPID, DatabaseName, ObjectName, CPU, Duration, Reads, RowCounts, Writes, TextData)
    Я когда-то немного писал про sp_trace, но вам, в отличие от статьи, не нужно собирать никакой агрегирующей информации, можно просто взять за отправную точку, ну и в BOL много примеров.

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

    Для примера скажу, мониторинг системы с Batch Requests/sec от 1500 до 15000, т.е. в среднем около 5000-7000 батчей в секунду, с подобными фильтрами за сутки занимает места примерно 200 МБ, так что я положил это туда же где собирается дефолтный трейс – никаких проблем не было. Вы сами смотрите (экспериментальным путем можно), все зависит от вашей нагрузки. Полезная опция указывать в трассировке время отключения, если вдруг вы сами забудете ее остановить, я обычно ставил +сутки от начала трассировки.

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

    2.2.5 Проведите анализ

    Собираете данные пунктов 2.2.1 – Общая информация, 2.2.2 – Жалобы пользователей, 2.2.3 – Счетчики, 2.2.4 – Трасса. Теперь, у вас есть все, что нужно для анализа. Его сложность зависит от нагрузки и вашего умения. Очевидно, попытаться наложить по времени жалобы, счетчики и трассу, чтобы определить конкретный запрос, для конкретного пользователя, и конкретное состояние системы в данный момент.

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

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

    Если планы одинаковые, по счетчикам не видно, то более тонкий поиск проблемы, можно выполнить настроив сессию xEvents для события wait_info, wait_info_external (доступно с 2008), теперь зная имя процедуры, примерное время и поставив фильтр на длительность ожидания. Запускаете профайлер, запускаете сессию xEvents, ловите события вызова этой процедуры профайлером, ожидания xEvents-ами. Увидели в профайлере тот самый «подвисший» вызов, останавливаете обе сессии (профайлер и xEvents) и коррелируете ожидания и проблемный вызов процедуры, например, по SPID. Обычно сразу все становится ясно.

    Из недавних примеров, собственного опыта, это было ожидание PAGEIOLATCH_SH, которое говорит о давлении на buffer pool, что собственно было видно и из счетчика PLE, который сильно падал в определенные моменты. Далее, чтобы определить, кто так забивает кэш, я сделал Job, который раз в 30 секунд собирал статистику из DMV по принадлежности страниц буферного пула объектам (таблицам, индексам) в БД. После этого, отобрал из статистики объекты, которые занимали очень много страниц и удерживали их долгое время. Оказалось что 80% всего рабочего времени, 40% всего буферного пула, занимают всего три широких индекса, все индексы по одной таблице.

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

    Есть еще много подходов и способов, поиском все это легко ищется. И если вы всерьез решили этим заняться, то приготовьтесь много читать.
    		•
    9 июл 14, 22:03    [16283579]     Ответить | Цитировать Сообщить модератору
     Re: Рестарт служб sql влияет на производительность бизнес приложения.  [new]
    Ondayl
    Member

    Откуда:
    Сообщений: 231
         		Mind, нда, простите. Выбрал первый попавшийся.
    gandjustas, да нет, я это перед трасой еще запускал.
    9 июл 14, 22:20    [16283623]     Ответить | Цитировать Сообщить модератору
     Re: Рестарт служб sql влияет на производительность бизнес приложения.  [new]
    gandjustas
    Member

    Откуда:
    Сообщений: 857
    Блог
    Ondayl
    Отклеилось.


    Возьми по ссылке запрос - http://blog.sqlauthority.com/2011/02/01/sql-server-introduction-to-wait-stats-and-wait-types-wait-type-day-1-of-28/
    Выполни его сразу после перезагрузки и когда начнет тормозить.

    Потом возьми другой запрос по ссылке http://blog.sqlauthority.com/2011/02/04/sql-server-dmv-sys-dm_os_waiting_tasks-and-sys-dm_exec_requests-wait-type-day-4-of-28/
    Отфильтруй по wait type, который оказался в топе предыдущего запроса. Посмотри какие запросы реально тормозят.
    9 июл 14, 22:26    [16283635]     Ответить | Цитировать Сообщить модератору
     Re: Рестарт служб sql влияет на производительность бизнес приложения.  [new]
    SomewhereSomehow
    Member

    Откуда: Moscow
    Сообщений: 2480
    Блог
    gandjustas
    Ondayl
    Отклеилось.


    Возьми по ссылке запрос - http://blog.sqlauthority.com/2011/02/01/sql-server-introduction-to-wait-stats-and-wait-types-wait-type-day-1-of-28/
    Выполни его сразу после перезагрузки и когда начнет тормозить.

    Потом возьми другой запрос по ссылке http://blog.sqlauthority.com/2011/02/04/sql-server-dmv-sys-dm_os_waiting_tasks-and-sys-dm_exec_requests-wait-type-day-4-of-28/
    Отфильтруй по wait type, который оказался в топе предыдущего запроса. Посмотри какие запросы реально тормозят.


    Любопытно, а в какой момент запускать второй запрос, тот который показывает текущие ожидания? И как это коррелировать с накопленной статистикой?

    Вы сами пробовали такую диагностику на реальной системе (не домашней станции)?

    К sys.dm_os_waiting_tasks - отношусь очень положительно, сам использую, это классное средство понять почему долго "сейчас". Эту же вьюху использует "хит" sp_WhoIsActive. Говорят, что если изучить все параметры этой процедуры, то можно овладеть дзеном сиквела =)

    Но как это поможет в анализе, если тормоза появляются непонятно когда и почему, т.е. время неизвестно.
    9 июл 14, 23:09    [16283763]     Ответить | Цитировать Сообщить модератору
     Re: Рестарт служб sql влияет на производительность бизнес приложения.  [new]
    gandjustas
    Member

    Откуда:
    Сообщений: 857
    Блог
         		SomewhereSomehow,

    Второй запрос запускать когда тормозит. Примерно тоже самое показывает activity monitor.

    Я запускал на реальной системе. Но там была проблема с локами, синить пришлось совсем в другом месте.
    10 июл 14, 00:45    [16284096]     Ответить | Цитировать Сообщить модератору
     Re: Рестарт служб sql влияет на производительность бизнес приложения.  [new]
    SomewhereSomehow
    Member

    Откуда: Moscow
    Сообщений: 2480
    Блог
         		gandjustas,

    Когда тормозит - согласен, хорошее средство, ожидания помогают многое понять. Упомянутая процедура от Адама Маканика дает еще больший результат. Там и планы можно посмотреть. Оценочные правда. И стейтмент выполняющийся и т.д.

    Непонятно как коррелировать с общей нагрузкой, как искать тормоза.

    Короче, как вычленять виновника по вашей методе я не понял.
    10 июл 14, 01:05    [16284160]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: ←Ctrl  назад   1 2 [3] 4 5 6   вперед  Ctrl→      все
    Все форумы / Microsoft SQL Server Ответить