Поставщик хочет запускать задание MSDB каждые 5 минут для бизнес-приложений

У нас есть сторонний поставщик, который пытается интегрировать 2 разных приложения, в которых обе БД находятся на нашем экземпляре SQL Server, с 150+ другими БД, и они хотят создать задание MSDB для «синхронизации» 2 разных приложений каждые 5 минут (сначала они хотел запускать его каждую минуту).

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

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

Другая проблема, с которой я столкнулся, заключается в том, что теперь мне нужно предоставить этому поставщику права «sysadmin» вместо прав «dbo» только на свои БД, когда они выполняют свои обновления через графический интерфейс, и надеюсь, что они не взорвут тот случай, когда моя критически важная задача БД есть (один из минусов консолидации).

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

Поставщик уже отодвинул мои опасения, говоря о том, насколько плохи триггеры. Итак, я немного «погуглил» на этом и вышел пустым. Кто-нибудь видел какую-либо ссылку "авторитетный вид", что это плохая идея, и я могу сослаться на них? Или я должен принять их подход?

Я не верю, что когда-либо писал на форуме sql, прежде чем просить о помощи, поэтому, надеюсь, мой запрос правильно оформлен.

РЕДАКТИРОВАТЬ: Мы работаем с SQL Server 2008 Enterprise R2 x64 SP1 (спасибо за указание, что я забыл упомянуть версию!). Хм, надеюсь, им не нужно менять свои сценарии обновления MSDB, когда мы перейдем на более новую версию.

Спасибо за ваше время! Богатый

ИМО ваш поставщик на самом деле на правильном пути.

Задание прикладного уровня потребовало бы от него большого количества готовых функций агента SQL (например, логики не запускать уже запущенное задание, придумать решение для хранилища безопасности и учетных данных, интегрировать результаты задания с отчеты об ошибках и отслеживание результатов в SQL и т. д. и т. д. и т. д.). И, самое главное, предоставить решение для резервного копирования / HA / DC для планирования. Вы не хотите , ваша история аварийного восстановления , чтобы быть "и после завершения восстановления сервера резервного идти создать эти 50 NT задач планировщика. Таким образом, он прав, выступая против использования системного планировщика, он не имеет ничего от функций и возможностей, которыми обладает Агент.

Он тем более прав, когда отталкивается от спусковых механизмов. Замена периодического задания синхронным триггером увеличивает задержку запроса, повышает согласованность и связь (думаю, что схема меняется ...), увеличивает риск простоя из-за проблем с синхронизацией (ошибка триггера -> ошибка приложения и ошибка задания -> исправить и повторить попытку позже) , значительно увеличивает проблемы взаимоблокировок (из-за перекрестных обновлений между отслеживаемыми и отслеживаемыми) и имеет много других проблем.

Самым простым решением действительно является работа агента, и msdbона ни в коем случае не зарезервирована для администраторов баз данных. Более причудливое решение - использовать таймеры разговоров. и внутренней активации , которые будут иметь некоторые преимущества по сравнению с заданиями агента, в первую очередь из-за локализации (все находится внутри БД приложения, подумайте о зеркалировании сценариев отработки отказа), но я могу полностью понять, если ваш поставщик неохотно пробует что-то, что требует очень специфического ноу-хау. Кстати, я надеюсь, что вы не имеете в виду одну работу каждые 5 минут на БД .

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

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

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

И в самом деле нет ничего плохого в триггерах, но, как и большинство аспектов T-SQL, очень возможно написать код, который работает ужасно. Я написал статью об общих ловушках триггеров, если это поможет.

Написание хорошо спланированных триггеров