Как отследить SQL-запросы, вызывающие сбой SQL Server

У нас есть сервер базы данных SQL Server 2008 (он работает под управлением MS Failover Clustering, но я не думаю, что это уместно здесь).

Наше приложение запускает Hibernate для доступа к БД, и с тех пор, как мы недавно обновили версию v3.1 до 3.6, у нас регулярно происходили сбои SQL Server (каждые 24-48 часов, но иногда чаще).

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

Error: 701, Severity: 17, State: 130.
There is insufficient system memory in resource pool 'internal' to run this query.

также случайные (но регулярные) сообщения

Error: 17300, Severity: 16, State: 1. (Params:). The error is printed in terse mode because there was error during formatting. Tracing, ETW, notifications etc are skipped.

Ошибка: 17312, серьезность: 16, состояние: 1. (параметры :). Ошибка печатается в кратком режиме, потому что во время форматирования произошла ошибка. Трассировка, ETW, уведомления и т. Д. Пропускаются.

Я также получаю некоторые ошибки на уровне приложения, такие как

java.sql.SQLException: A time out occurred while waiting to optimize the query. Rerun the query.

а потом захватывающая и, возможно, поучительная ошибка:

The query processor ran out of internal resources and could not produce a query plan. 
This is a rare event and only expected for extremely complex queries or queries that reference a very large number of tables or partitions. 
Please simplify the query. If you believe you have received this message in error, contact Customer Support Services for more information.

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

Теперь вопрос - как мне отследить запросы, которые вызывают эту ошибку (и, следовательно, предположительно, все проблемы)? Похоже, что после нашего обновления Hibernate он запускает несколько больших запросов на SQL Server, и это не работает. Как это происходит, у меня есть некоторые идеи относительно того, что они могут быть, но было бы хорошо, чтобы иметь возможность отследить их.

Конечно, я могу запустить профилировщик SQL Server, но как только это будет сделано (и произведено огромное количество данных - это занятая база данных OLTP), как мне отфильтровать, чтобы найти проблемные запросы?

Спасибо!

Выполните действия, описанные в разделе Как использовать DBCC MEMORYSTATUSкоманду для мониторинга использования памяти на SQL Server . Действие лекарства будет зависеть от ваших выводов. Вы также можете прочитать Как определить узкие места в памяти Microsoft SQL Server, которые более доступны.

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

Кажется, вы хотите перейти к Extended Eventsнастройке, используя события query_memory_grant_xxxxx.

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

Быстрая настройка шагов ..