SQL Server Agent
SQL Mail и SQLAgentMail
Планирование заданий
Оповещение операторов
Журнал истории задания
Оповещения
Оператор RAISERROR
Отслеживание событий
Траблешутинг оповещений и заданий
Многосерверные задания
Публикация в WEB
Вопросы для повторения

SQL Server Agent

Каждый DBA может существенно упростить свою работу, если освоит не сложные методы автоматизации рутинных, повседневных задач администрирования, выполняемых SQL сервером. Многие задачи (резервирование, импорт/экспорт) можно заставить сервер выполнять самостоятельно по установленному Вами расписанию. Возможные неполадки также могут устранятся сервером самостоятельно, в соответствии с заданной Вами схемой. Так, сервер может превентивно реагировать на события (например ошибки) выполняя заданные операции или устанавливая более подходящие для сложившейся ситуации режимы своей работы. Например, при появлении ошибки 9002 (переполнение журнала) можно настроить так реакцию сервера, что будет выполнятся оператор, очищающий журнал. Или другой пример, при обнаружении нежелательных блокировок можно автоматически отправлять уведомление администратору.

Всё, что вам нужно из компонент сервера для облегчения своих обязанностей, это SQL Server Agent, сам MSSQLServer и EventLog от NT. Разберём, для начала, наиболее полезную компоненту сервера. Сфера её владений, это оповещения, расписания заданий и операторы. Причём задания и оповещения отделены друг от друга и выполняются независимо. Такой подход позволяет выбирать любой из этих компонентов в качестве реакции на событие, особенно, если один из них недоступен. Сервис SQL Server Agent, как и любая другая служба NT регистрируется в системном журнале операционки и ведёт там записи о событиях сервера баз данных. После запуска, SQL Server Agent начинает сопоставлять события с заданиями и оповещениями (содержащимися в кэше) и на основе этого выбирает действия в качестве реакции на заданные администратором события. Операционкой журналируются все ошибки SQL сервера с уровнями от 19 по 25, а также, могут записываться в журналы записи, порождаемые системными хранимыми процедурами sp_addmessage и sp_altermessage. Кроме того, возможность записывать в журнал приложений Windows NT имеет оператор RAISERROR WITH LOG и расширенная хранимая процедура xp_logevent.

Сервис SQL Server Agent может запускаться, как от имени LocalSystem, так и от имени учётных записей. Разумеется, это влияет на то, какой набор возможностей будет представлен для SQL Server Agent. К примеру, в SQL SEM можно настроить автоматический рестарт этой службы в случае зависания, но это возможно, только если она стартует от имени учётной записи, которая входит в локальную группу администраторов NT. Давайте рассмотрим, как будут меняться возможности SQL Server Agent при запуске её от разных учётных записей.

Для того, что бы служба SQL Server Agent могла работать с сервером баз данных необходимо, что бы учётная запись, от имени которой она стартует, была отражена в роли сервера sysadmin. LocalSystem – это фактически то же самое, что группа Administrators локального NT сервера, что автоматически делает её членом роли sysadmin. Поскольку используется локальная учётная запись, доступ к сетевым ресурсам для SQL Server Agent будет под вопросом. Если Вы посчитали, что администраторские права на локальный сервер для SQL Server Agent – это слишком много, можете запустить его от имени локальной учётной записи. Но тогда позаботьтесь о том, что бы эта учётная запись была включена в роль sysadmin, напрямую или через отображённую на эту роль локальную группу сервера Windows NT. Опять же, сетевые ресурсы, если они не доступны всем подряд, будут для службы недоступны. Для того, что бы SQL Server Agent мог использовать сетевые ресурсы, удобно использовать для его запуска учётную запись пользователя домена. Особенно часто это используется при подключении к почтовым серверам. Для такой учётной записи нужно также обеспечить её присутствие в роли sysadmin.

Если вы правильно настроили запуск SQL Server Agent, после этого она будет пытаться подключиться к серверу баз данных. При подключении будут использоваться механизмы проверки подлинности либо NT (по умолчанию), либо SQL сервера. При механизме NT, для проверки подлинности используется та учётная запись, от имени которой стартует SQL Server Agent.

SQL Mail и SQLAgentMail

