8.1.7. Работа с предупреждениями

Предупреждения (alerts) SQL Server Agent, типы предупреждений SQL Server event alert, SQL Server performance condition alert, WMI event alert, sp_addmessage, RAISERROR

Предупреждения (alerts) — это еще одно важное средство автоматизации работы с SQL Server 2005. Предупреждения позволяют реагировать на события, которые происходят на SQL Server. К таким событиям относятся:

q      события самого SQL Server. Для удобства любые события SQL Server, которые можно зафиксировать (перехватить), называются ошибками. При этом совершенно не обязательно, чтобы данная ошибка действительно мешала работе сервера: множество ошибок (например, все ошибки с уровнем важности от 0 до 9) являются просто информационными сообщениями о том, что на сервере что-то произошло. Кроме того, пользователь (или разработчик) может сам сгенерировать ошибку с нужным кодом;

q      выход значения счетчика Системного монитора за указанные вами пределы. Подробно про счетчики Системного монитора и анализ получаемой с их помощью информации будет рассказываться в разд. 11.4;

q      возникновение события WMI. Про работу с объектной моделью WMI будет рассказываться в разд. 9.4.

Работа с предупреждениями производится из контейнера SQL Server Agent | Alerts. Чтобы создать новое предупреждение, нужно воспользоваться командой New Alert (Новое предупреждение) из контекстного меню этого контейнера. Далее на вкладке General свойств создаваемого предупреждения вы можете настроить:

q      Name — имя создаваемого предупреждения;

q      Enable — если этот флажок снят, то предупреждение работать не будет. Обычно это используется для того, чтобы на время отключить оповещение без его удаления;

q      Type — тип предупреждения. От него зависит, что именно будет отслеживать это предупреждение и какие параметры можно будет для него настроить. В вашем распоряжении три варианта:

·                SQL Server event alert — предупреждение будет реагировать на встроенные и пользовательские ошибки SQL Server;

·                SQL Server performance condition alert — будет отслеживаться выход значений выбранных вами счетчиков производительности в Системном мониторе за указанные вами границы;

·                WMI event alert — будут отслеживаться события объектов WMI.

Рассмотрим возможности каждого типа предупреждений.

Чаще всего используются предупреждения типа SQL Server event alert. Для них вы можете настроить следующие параметры:

q      Database name (Имя базы данных) — предупреждение будет срабатывать, только если возникла ошибка в определенной базе данных. В вашем распоряжении есть все базы данных на этом сервере и специальное значение <all databases> (Все базы данных);

q      Alert will be raised on: Error number/Severity (Предупреждение сработает: При ошибке номер/С важностью) — этот параметр определяет номер ошибки или уровень важности. При возникновении ошибки с этим номером или любой ошибки на указанном вами уровне важности произойдет срабатывание данного предупреждения. Подробнее про номера встроенных и пользовательских ошибок будет рассказано далее в этом разделе;

q      Raise alert when message contains (Срабатывать, если текст ошибки содержит) — проверяет не номер и уровень важности ошибки, а текст сообщения для этой ошибки. Такой вариант рекомендуется выбирать только в том случае, если вы не можете использовать номер ошибки. С точки зрения производительности, использование таких предупреждений — не самый лучший вариант.

