Возникла такая проблемка – есть 2 хранимые процедуры, время исполнения которых – 0.01 сек в среднем.
В определенное время – с 14 до 15 часов время выполнения может резко прыгнусть до 45-60 секунд.
При этом не для всех вызовов, а скажем для каждого 10-го – 20го.
Все мои попытки определить что происходит и где собака порылась не привели ни к каким результам.
Как можно определить что именно происходит и как с такими явлениями бороться?

Нагрука на сервер в это время вполне обычная, может на проентов 10 выше чем обычно.

Здравствуйте, SergeiSF, Вы писали:

SSF>Возникла такая проблемка – есть 2 хранимые процедуры, время исполнения которых – 0.01 сек в среднем.
SSF>В определенное время – с 14 до 15 часов время выполнения может резко прыгнусть до 45-60 секунд.
SSF>При этом не для всех вызовов, а скажем для каждого 10-го – 20го.
SSF>Все мои попытки определить что происходит и где собака порылась не привели ни к каким результам.
Что именно пробовали? Чтобы не повторяться.

SSF>Как можно определить что именно происходит и как с такими явлениями бороться?

Проверьте для начала SQL Server Agent и Windows task scheduler на сервере, может там база бэкапится или что-нибудь такое.
Если не найдёте — ставьте Profiler, performance monitor на количество соединений/память/диск для процесса сервера и ждите часа Ч.

Здравствуйте, SergeiSF, Вы писали:

SSF>Возникла такая проблемка – есть 2 хранимые процедуры, время исполнения которых – 0.01 сек в среднем.
SSF>В определенное время – с 14 до 15 часов время выполнения может резко прыгнусть до 45-60 секунд.
SSF>При этом не для всех вызовов, а скажем для каждого 10-го – 20го.
SSF>Все мои попытки определить что происходит и где собака порылась не привели ни к каким результам.
SSF>Как можно определить что именно происходит и как с такими явлениями бороться?

SSF>Нагрука на сервер в это время вполне обычная, может на проентов 10 выше чем обычно.

Мож на блокировке висит?

Здравствуйте, SergeiSF, Вы писали:

SSF>Возникла такая проблемка – есть 2 хранимые процедуры, время исполнения которых – 0.01 сек в среднем.
SSF>В определенное время – с 14 до 15 часов время выполнения может резко прыгнусть до 45-60 секунд.
SSF>При этом не для всех вызовов, а скажем для каждого 10-го – 20го.
SSF>Все мои попытки определить что происходит и где собака порылась не привели ни к каким результам.
SSF>Как можно определить что именно происходит и как с такими явлениями бороться?

SSF>Нагрука на сервер в это время вполне обычная, может на проентов 10 выше чем обычно.


О какой СУБД идёт речь?
В ORACLE данная проблема локализуется просто: снимается трассировка с сессии в которой выполняется процедура.
По трассировке видно на какие wait'ы для каких DML выражений уходит время.
Скорее всего конкуренция за какой-то ресурс.

SergeiSF пишет:

> Как можно определить что именно происходит и как с такими явлениями
> бороться?

Планы скорее всего "слетают", начинают другие генерироваться.
Смотрите выполняемые запросы и их планы. Если планы плохие,
исправляйте.

Возможно, конечно, что это связано с какими-то системными
проблемами сервера, но это менее вероятно.

Здравствуйте, vmpire, Вы писали:
SSF>>Возникла такая проблемка – есть 2 хранимые процедуры, время исполнения которых – 0.01 сек в среднем.
SSF>>В определенное время – с 14 до 15 часов время выполнения может резко прыгнусть до 45-60 секунд.
SSF>>При этом не для всех вызовов, а скажем для каждого 10-го – 20го.
SSF>>Все мои попытки определить что происходит и где собака порылась не привели ни к каким результам.
V>Что именно пробовали? Чтобы не повторяться.

Проверил планы, посмотрел на CPU/Network IO сервера(всё в норме, в это время никаких скачков)
Сервер на VMWare и никаких пиковых нагрузок не видно. Сегодня ещё и perf mon поставлю понаблюдаю
Кстати – база на MS SQL 2005

В процессе данные из одной таблицы(~1000-3000 записей ежедневно) постепенно копируются во вторую и запрос выдает данные из 1й таблицы которые еще не существуют во второй. Там где то 5-7 штук inner / left outer joins. Вроде ничего криминального.
Тормозить начиниает когда разница между 2мя таблицами становится оочень небольшой – скажем 100-50-10 строк. Это что нить объясняет?

Спасибо!
Сергей



SSF>>Как можно определить что именно происходит и как с такими явлениями бороться?

V>Проверьте для начала SQL Server Agent и Windows task scheduler на сервере, может там база бэкапится или что-нибудь такое.
V>Если не найдёте — ставьте Profiler, performance monitor на количество соединений/память/диск для процесса сервера и ждите часа Ч.

Здравствуйте, MasterZiv, Вы писали:

Вполне возможно что слетают – сам подозреваю что оно и происходит.
Как это проверить/вылечить? В live базе данных?

Вот кое какие подробности запроса:
В процессе данные из одной таблицы(~1000-3000 ежедневно) постепенно копируются во вторую и запрос выдает данные из 1й таблицы которые еще не существуют во второй. Там где то 5-7 штук inner / left outer joins. Вроде ничего криминального.
Тормозить начиниает когда разница между 2мя таблицами становится оочень небольшой – скажем 100-50-10 строк. Это что нить объясняет?