С помощью этих двух программ SQL сервер может получать и отправлять сообщения электронной почты, выступая как клиент сервера передачи сообщений. Программа SQLAgentMail работает через сервис SQLServerAgent и осуществляет уведомления об успешности выполнения заданий по расписанию или оповещает через почту о событиях сервера баз данных. SQLAgentMail стартует вместе со своей службой, но для того что бы этот старт был удачным, необходимо что бы SQLServerAgent запускался от имени учётной записи пользователя домена. Программа SQL Mail содержит несколько расширенных хранимых процедур, через которые MSSQLServer может обрабатывать запросы в теле сообщения электронной почты и возвращать отправителю отчёт. Запрос должен содержать только одну очередь. Другим назначением SQL Mail является отправка сообщений электронной почты из пользовательского приложения. Наиболее часто для этого используется хранимая процедура xp_sendmail, которая запускается из триггера. Для того, что бы программа SQL Mail могла работать, у Вас должен существовать почтовый профиль учётной записи пользователя домена, от имени которого стартует MSSQLServer. Старт SQL Mail может быть автоматический, вместе с сервером баз данных, либо можно запускать его вручную по необходимости.
Для правильной работы сервера баз данных, как почтового клиента необходимо выполнять следующие пять правил:
1. Почтовый сервер должен поддерживать почтовый интерфейс MAPI-1;
2. На сервере баз данных должен быть установлен почтовый клиент;
3. Сервисы MSSQLServer и SQLServerAgen должны стартовать от имени одного или двух разных пользователей домена;
4. Если сервер и агент стартуют от имени разных пользователей, каждому такому пользователю нужно настроить свой почтовый профиль;
5. В SQL SEM можно задать профиль для любого сеанса передачи почты как SQL Mail, так и SQLAgentMail.
Возможна также передача сообщений на пейджер через сервер передачи сообщений, который должен уметь устанавливать связь с вашим пейджером.

Планирование заданий

Наверное, удобнее всего создавать и планировать исполнение заданий (Jobs) с помощью SQL Server Enterprise Manager (EM). Однако, помимо стандартного, второго пути управления сервером с помощью системных хранимых процедур, для заданий есть ещё набор объектов распределённого управления SQL-DMO (Distributed Management Objects), с помощью которых можно включать опции управления заданиями в пользовательское приложение.
Информация о каждом задании помещается в таблицу msdb..sysjobs и может быть добавлена через EM или процедуру sp_add_jobs. По умолчанию, каждое задание становится активным сразу после создания. Не активные задания невозможно выполнить по расписанию иначе, чем через ЕМ. У задания есть владелец (owner), которым по умолчанию назначается учётная запись подключения пользователя NT или SQL сервера, под которой это задание создавалось. Задания могут выполняться локально или на удалённых серверах. Возможна группировка заданий по категориям, что существенно (в отличии от v.6.5) облегчает работу с большим количеством заданий.
Если владельцем задания является пользователь, учётная запись которого не включена в роль sysadmin (авторизация возможна, как NT, так и SQL сервера), полное и правильное исполнения всех возможных этапов этого задания возможно только при условии, что он имеет соответствующие разрешения на каждом из этапов. Это обусловлено тем, что SQL сервер для установки соответствующего контекста пользователя использует оператор SETUSER. Механизм проверки разрешений начинает действовать тогда, когда SQL сервер обнаруживает, что учётная запись владельца задания или этапа его выполнения не входит в роль sysadmin или назначена к выполнению в отличном от администратора контексте.
Для проверки прав в контексте учётной записи пользователя владельца задания, SQL сервер устанавливает необходимый контекст с помощью оператора SETUSER, который, в свою очередь, обращается к контроллеру домена, для определения группы, к которой принадлежит владелец задания. Этот механизм позволяет определить набор его разрешений для доступа к базе данных.
После инсталляции SQL сервера, по умолчанию, всем владельцам заданий разрешено выполнять этапы, содержащие запросы T-SQL, процессы репликации, команды операционной системы, VBScript и JavaScript. Каждый из этапов может содержать только один из перечисленных типов выполнения. Контекст безопасности, в данном случае, будет зависеть от того, принадлежит ли этот владелец к роли sysadmin. Если да, то контекст будет той учётной записи NT, от имени которой стартует SQLServerAgent, если нет, то в контексте созданной при инсталляции SQL сервера учётной записи SQLAgentCmdExec. Отменить разрешение по умолчанию владельцам заданий выполнять команды ОС и активные сценарии можно только изменением свойств службы SQL Server Agent. Для того, что бы выполнить этап задания в контексте учётной записи, не состоящей в роли sysadmin, необходимо, что бы учётная запись, от имени которой стартует SQLServerAgent, входила в группу Windows NT - Administrators. Только после выполнения этого условия, служба SQL Server Agent получит возможность работать в контексте SQLAgentCmdExec.
Для создания задания или его этапа используют ЕМ или системную хранимую процедуру sp_add_jobstep, которые создают соответствующие записи в таблице msdb..sysjobsteps. При определении задания нужно помнить, что существуют обязательные переменные и параметры, без которых оно никогда не заработает. Результирующие наборы каждого этапа задания можно направить в выходной файл. Такие файлы не могут быть общими для разных этапов задания. При определении этапа с командами ОС, не забывайте указывать код успешного выхода из процесса, и полный путь к запускаемым *.exe, *.com, *.bat или *.cmd файлам. Иначе SQLServerAgent может их просто не найти. При включении в этап активного сценария (скрипт VB или Java), необходимо указывать язык скрипта. Для вывода результатов в историю задания или для создания в этапе нового объекта используют SQLActiveScriptHost. Откомпилированные активные сценарии запускаются, как команды ОС. Процессы репликации (агенты) всегда существуют в виде заданий.
Для каждого этапа задания можно определить действия, которые будут выполняться в случае успешного или не успешного его выполнения. По умолчанию, если всё ОК, осуществляется переход к следующему этапу. Если Вас это не устраивает, вы можете изменить логику последовательности действия для каждого задания. Также, можно указать число повторных попыток исполнения задания, в случае неудачи. Интервал повторения задаётся в минутах, что бывает удобно при подключении к удалённому серверу. После выполнения задания можно задать его удаление.
Задания могут выполняться по расписанию (если задание включено), которое легко составляется в ЕМ или с помощью sp_add_jobshedule, создающие соответствующие записи в таблице msdb..sysjobshedules. Кроме расписания, задания могут выполняться в ответ на оповещение. Разумеется, для успешной отработки расписаний сервис SQLServerAgent должен быть стартован. Расписание может определять запуск задания единожды, ежедневно, еженедельно, ежемесячно или во время простоя процессора. Для того, что бы SQLServerAgent мог узнать у NT, что процессор простаивает, необходимо, что бы его стартовая учётная запись входила в группу Administrators. Одно задание может иметь несколько расписаний, например, для будней и выходных дней.

