У нас есть два сервера MS SQL (один 2000 и один 2005), которые выполняют ряд заданий в разное время днем и ночью. У этих заданий есть ряд шагов, которые извлекают данные из базы данных Informix (наша бизнес-система) и обновляют таблицы для использования в различных системах отчетности и производстве.
На выходных у нас произошел сбой в импорте, в результате чего многие системы отчетности предоставили неверные данные.
Из-за ограничений безопасности мы не можем включить отправку электронных писем с серверов, поэтому как мы можем эффективно отслеживать эти задания без необходимости постоянно проверять статус задания в Enterprise Manager или MS SQL Studio? Можно ли выполнить запрос на серверах и узнать статус различных заданий?
Есть несколько разных способов контролировать вывод заданий sql server.
Вариант 1. Инструмент мониторинга, например Sitesope, MOM / SCOM или Custom Для большинства производственных экземпляров вам нужен инструмент корпоративного мониторинга, который будет сканировать на наличие ошибок, связанных с ОС и SQL. Обычно вы устанавливаете задания агента Sql для записи в журнал событий Windows при сбое, а ваш инструмент мониторинга часто читает журнал событий Windows и предупреждает вас в зависимости от условий, которые вы определяете. Вы можете приобрести систему мониторинга, такую как SiteScope, или создать свой собственный инструмент для поиска этих ошибок. Вы также можете использовать такой инструмент, как Logparser, для чтения этих журналов.
Я упомянул этот вариант первым, потому что, если ваша система отчетности имеет решающее значение, вы, вероятно, захотите инвестировать в надежную систему мониторинга в долгосрочной перспективе. В краткосрочной перспективе вы могли бы написать несколько пользовательских сценариев, если бы захотели пойти по маршруту журнала Windows.
Вариант 2: запрос MSDB Вся история заданий sql хранится в базе данных MSDB, и вы действительно можете запросить ее. Вы можете сделать это как из окон запросов, так и из специального инструмента - например, вы можете создать сценарий PowerShell, который периодически подключается к каждому из ваших серверов и запрашивает базу данных msdb для заданных условий и предупреждений соответственно.
Я написал несколько записей в блоге, в которых есть примеры сценариев для запроса истории заданий sql. Ни один из них не делает именно то, что вы просите, но они помогут вам работать с тем, как даты хранятся в MSDB, что может быть немного сложно, поскольку они не хранятся в полях datetime: http://thedbaknows.wordpress.com/category/sql-agent/
Надеюсь это поможет!
Каждый раз, когда я говорю об этом, меня кричат, но я все равно упомяну об этом, потому что это работает для меня.
Практически все, что вы делаете в качестве задания SQL, вы можете сделать из командного файла, используя osql для выполнения соответствующих команд SQL. Преимущество пакетного файла заключается в том, что у вас есть большая гибкость в том, как вы анализируете результаты и отправляете уведомления, если есть какие-либо ошибки. Особенно, если вы используете Powershell. Просто запустите командный файл из планировщика Windows.
Обычная критика заключается в том, что это нестандартный способ делать что-то, и я думаю, что это так. Однако у меня более сотни серверов, разбросанных по северо-западу Великобритании, и использование пакетных файлов (и некоторого VBScript) для выполнения задач резервного копирования и обслуживания базы данных и анализа результатов - лучший способ, который я нашел, чтобы сделать вещи управляемыми.
JR
Если ваше приложение для мониторинга может запускать SQL Statment:
Вы можете запустить процедуру sp_help_job и поместить результаты в таблицу, а затем искать задания, для которых last_run_outcome равен 0. Если они есть, приложение мониторинга отправит электронное письмо.
Или, что еще лучше, проинформируйте свое руководство, что ограничение, что SQL Server не может отправлять почту, отрицательно сказывается на вашем упреждающем мониторинге SQL Server, поскольку SQL Server не может использоваться в полной мере, предупреждая администраторов баз данных о наличии задания. неудача.
Я предполагаю, что вы используете какую-то почтовую систему корпоративного класса (Exchange, Lotus и т. Д.). Настройте SQL Server для отправки почты через SMTP в почтовую систему и настройте почтовую систему так, чтобы SQL Server мог отправлять электронную почту только администраторам баз данных. Таким образом, не нужно беспокоиться о том, что SQL Server волшебным образом отправляет электронную почту людям, которые не должны их получать.
Какая логика стоит за тем, чтобы серверы SQL все равно не отправляли электронную почту?