Мое приложение получает ошибки тайм-аута SQL, но какой запрос вызывает проблему?
Пересказ статьи David Fowler. My Application is Getting SQL Timeout Errors, But What Query is the Problem?
Такое периодически возникает. Разработчик или сотрудник службы поддержки приходит ко мне и спрашивает: "Тайм-аут SQL, посмотрите, какой запрос его вызывает?"
Ну, я скажу вам теперь, что не SQL вызывает тайм-аут вашего запроса. SQL благополучно выполнит запрос за год или за день, если это необходимо (да, это может не понравиться, но такое бывает). Тайм-аут будет исходить из слоя вашего приложения, возможно в .NET или IIS.
Возникающая ошибка будет чем-то вроде..
Не очень полезно, правда? И если у вас нет какого-либо мониторинга, например, вы можете найти в SQL Sentry прерванные запросы, или возможности выбора их в журнале своего приложения, вам будет сложно отследить, какой запрос действительно вызвал тайм-аут. Поскольку вы читаете эту статью, я могу предположить, что у вас нет мониторинга.
Так как же нам это выяснить?
То, что мне нравится, это установить расширенные события для захвата прерванных запросов. Я ищу прерванные запросы, поскольку у SQL нет способа сообщить, был ли запрос прерван пользователем или сработал тайм-аут в приложении - для SQL Server это одно и то же.
Давайте приступим к настройке этого сеанса расширенных событий. В SSMS раскроем Management>Extended Events.
Выполним щелчок правой кнопкой на Sessions и выберем ‘New Session…’
Вы захотите дать сессии имя, и я обычно устанавливаю флажки ‘Start the event sessions at server startup’ (запускать сессии событий при запуске сервера) и ‘Start the event session immediately after session creation’ (запускать сессию события сразу после создания сессии).
Переходим на экран ‘Events’ (события). Мы ищем класс событий ‘attention’ (внимание), поэтому выделите «attention» в поле Event Library (Библиотека событий), теперь оно должно появиться в поле ниже. Выберите класс события "внимание" и щелкните кнопку >, чтобы переместить его в выбранные события.
Нажмите кнопку ‘Configure’ (конфигурировать). Теперь нам нужно выбрать другие поля, которые мы хотим собрать. Просмотрите и выберите все те, которые вам интересны. Я обычно выбираю...
Затем нам нужно сконфигурировать, куда мы будем собирать эту информацию. Перейдите на экран ‘Data Storage’ (хранилище данных), где вы можете выбрать, как сохранять данные. Я обычно выбирал I ‘event_file’ (файл событий). Как только вы выбрали файл событий, то можете дать имя своему файлу, задать максимальный размер, включить перекидывание, если вы этого хотите, и сконфигурировать количество поддерживаемых файлов.
Это почти все, что требуется сделать. Щелкните ok и ваша сессия XEvent будет создана, и начнется запись.
Теперь в SSMS в ветке Extended Events мы можем увидеть новую сессию, которую только что создали. Раскройте её, и выполните щелчок правой кнопкой на ‘View Target Data…’ (просмотреть целевые данные). Это позволит нам увидеть любые прерванные запросы, которые мы смогли захватить.
С помощью этих данных вы сможете точно отследить, какие запросы вызывают тайм-аут, который вас беспокоит.
System.Exception: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
(Системное исключение: истекло время ожидания. Период тайм-аута закончился до завершения операции или сервер не отвечает.)
Не очень полезно, правда? И если у вас нет какого-либо мониторинга, например, вы можете найти в SQL Sentry прерванные запросы, или возможности выбора их в журнале своего приложения, вам будет сложно отследить, какой запрос действительно вызвал тайм-аут. Поскольку вы читаете эту статью, я могу предположить, что у вас нет мониторинга.
Так как же нам это выяснить?
То, что мне нравится, это установить расширенные события для захвата прерванных запросов. Я ищу прерванные запросы, поскольку у SQL нет способа сообщить, был ли запрос прерван пользователем или сработал тайм-аут в приложении - для SQL Server это одно и то же.
Давайте приступим к настройке этого сеанса расширенных событий. В SSMS раскроем Management>Extended Events.
Выполним щелчок правой кнопкой на Sessions и выберем ‘New Session…’
Вы захотите дать сессии имя, и я обычно устанавливаю флажки ‘Start the event sessions at server startup’ (запускать сессии событий при запуске сервера) и ‘Start the event session immediately after session creation’ (запускать сессию события сразу после создания сессии).
Переходим на экран ‘Events’ (события). Мы ищем класс событий ‘attention’ (внимание), поэтому выделите «attention» в поле Event Library (Библиотека событий), теперь оно должно появиться в поле ниже. Выберите класс события "внимание" и щелкните кнопку >, чтобы переместить его в выбранные события.
Нажмите кнопку ‘Configure’ (конфигурировать). Теперь нам нужно выбрать другие поля, которые мы хотим собрать. Просмотрите и выберите все те, которые вам интересны. Я обычно выбираю...
- имя базы данных
- имя пользователя nt
- хэш запроса
- текст sql
- имя пользователя
Затем нам нужно сконфигурировать, куда мы будем собирать эту информацию. Перейдите на экран ‘Data Storage’ (хранилище данных), где вы можете выбрать, как сохранять данные. Я обычно выбирал I ‘event_file’ (файл событий). Как только вы выбрали файл событий, то можете дать имя своему файлу, задать максимальный размер, включить перекидывание, если вы этого хотите, и сконфигурировать количество поддерживаемых файлов.
Это почти все, что требуется сделать. Щелкните ok и ваша сессия XEvent будет создана, и начнется запись.
Теперь в SSMS в ветке Extended Events мы можем увидеть новую сессию, которую только что создали. Раскройте её, и выполните щелчок правой кнопкой на ‘View Target Data…’ (просмотреть целевые данные). Это позволит нам увидеть любые прерванные запросы, которые мы смогли захватить.
С помощью этих данных вы сможете точно отследить, какие запросы вызывают тайм-аут, который вас беспокоит.
Обратные ссылки
Нет обратных ссылок
Автор не разрешил комментировать эту запись
Комментарии
Показывать комментарии Как список | Древовидной структурой