Оповещение операторов

Создать нового оператора можно в ЕМ или, воспользовавшись системной хранимой процедурой sp_add_operator. В любом случае, должна добавиться соответствующая запись в таблицу msdb..sysoperators. Назначение операторов в том, что бы предоставить возможность оповещения необходимого персонала для оперативной реакции на события сервера или результаты исполнения заданий по расписанию. У Вас есть возможность определить действия, в ответ на события сервера (например, ошибки или результаты выполнения этапов задания), которые будут либо регистрироваться в журнале приложений NT, либо создавать сообщение оператору по электронной почте, пейджеру или по сети (команда net send для NT). Для заданий возможен ещё вариант удаления задания. Для оповещения нескольких операторов используют групповой псевдоним электронной почты. Для успешного оповещения, Вам необходимо убедится, что используемые почтовые псевдонимы работоспособны. Для каждого оператора можно определить расписание его работы, когда он будет доступен для приёма оповещения. В не установленное расписанием рабочее время оператора, оповещения ему посылаться не будут. Для операторов, оповещаемых по электронной почте, необходимо указывать полный адрес электронной почты. Это обусловлено тем, что SQL сервер не умеет распознавать похожие псевдонимы (например, «smithj» и «smithje» для сервера будут на одно лицо). Полная информация обо всех оповещениях оператора записывается в системную таблицу sysoperators. Если оператору не удаётся получать отправленные сервером оповещения, значит он не доступен через свой псевдоним, или для передачи сообщений по сети. Для возобновления оповещений, необходимо проверить возможность получения почтовых или иных сообщений оператором посредством иных средств (через почтового клиента или командой из консоли операционной системы). Также, просмотрев записи об истории оповещений оператора и системные журналы, можно определит время последнего, успешного уведомления и описание ошибок, которые возникают при попытке оповещения.

Журнал истории задания

Вся информация об этапах выполнения заданий регистрируется службой SQLServerAgent в специальном журнале, который хранится в таблице msdb..sysjobhistory. Существует ограничение на глубину истории выполнения заданий, которое можно установить, воспользовавшись ЕМ. Журнал содержит информацию о времени исполнения этапа задания, его успешности выполнения, операторах оповещения, длительности исполнения и сообщениях об ошибках. Установки по умолчанию не подразумевают, что вы будете хранить историю по каждому заданию. Поэтому, для хранения информации о каждом задании, следует увеличить максимальны размер строки в таблице msdb..sysjobhistory, с таким расчётом, что при исчерпании этого размера, запись начнётся поверх старого содержимого истории задания.

По умолчанию, база данных msdb будет автоматически расширяться, и её журнал транзакций будет очищаться после каждой контрольной точки. После инсталляции будет действовать ограничение, которое отслеживает, что бы максимальное количество записей журнала для всех заданий не превышало одной тысячей. Причём каждое отдельное задание не сможет занимать более ста записей. Если задание было занесено в журнал более ста раз, то последующие записи будут автоматически затирать самые старые.

Есть и ещё одна интересная особенность настроек заданий. Если в процессе выполнения задания может начаться процесс остановки работы сервисов SQL сервера, можно задать максимальный интервал ожидания сервером окончания исполнения задания, в течении которого сервер не сможет прервать работу задания и будет ждать его завершения, а только потом завершить свою работу. Это может быть очень полезно, когда вы планируете некие операции, выполняемые по расписанию в Ваше отсутствие, и хотите обезопасить эти операции от типичной в наше время ситуации, когда электросети производят «веерные» отключения потребителей. Использование источников бесперебойного питания и специальных программных средств, которые могут в случае отключения электричества аккуратно опустить, а потом поднять сервер, конечно очень удобно и полезно, но может сбить исполняемые сервером задачи. Теперь этого можно избежать.