Спасибо!
Сергей


MZ>SergeiSF пишет:

>> Как можно определить что именно происходит и как с такими явлениями
>> бороться?

MZ>Планы скорее всего "слетают", начинают другие генерироваться.
MZ>Смотрите выполняемые запросы и их планы. Если планы плохие,
MZ>исправляйте.

MZ>Возможно, конечно, что это связано с какими-то системными
MZ>проблемами сервера, но это менее вероятно.

Здравствуйте, WaR_RioR, Вы писали:

It's MS SQL 2005. Is there a way to enable some sort of tracing fro sprocs in it?

WR_>Здравствуйте, SergeiSF, Вы писали:

SSF>>Возникла такая проблемка – есть 2 хранимые процедуры, время исполнения которых – 0.01 сек в среднем.
SSF>>В определенное время – с 14 до 15 часов время выполнения может резко прыгнусть до 45-60 секунд.
SSF>>При этом не для всех вызовов, а скажем для каждого 10-го – 20го.
SSF>>Все мои попытки определить что происходит и где собака порылась не привели ни к каким результам.
SSF>>Как можно определить что именно происходит и как с такими явлениями бороться?

SSF>>Нагрука на сервер в это время вполне обычная, может на проентов 10 выше чем обычно.


WR_>О какой СУБД идёт речь?
WR_>В ORACLE данная проблема локализуется просто: снимается трассировка с сессии в которой выполняется процедура.
WR_>По трассировке видно на какие wait'ы для каких DML выражений уходит время.
WR_>Скорее всего конкуренция за какой-то ресурс.

Здравствуйте, GarryIV, Вы писали:
Может и висит, хотя вряд ли.. MS SQL при insert в table по идее не блокирует же ёё всю таблицу, так?
При том вроде на все selects висит nolock – для dirty reads в данном случае устраивают на 100%

GIV>Здравствуйте, SergeiSF, Вы писали:

SSF>>Возникла такая проблемка – есть 2 хранимые процедуры, время исполнения которых – 0.01 сек в среднем.
SSF>>В определенное время – с 14 до 15 часов время выполнения может резко прыгнусть до 45-60 секунд.
SSF>>При этом не для всех вызовов, а скажем для каждого 10-го – 20го.
SSF>>Все мои попытки определить что происходит и где собака порылась не привели ни к каким результам.
SSF>>Как можно определить что именно происходит и как с такими явлениями бороться?

SSF>>Нагрука на сервер в это время вполне обычная, может на проентов 10 выше чем обычно.

GIV>Мож на блокировке висит?

Здравствуйте, SergeiSF, Вы писали:

SSF>В процессе данные из одной таблицы(~1000-3000 записей ежедневно) постепенно копируются во вторую и запрос выдает данные из 1й таблицы которые еще не существуют во второй. Там где то 5-7 штук inner / left outer joins. Вроде ничего криминального.
SSF>Тормозить начиниает когда разница между 2мя таблицами становится оочень небольшой – скажем 100-50-10 строк. Это что нить объясняет?
Это, возможно, объясняет всё (а возможно и нет ).
Очень похоже, что при маленьком и большом количестве записей сервер использует разные планы выполнения, которые сильно отличаются по эффективности.
Если Вы можете воспроизвести текст запроса для большого и маленького количества записей, то можно это проверить, запустив их в SSMS с показом реального плана выполения. Если это, действительно, так — то дальше нужно смотреть причину неэффективного плана.
Или, можно вытащитьь план сразу после выполнения долгого и быстрого запросов из вьюшек sys.dm_exec_cached_plans и sys.dm_exec_query_plan.
А когда запустите perfmon добавьте счётчик перекомпиляций планов. Это же можно посмотреть в профайлере.

Здравствуйте, SergeiSF, Вы писали:

SSF>Вот кое какие подробности запроса:
SSF>В процессе данные из одной таблицы(~1000-3000 ежедневно) постепенно копируются во вторую и запрос выдает данные из 1й таблицы которые еще не существуют во второй. Там где то 5-7 штук inner / left outer joins. Вроде ничего криминального.
SSF>Тормозить начиниает когда разница между 2мя таблицами становится оочень небольшой – скажем 100-50-10 строк. Это что нить объясняет?

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

Я думаю одно дело проверить наличие в первой таблице записей, которые не являются членами множества {1, 2} и совсем другое {1, 2, 3, 4, 5, 6, 7, 8, 9}. Как-то так.

Здравствуйте, SergeiSF, Вы писали:
SSF>Нагрука на сервер в это время вполне обычная, может на проентов 10 выше чем обычно.

В своё время налетал на аналогичную проблему в MS 2000. Там запрос типа

select * from tableA where id not in (select id from tableB)

отламывал оптимизатору башню напрочь — когда в tableA был примерно миллион записей, а в tableB — почти все они же минус несколько штук.
Причём estimated plan показывался нормальный — такой же, как и для наоборот,

select * from tableB where id not in (select id from tableA)

, который отрабатывал за секунду. (естественно, индексы по id были в обеих таблицах).
Интуитивное представление о том, что он вместо index merge сваливался в nested loops, подтвердить не удалось — не хватало терпения дождаться выполнения запроса для показа actual plan.

Насколько я помню, забороли проблему переписыванием запроса в виде

select * from tableA left join tableB on tableA.id = tableB.id where tableB.id is null