Какие именно ошибки чаще всего перехватываются? К сожалению, в справке к SQL Server 2005, в отличие от справки к SQL Server 2000, нет таблиц с номерами ошибок. Вместо этого нам предлагается воспользоваться разделом "Events and Errors Message Center" (Центр сообщений о событиях и ошибках), расположенном на сайте Microsoft (по адресу http://go.microsoft.com/fwlink/?LinkId=47660). Однако сводного списка ошибок SQL Server 2005 там тоже нет: по указанному адресу открывается интерфейс для поиска информации по конкретной ошибке. Поэтому приведем здесь краткую информацию по некоторым наиболее часто перехватываемым ошибкам SQL Server 2005:

q      1204 — появление этой ошибки говорит о том, что SQL Server не хватает специальной области оперативной памяти для того, чтобы наложить новые блокировки в оперативной памяти. Для решения этой проблемы можно увеличить объем оперативной памяти на сервере или в некоторых ситуациях можно выполнить хранимую процедуру sp_configure с параметром locks;

q      1205 — ошибка, свидетельствующая о взаимоблокировке (deadlock) на сервере. Взаимоблокировки обычно являются следствием плохо продуманных транзакций. В случае появления таких ошибок администратору рекомендуется предъявлять претензии разработчикам, а разработчикам рекомендуется планировать транзакции так, чтобы взаимоблокировок не происходило, или, по крайней мере, перехватывать эту ошибку на уровне приложения;

q      3041 — сбой резервного копирования (по самым разным причинам);

q      3267 — для начала резервного копирования недостаточно системных ресурсов сервера;

q      6103 — произошло аварийное закрытие пользовательского соединения;

q      9002 — это, наверное, наиболее часто перехватываемая ошибка. Она сообщает о том, что закончилось место в журнале транзакций.

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

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

q      определить пользовательскую ошибку;

q      создать для этой таблицы триггеры для операций изменения данных;

q      поместить в этот триггер оператор RAISERROR, который генерирует данную ошибку;

q      настроить предупреждение SQL Server Agent, которое перехватывает ошибку и реагирует на нее (например, извещает администратора по электронной почте).

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

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

Работа с пользовательскими ошибками может оказаться удобной также при отладке скриптов Transact-SQL.

Отметим также, что в SQL Server 2005 появилась возможность перехвата ошибок из кода Transact-SQL при помощи синтаксической конструкции TRY ... CATCH.

Теперь остановимся подробнее на том, как настроить перехват пользовательских ошибок на практике:

1.     Первое, что нужно сделать, — создать пользовательское сообщение. В SQL Server 2000 это можно было сделать и при помощи графического интерфейса, и из кода Transact-SQL, а в SQL Server 2005 — только средствами кода Transact-SQL при помощи хранимой процедуры sp_addmessage, например:

sp_addmessage 50001, 16, 'Пользовательская ошибка';

Здесь 50001 — это номер пользовательской ошибки (еще раз напомним, что он обязательно должен быть больше 50000, иначе пользовательская ошибка просто не будет работать), 16 — уровень важности (от 0 о 25), 'Пользовательская ошибка' — текст сообщения ошибки. В этом тексте можно использовать параметры, в которые при возникновении ошибки будут подставляться значения (например, имя базы данных, имя объекта в базе данных и т. п.).

2.     Далее нужно настроить триггеры с командой RAISEERROR. Соответствующая команда в теле триггера может выглядеть так:

RAISERROR (50001, 16, 1) WITH LOG;

Параметр WITH LOG нужно обязательно указывать, т. к. в противном случае предупреждение SQL Server 2005 не сможет "поймать" эту ошибку. Это связано с тем, что предупреждения SQL Server 2005 используют службу событий Windows, а параметр WITH LOG как раз и указывает на то, что информация должна быть записана в журнал событий Windows (ошибка попадет в журнал событий приложений с номером 17063, а ваш номер 50001 будет использован только в тексте сообщения). Параметр 16 — это уровень важности ошибки, а 1 — это код состояния ошибки. Практически во всех ситуациях для кода состояния ошибки нужно использовать значение 1. Исключением является ситуация, когда одна и та же ошибка может быть сгенерирована в разных частях кода. В этом случае выяснить, в каком именно участке кода она возникла, можно, использовав для этого параметра оператора RAISERROR значение, отличное от 1 (максимально допустимое значение — 127).

3.     Затем нужно настроить предупреждение, которое выполнит необходимые действия.

Можно также настроить перехват всех ошибок с определенным уровнем важности (severity). Обычно создают предупреждения для всех ошибок с уровнями важности от 19 до 25. Ошибки этих уровней — это так называемые критические (fatal) ошибки, которые сам SQL Server исправить не может. Смысл настройки предупреждений для ошибок определенного уровня важности — быстрое предупреждение администратора о проблемах на важной системе.

Предупреждения типа SQL Server performance condition alert настраиваются для того, чтобы отслеживать выход за предельные значения для счетчиков производительности Системного монитора. Для таких оповещений можно настроить:

q      Object (Объект) — имя объекта в Системном мониторе;

q      Counter (Счетчик) — счетчик для данного объекта, значение которого будет отслеживаться;

q      Instance (Экземпляр) — экземпляр объекта, для которого будет производиться мониторинг. Например, экземплярами объекта Databases будут базы данных на SQL Server;

q      Alert if counter (Оповестить, если счетчик) — предупреждение сработает, если станет справедливым одно из трех условий:

·                rises above — значение счетчика превысит значение, указанное в поле Value;

·                falls below — упадет ниже этого значения;

·                becomes equal to — станет равным указанному значению.

Например, если вы настроили параметры для оповещения так, как показано на рис. 8.6, предупреждение сработает при заполнении журнала транзакций базы данных db1 более чем на 80%.

Рис. 8.6. Настройка предупреждения для переполнения журнала транзакций

Отметим, что аналогичные оповещения можно создавать и средствами Windows. Для этого используется консоль Производительность в системном меню Пуск | Программы | Администрирование. Применение этой консоли по сравнению с SQL Server Management Studio в некоторых случаях может быть даже удобнее, поскольку:

q      в одно предупреждение можно добавить сразу несколько счетчиков (в предупреждениях SQL Server Agent допускается проверка только одного значения счетчика);

q      можно использовать не только счетчики, относящиеся к данному экземпляру SQL Server (как в предупреждениях SQL Server Agent), но также счетчики для других экземпляров SQL Server и счетчики операционной системы.

Про работу с WMI будет рассказано в модуле 9. Здесь отметим только, что это самый мощный тип предупреждения. При помощи предупреждений этого типа можно перехватить и события SQL Server, и изменения значений счетчиков производительности, а также изменения в сотнях объектов SQL Server и операционной системы. Например, при применении предупреждений этого типа можно отреагировать на запуск или завершение работы приложения, появление или исчезновение файла из каталога, изменение размера файла и т. п.

На вкладке Response (Отклик) свойств предупреждения вы можете настроить реакцию на событие, на которое настроено это предупреждение. В вашем распоряжении есть возможность выполнить задание SQL Server Agent или оповестить оператора.

При помощи вкладки Options (Настройки) вы можете указать дополнительные параметры для реакции на события, например, можно определить, будет ли передаваться операторам полная информация о событии при отправке уведомления по электронной почте, пейджеру или сети, указать дополнительный текст для сообщения, которое будет передаваться оператору. При помощи раздела Delay between responses (Задержка между откликами) вы можете указать задержку между выполнением действий, определенных как реакция на событие. По умолчанию используется значение 0, т. е. действия будут производиться с минимально возможной задержкой.

Последняя вкладка свойств предупреждения — History (История). На ней вы можете просмотреть информацию о том, когда в последний раз сработало предупреждение, когда в последний раз были выполнены действия, определенные в качестве реакции, а также общее количество срабатываний предупреждения. При помощи флажка Reset Count (Сброс счетчика) можно сбросить этот счетчик предупреждений.

Историю срабатывания предупреждений проще всего просматривать при помощи журналов событий SQL Server. Обратите внимание, что информация записывается именно в журналы SQL Server, а не SQL Server Agent.

Получить учебные материалы по этому курсу