Оповещения

Дорожащий своей работой DBA всегда испытывает повышенный интерес к событиям сервера, которые (почему-то) норовят произойти с сервером в его отсутствие. Современные требования приложений баз данных заставляют администраторов поддерживать работоспособность своих систем семь дней в неделю и 24 часа в сутки. С другой стороны, при условии грамотного администрирования, можно добиться высокой степени готовности и доступности программно - аппаратного комплекса, так, что вмешательство обслуживающего персонала будет происходить в очень редких случаях, а у руководства будет складываться впечатление, что его специалисты сидят без работы. Однако маломальский опыт обслуживания серверов баз данных подсказывает DBA, что серьёзные проблемы всё же возникают (в самый не подходящий и неожиданный момент), и их детальный анализ, как правило, указывает на то, что проблему можно было прогнозировать и предотвратить. Об одном из инструментов, который помогает DBA оперативно получать необходимую информацию для принятия решений о реакции на события сервера, и который является неотъемлемой частью MS SQL Server, мы сегодня и поговорим.
Всем известно, что заполнение журналом транзакций всего дискового пространства может стать катастрофой для сервера. У администратора достаточно средств контроля размера журнала и дискового пространства, но те средства, которые входят в стандартную поставку, требуют от него выполнять этот контроль вручную. Также, можно устроить автоматический опрос критичных параметров, оформив соответствующее задание и запуская его по расписанию, но это тоже, как-то не по-людски. Вот если бы сервер присылал вовремя необходимые предупреждения на пейджер или (в крайнем случае) по электронной почте... Что же, нельзя не отметить, что MS SQL Server предоставляет прекрасный инструмент для передачи сообщений о событиях сервера - это ОПОВЕЩЕНИЯ.
Таким образом, Вы можете использовать оповещения для оперативного реагирования на неисправности или ошибки сервера, для отслеживания и принятия мер при изменении режима работы, для реакции на действия пользователей или их ошибки, а также, если ни один из операторов в момент критичного события не доступен, отправить оповещение оператору последней надежды.
Существует только ода причина, в ответ на которую Вы сможете отправить оператору(ам) оповещение - это появление в журнале приложений Windows NT записи об ошибке/событии, которая порождена или одной из служб или определена пользователем. Что бы появилась возможность вносить записи в журнал NT, порождающие их события должны быть описаны заранее. Большинство ошибок/событий определены разработчиками в стандартных поставках операционной системы и сервера баз данных. Если возникает необходимость, Вы можете дополнить стандартный набор сообщений своими собственными, которые будут генерироваться из хранимой процедуры или триггера посредством оператора RAISERROR. Механизм отслеживания событий сервера баз данных достаточно гибок и позволяет Вам регистрировать и оповещать оператора даже об удалении пользователем отдельных записей из таблиц баз данных. Последовательность отработки оповещения, в таком случае, будет следующая: вначале, происходит само действие (удаление записи), например, в рамках процедуры содержащей RAISERROR; сгенерированное RAISERROR сообщение/ошибка (здесь применяется код ошибки из диапазона кодов, предоставленных для пользователя) записывается в журнал приложений Windows NT; журнал NT передаёт службе SQL Server Agent информацию о появлении записи, содержащей код ошибки; SQL Server Agent сверяет коды всех ошибок со списком оповещений, предварительно записанных в таблицу msdb..sysalerts, которая в течении сеанса работы сервера находится в кэше; если соответствие кодов ошибки установлено, из системной таблицы msdb..sysnotifications выбирается соответствующее оповещение, а адресат оповещения определяется в таблице msdb..sysoperators.
Каждому номеру ошибки/события или их классу/уровню может быть сопоставлено только одно оповещение. Разные оповещения на одну ошибку Вы можете определять только для разных баз данных. Однако, если этого достаточно, можно определить для конкретного уровня или ошибки одно оповещение для всех баз данных. Если у Вас определены для одной ошибки оповещения для каждой базы данных и для всех баз данных, выполнится более конкретное оповещение, т.е. оповещение для конкретной базы данных. Два или более оповещений на одну ошибку выдаваться никогда не будут. Если Вы определяете оповещение для всех баз данных или для целого уровня ошибок, удобно использовать метки подстановки, которые дополнят текст описания именами затронутых событием объектов. В столбце описания таблицы sysmessages, символ процента (%) и расположенные за ней символы служат как метка, определяющая подставляемое имя объекта в генерируемый текст описания ошибки. Например, %d - метка числового значения, а %ls (или '%.*ls') - метка строки. Для текста сообщения об ошибке 105 (Unclosed quote before the character string %.*ls.), вместо %.*ls может быть подставлено или "SA" или другой логин.
Вот несколько примеров использования меток подстановки, взятые из таблицы sysmessages:

