Всем дорого времени суток!

Сабж - запуск трассировщика в базе данных с фильтром по ObjectName - "нужная мне таблица" убивает подключения приложения к базе.

Select @@Version: Microsoft SQL Server 2014 (SP2-CU7) (KB4032541) - 12.0.5556.0 (X64) Enterprise Edition (Build 9600: )
База в Always On кластере, jбъем данных порядка 3TB, одновременно в базу подключается до 400 клиентов.

Коллеги, в чем может быть причина?

Ошибка, которую генерит внешнее приложение:

2018-02-02 10:45:11,879 [Pay_8c185f46-90ff-4b7b-87f1-e04ef43f4d24][982037][35] ERROR NHibernate.AdoNet.AbstractBatcher.Error (0) - Could not execute query: exec sp_Payments_GetPaymentHistory @locale=@p0, @userId=@p1,@dtBegin=@p2 , @dtEnd=@p3, @Page =@p4, @Count=@p5, @paymentinfoId=@p6, @subscriptionId=@p7
System.Data.SqlClient.SqlException (0x80131904): Execution Timeout Expired. The timeout period elapsed prior to completion of the operation or the server is not responding.

Кусочек,

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

Yasha123,

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

Попробуем проверить подобное поведение на тестовой платформе, но не понятно почему трассировка так кардинально меняет ситуацию на боевой базе, причем это сразу видно по загрузке сети и ЦПУ - и то и другое резко снижаются.

Владислав КолосовавторКоллеги, в чем может быть причина?


Профайлер съел ресурсы сервера. Умерьте его аппетиты, пишите лог в файл на другой компьютер.

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

гоголKopilogusпропущено...


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


а блокировки?

блокировок не наблюдали, просто очередь обращений встала, как будто сервер стал недоступным ...

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

Yasha123KopilogusYasha123,

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

Попробуем проверить подобное поведение на тестовой платформе, но не понятно почему трассировка так кардинально меняет ситуацию на боевой базе, причем это сразу видно по загрузке сети и ЦПУ - и то и другое резко снижаются.
смотрите ожидания.
ведь перед тем, как упасть, запрос как минимум 30 секунд что-то ждет.
sys.dm_os_waiting_tasks

Будем проверять на тестовой платформе в понедельник..
Спасибо всем за советы!