Постачальник хоче виконувати завдання MSDB кожні 5 хвилин для ділового застосування

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

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

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

Ще одне питання, що я маю те, що тепер мені потрібно надати цьому постачальникові права "sysadmin", а не лише права на "dbo" лише на їхні БД, коли вони здійснюють оновлення через свій графічний інтерфейс, і сподіваюся, що вони не підірвуть примірник, коли моя місія критична БД є (один із мінусів консолідації).

Я думаю, що я можу поставити їх на інший "ізольований" екземпляр, де ми розміщуємо всіх постачальників, які не грають добре, але тоді нам потрібно переналаштувати Програми, щоб вказати на новий екземпляр SQL ( зітхання, на жаль, не банальне в цьому випадку).

Постачальник вже відштовхувався від моїх занепокоєнь, розповідаючи про те, як погані тригери. Отже, я трохи "погуглився" на цьому і підійшов порожнім. Хтось бачив якесь там посилання "авторитетно дивлячись", що це погана ідея, і я можу посилатись на них? Або я повинен прийняти їхній підхід?

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

EDIT: У нас працює SQL Server 2008 Enterprise R2 x64 SP1 (Дякую, що вказали, що я забув згадати версію!). Хм, сподіваємось, їм не потрібно змінювати свої сценарії оновлення MSDB, коли ми переходимо до нової версії.

Дякую за ваш час! Багатий

IMO ваш постачальник фактично на правильному шляху.

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

Він тим більше правий у відштовхуванні від курок. Заміна періодичного завдання синхронним тригером збільшує затримку запиту, збільшує згуртованість та з'єднання (думає, що зміни схеми ...), збільшує ризик простою через проблеми синхронізації (помилка запуску -> помилка додатка проти помилки завдання-> виправити та повторити спробу пізніше) , різко збільшує проблеми з тупиком (через перехресні оновлення між відстеженими / відстежуваними) та має ще багато інших проблем.

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

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

Моє особисте перевагу було б використовувати тригери для обробки принаймні деякої частини синхронізації. Мене особливо не хвилює планова синхронізація опитування, оскільки вам доведеться мати справу з потенційними конфліктами, несвіжими даними, впливом на виконання повторюваної роботи тощо. Якщо вони хочуть робити це так агресивно, як від 1 до 5 хвилин, я здогадуюсь це пом'якшити конфлікти та несвіжість, і безпосередність спрацьовування буде вирішувати це.

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

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

Написання справних тригерів