Номер ошибки / Описание ошибки
21 / Warning: Fatal error %d occurred at %S_DATE.
103/ The %S_MSG that starts with '%.*ls' is too long. Maximum length is %d.
231/ No such default. ID = %ld, database ID = %d.
232/ Arithmetic overflow error for type %ls, value = %f.

Оповещения, определённые для уровня/категории ошибок обрабатываются сервером несколько иначе, чем простые оповещения. Например, для уровней ошибок 19-25 установлена автоматическая запись в журнал приложений Windows NT. Для не устранимых ошибок (уровни с 20 по 25) необходимо обязательно указать оповещаемого оператора. Несколько таких оповещений, с пометкой "Demo", определяются при инсталляции сервера. Для того, что бы они стали активны, необходимо убрать пометку "Demo", а для не устранимых ошибок назначить оповещаемого оператора.
Обслуживание оповещений может отнимать у сервера значительные ресурсы. Для того, что бы разгрузить "слабый" сервер, можно организовать переадресацию событий/ошибок на другой сервер баз данных. Для этого, при настройке службы SQL Server Agent необходимо указать другой сервер, на который будут передаваться сообщения об ошибках заданного уровня или все ошибки не ниже заданного уровня.

Оператор RAISERROR

Кроме стандартных ошибок/событий, у Вас есть возможность определять оповещения для ошибок пользователей приложений баз данных, которые будут генерироваться оператором RAISERROR или на стороне клиента или из хранимой процедуры. Оператор RAISERROR возвращает сообщение об ошибке и устанавливает с помощью системной функции @@error флаг регистрации ошибки. Например:
...
RAISERROR (50111, 16, 1, @CustomerID, @username)
...
При этом, в текст сообщения об ошибке параметр @CustomerID может быть передан меткой %d, а @username меткой %s.
К примеру, использование этого оператора в триггере обновления таблицы и вызове его при не выполнении заданного условия (контрольного значения), может предоставить Вам возможность создания оповещения оператору, для того, что бы он мог вовремя вмешаться и урегулировать зафиксированные расхождения. Для создания такого оповещения необходимо предварительно определить новое сообщение об ошибке, сгенерировать ошибку в приложении и определить на основании этой ошибки необходимое оповещение. Оповещение будет невозможно, если в журнал приложений Windows NT не будет сделана соответствующая запись об ошибке или событии. Удобным инструментом для ввода пользовательских ошибок является Enterprise Manager или системная хранимая процедура sp_admessage. Для определяемых Вами пользовательских ошибок/событий у сервера выделен диапазон номеров, начиная с 50000. Номера меньше пятидесяти тысяч зарезервированы для нужд сервера. Все номера ошибок и их описания хранятся в базе master, в таблице sysmessages. При определении нового кода ошибки можно использовать метки параметров, для уточнения необходимых деталей. Например:

EXEC sp_admessage 50111, 16, 'Customer %d was deleted by %s', 'us_english', 'true'

Метка %d подставит номер заказчика, а %s - имя пользователя, его удалившего из таблицы заказчиков. В результате, сгенерированная приложением ошибка 50111 будет записана в журнал NT, что породит определённое предварительно оповещение следующего содержания:

Error: 50111, Severity: 16, State 1
Customer 911 was deleted by DOM1\customkiller

Существует возможность вводить описание ошибки/события на Русском языке. Для этого, Русский язык должен быть выбран во время инсталляции сервера баз данных, а номер сообщения об ошибке не ниже 50100.

Отслеживание событий

С помощью механизма оповещений можно не только оперативно получать информацию об ошибках/событиях сервера, но и отслеживать изменения режимов и характеристик его работы. Например, можно отслеживать те же самые параметры, которые контролируются программой Windows NT Performance Monitor и выдавать оповещения, если превышены заданные Вами пороговые значения этих параметров. Таким образом, можно заведомо узнать о том, что журнал транзакций вот-вот заполниться и автоматически выполнить его резервирование. Причём совершенно не обязательно, что бы Windows NT Performance Monitor был запущен. Для отслеживания режимов функционирования ресурсов SQL сервера, вы можете определить оповещения для следующих объектов: Access Methods (методы доступа); Buffer Manager (диспетчер буфера); Cache Manager (диспетчер кэша); Databases (базы данных); Locks (блокировки); SQL Statistics (статистика SQL). Существует маленький нюанс, связанный с задержкой во времени между событием/ошибкой и генерацией оповещения. Для того, что бы оповещение было создано и получено вовремя (т.е. до того момента, когда событие может негативно повлиять на работу сервера или приложения) существует возможность изменения интервала задержки между ответами, или можно подобрать такое пороговое значение, которое позволит оператору или непосредственно оповещению выполнить необходимые действия до достижения критического значения.
Самым быстрым способом доведение информации о событиях/ошибках на сервере до оператора является передача оповещения на пейджер. Но может случиться так, что это событие произойдёт в то время, когда в расписании доступности операторов не будет существовать ни одного, кто в это время работает. Для того, что бы гарантировать получение оповещения в допустимые сроки, можно определить оператора "последней надежды", который может быть только один. Для обеспечения передачи оповещений оператору "последней надежды" необходимо, что бы служба SQL Server Agent была запущена. Правда, если в Ваше отсутствие, эта служба остановиться, оповещение всё равно будет отправлено, т.к. информация об операторе "последней надежды" заноситься в кэш. Если Вам в последствии потребуется удалить или изменить оператора "последней надежды", то Вы должны вначале отменить назначение оператора "последней надежды", а потом удалить самого оператора или установить назначение другому.

Траблешутинг оповещений и заданий

Поиск и устранение неполадок в работе заданий и оповещений стандартное руководство Микрософт предлагает проводить по следующей схеме:

1. Проверьте, запущен ли SQL Server Agent.
2. Убедитесь, что учётная запись, от имени которой стартует агент, отражена в роли sysadmin.
3. Убедитесь, что пароль учётной записи, от имени которой стартует агент, соответствует паролю, указанному при запуске сервиса SQL Server Agent (список сервисов в панели управления или через соответствующий пункт SQL Server Enterprise Manager).
4. Убедитесь, что интервал ожидания подключения агента к серверу баз данных достаточно велик.
5. Убедитесь, что задание, расписание или оповещение находится в состоянии «включено». Если оповещение было удалено, то автоматически удалились и все связанные с ним уведомления. Имейте в виду, что действия по отключению заданий, расписаний или оповещений нигде не журналируются.
6. Убедитесь, что контексту, через который работает владелец задания, предоставлены необходимые для выполнения всех этапов права. Если владелец задания не входит в роль sysadmin, этапы задания будут выполняться в контексте учётной записи NT SQLAgentCmdExec.
7. Убедитесь, что учётная запись SQLAgentCmdExec существует и создана при инсталляции сервера баз данных или из SQL Server Enterprise Manager.
8. Убедитесь в правильности присвоения пароля учётной записи SQLAgentCmdExec, который должен быть введён в окне SQL Server Agent Properties.
9. Убедитесь, что размер базы msdb достаточно велик для размещения в нём истории выполнения заданий. Для анализа используйте число строк в таблице sysjobshistory. Неверная настройка этой базы может привести к заполнению базой всего дискового пространства или нехватке места в для истории заданий в базе msdb.
10. Убедитесь, что используемый для рассылки оповещений почтовый клиент работоспособен и тестовые сообщения доставляются правильно и своевременно. Для тестирования используйте профиль учётной записи, от имени которой стартует SQL Server Agent.
11. Убедитесь, что журнал приложений NT не переполнен.
12. Убедитесь, что утилизация процессорного времени находится в допустимых пределах. Одной из возможных причин высокой утилизации процессоров может стать появление часто повторяющегося события, на которое создано оповещение. Такое случается вследствие ошибки администратора, который мог настроить оповещение по часто встречающемуся событию, не учтя аппаратных возможностей или доступных для этого ресурсов, или он мог установить слишком короткий интервал для часто встречающихся оповещений.   Также чрезмерная утилизация ЦПУ может проявиться вследствие того, что сервер перестал получать доступ к необходимому ему ресурсу и генерирует соответствующую ошибку. Результатом может стать отказ сервера в обслуживании клиентов. Когда оповещений очень много, а утилизация ЦПУ слишком высока, возможно накопление оповещений в очереди ожидания на обработку, что может, как повлиять на работоспособность сервера, так и на скорость ответной реакции сервиса SQL Server Agent на события сервера.

Причину неполадок можно локализовать с помощью записей в журнале приложений и системы NT, а также с помощью журналов ошибок SQL Server Agent и SQL Server (папка MSSQL7\Log). Следует только помнить, что при каждом запуске SQL сервера эти журналы создаются заново. Кстати, можно создать оповещение, которое после каждой записи ошибки в журнал SQL Server будет посылать соответствующую команду net send.
Журнал приложений Windows NT может настраиваться на несколько режимов хранения записей. Это может быть фиксированный размер, без возможности автоматической замены старых записей новыми или, наоборот, умеющий это делать. Также, при полном заполнении, через заданные промежутки времени может открываться новый журнал. Вам нужно выбрать разумный компромисс, который бы обеспечивал Вам наличие необходимой глубины истории записей и, в то же время, исключалась возможность переполнения журнала. Если возникнет необходимость принудительной очистки журнала приложений, помните, что удалятся все содержащиеся в нём записи, которые относятся не только к серверу баз данных, но и к другим задачам. Ещё одним источником информации о времени возникновения проблем оповещений или заданий может стать журнал их истории выполнения.
Когда Вам удалось локализовать проблему, внимательно изучите её описание в документации (BOL, KB, TN) и действуйте далее в соответствии с инструкциями.
Если же проблема не может быть устранена, но порождающая её ошибка/событие не критична для работы сервера и приложений, можно В КРАЙНЕМ СЛУЧАЕ запретит генерацию оповещения для ошибки путём внесения соответствующей записи в системный реестр Windows NT.

Многосерверные задания

Если Ваша организация имеет несколько SQL серверов, может оказаться удобным использовать задания, которые будут выполняться на всех или избранных серверах под управлением одного сервера. Такой сервер будет являться главным и будет не только распределять задания между подчинёнными серверами назначения, но и получать от них все события. Это даст Вам возможность управлять заданиями нескольких серверов из одного узла, объединив, таким образом, свои серверы в одну логическую, структурную единицу. Правда, все SQL серверы должны быть не младше седьмой версии. Как правило, главный сервер располагается в головной конторе Вашей организации, причём, работать он может только под NT. Выделить такой сервер можно в специальном мастере, в составе Enterprise Manager или с помощью системной хранимой процедуры sp_msx_enlist. При этом в системную таблицу главного сервера systargetservers добавляется соответствующая строка. Для каждого сервера назначения мастер автоматически создаёт специальную учётную запись с суффиксом _msx_probe с паролем SQL сервера, которой предоставляются права для доступа к базе msdb главного сервера, откуда они будут загружать задания. Пароль менять нельзя, т.к. сервер назначения утратит предоставленные ему права, и «лечится» это только удалением сервера назначения из списка и повторного его там определения. Также, мастер создаёт специального оператора главного сервера MSXOperator и такого же оператора на каждом из серверов назначения. Кроме указанного уже мастера, сервер назначения можно заводить с помощью sp_msx_enlist, при этом, соответствующие записи добавляются в таблицу msdb..systargetservers. У сервера назначения может быть только один главный сервер, который должен располагаться или в том же домене, или в домене, имеющем с доменом главного сервера доверительные отношения. Вы не сможете закрепить сервер назначения за другим главным сервером, пока он не будет исключён из списка серверов назначения ранее определённого главного сервера. Главный сервер может быть использован серверами назначения и как сервер переадресации событий, если его ресурсы в состоянии справиться с такой повышенной нагрузкой.
Главный сервер помещает многосерверные задания в список загружаемых с него файлов, который хранится в таблице msdb..sysdownloadlist. Для того, что бы определить, не появились ли новые задания, серверы назначения должны периодически подключаться к главному и заглядывать в этот список на предмет появления там для них новых или обновлённых заданий. Если задание получено, то, после его исполнения, сервер назначения помещает на главный сервер результаты его исполнения и завершения. Основные экземпляры заданий и расписаний хранятся на главном сервере, и только они могут быть изменены. Те экземпляры, которые хранятся на серверах назначения менять нельзя. Удобство использования Enterprise Manager заключается в том, что он автоматически включает в список загружаемых файлов все необходимые инструкции. При необходимости просмотра результатов выполнения и завершения задания, можно обратиться к системной таблице msdb..sysjobservers. Дополнительную информацию, содержащую обычные сведения истории заданий, можно получить на сервере назначения из таблицы msdb..sysjobshistory.

Публикация в WEB

MS SQL Server имеет ещё одну замечательную возможность, это публикация данных в виде HTML страниц. Причём, у Вас есть возможность не только вывести на WEB страницу данные, аналогичные выдаваемым оператором SELECT, но и форматировать HTML страницу. Вам доступно: создание заголовков страницы; указание времени последнего обновления; форматирование рамок, шрифта и столбцов таблицы; задание максимального числа строк таблицы; задание числа строк таблицы для страницы; размещение гиперссылок и их описателей. Такие возможности вам предоставляет WEB Assistant Wizard и системная хранимая процедура sp_makewebtask. Принцип их работы достаточно прост. В базе создаётся хранимая процедура, которая публикует данные из этой базы. В таблице msdb..mswebtasks создаётся задание ( WEB Assistant Job), которое может единожды или по расписанию размещать эти публикации, и работу которого будет обеспечивать SQL Server Agent. Каждому заданию и процедуре присваивается логическое имя, которое, по возможности, должно быть достаточно описательным. Для использования указанного визарда и системной процедуры у Вас должны быть права на выполнение оператора SELECT и на исполнение CRAETE PROCEDURE в публикуемой базе данных. Необходимо также помнить, что ни визард ни sp_makewebtask не умеют определять, что ссылки, базы, таблицы или процедуры, которые задействованы в публикации, действительно существуют. Убедитесь в этом до их запуска. Для того, что бы установить, какие данные будут публиковаться, можно воспользоваться графическим интерфейсом WEB Assistant Wizard, написать соответствующий запрос средствами T-SQL и/или хранимых процедур, использовать существующие хранимые процедуры. Кроме этого, сервер баз данных должен получить информацию о том, куда он должен выложить сформированную страницу, т.е. каталог на диске, в сети или на FTP. По умолчанию всё выкладывается в MSSQL7\HTML. Для того, что бы это было возможно, учётная запись, от имени которой стартует MSSQLServer, должна иметь соответствующий набор прав, для размещения файла в указанном каталоге. Если Вы создаёте WEB страницу с помощью скрипта T-SQL, не забудьте его сохранить. Это позволит Вам многократно его использовать. Сформированная и размещённая в каталоге HTML страница будет доступна для дальнейшего её ручного или автоматического форматирования/редактирования.
Вы можете использовать шаблоны HTML для упрощения процесса создания красивых WEB страниц. Для шаблонов применяются специальные метки, которые указывают где и что размещать на странице. Например, метка <%insert_data_here%> указывает место размещения таблицы, которую сформирует сервер из публикуемых данных. Теги форматирования этой таблицы должны быть размещены между двумя метками: <%begindetail%> и <%enddetail%>.
Если Вы желаете, что бы данные WEB страницы, публикуемые из базы, автоматически обновлялись, задайте в визарде или в sp_makewebtask параметр @whentype. По умолчанию, задание выполниться только однажды и сразу удаляется. Разумеется, такое задание в Enterprise Manager Вы даже не увидите. Однако, вы можете определить нормальное задание, которое можно будет выполнять вручную, единожды в заданное время или по расписанию. Также, существует возможность задать выполнение задания при каждом изменении данных на сервере. В таком случае, SQL сервер сам создаст необходимые триггеры INSERT, UPDATE и DELETE, и в имя этого триггера будет включено имя задания, причём включая возможные пробелы. Если триггеры уже существуют, то в них автоматически добавится запуск sp_makewebtask. Следите только, что бы эти триггеры небыли созданы с параметром WITH ENCRYPTION. Синтаксис sp_makewebtask следующий:

sp_makewebtask имя хр. процедуры, [полное имя HTML файла с указание пути]

Удалит задание можно с помощью системной хранимой процедуры sp_dropwebtask, которая имеет такие же параметры, как и предыдущая процедура. Имена заданий и местоположения файлов можно получить из таблицы msdb..mswebtasks, расписание публикаций можно узнать из msdb..sysjobschedules, определения процедур и триггеров в таблице syscomments.

Вопросы для повторения.

ВОПРОС
Вы хотите создавать резервную копию журнала транзакций базы данных каждый час в основное рабочее время (с 8:00 до 18:00) и каждые три часа в остальное время (с 18:00 до 8:00). Как наиболее эффективно автоматизировать эти задачи?
ОТВЕТ
Определите одно задание для создания резервной копии журнала транзакций и составьте для него два расписания.
ВОПРОС
Руководитель отдела, обслуживающего счета заказчиков, попросил, чтобы его извещали о каждом изменении предельной суммы кредита заказчика (увеличении или уменьшении). Кроме того, необходимо знать имя сотрудника отдела, обновившего счет заказчика, а также получить все объяснения по этому поводу. Как выполнить эту задачу?
ОТВЕТ
Первое, что следует сделать, - это создать пользовательское сообщение об ошибке, в котором указано имя заказчика, предельная сумма кредита, примечания (в предположении, что соответствующий столбец в базе данных уже имеется) и имя сотрудника отдела, сделавшего изменение.
После этого в хранимую процедуру или триггер, выполняющий обновление предельных сумм кредитов заказчиков, необходимо включить оператор RAISERROR, генерирующий пользовательскую ошибку.
Затем назначьте руководителя отдела оператором.
Наконец, создайте на основе пользовательского сообщения об ошибке оповещение, которое будет отправлять назначенному оператору сообщение электронной почты.
ВОПРОС
Вы разрабатываете новое приложение базы данных и хотите проверить его рабочие характеристики. Именно, вы хотите знать, не превышает ли время ожидания блокировки интервал в 20 секунд. Как можно организовать автоматическое получение уведомлений о подобном событии?
ОТВЕТ
Создайте оповещение об изменении рабочего режима на сервере SQL Server для объекта Locks (Блокировки).
ВОПРОС
Когда наступает новое время года, поставщик изменяет цены на некоторые товары. Как с помощью мастера помощника по Вебу обновлять прейскурант на веб-странице?
ОТВЕТ
Создайте задание Веба, обновляющее веб-страницу при изменении цен в таблице. Это задание Веба автоматически создаст триггер для таблицы.