Il fornitore desidera eseguire il processo MSDB ogni 5 minuti per l'applicazione aziendale

Abbiamo un fornitore di terze parti che tenta di integrare 2 diverse applicazioni in cui entrambi i DB risiedono sulla nostra istanza di SQL Server con oltre 150 altri DB e desiderano creare un lavoro MSDB per "sincronizzare" le 2 diverse applicazioni ogni 5 minuti (inizialmente volevo eseguirlo ogni minuto).

Il mio sospetto iniziale è che dovrebbero invece farlo in qualche modo nel livello Applicazione con un processo pianificato di Windows, o forse anche un trigger temuto (che in genere ricorre in situazioni come questa).

Preferisco mantenere i lavori MSDB riservati alle attività DBA il più possibile per ridurre il disordine lì, e ho anche incontrato query lente di MSDB durante la visualizzazione di cronologie di lavori con lavori super attivi come questo (che annegano e abbandonano importanti storie di cose più importanti come le storie di backup). Ma ancora una volta, forse le mie preferenze sono sbagliate e ho bisogno di fare un po 'di spazio per il livello Applicazione in MSDB e rimboccarmi le maniche e risolvere i problemi della cronologia dei lavori che impiegano un'eternità a caricarsi quando devo conservare molte più voci della cronologia per catturare il cose importanti come i backup (o eliminare le voci di lavoro iperattive).

Un altro problema che ho è che ora devo dare a questo fornitore i diritti "sysadmin" anziché solo i diritti "dbo" solo sui loro DB quando eseguono i loro aggiornamenti tramite la loro GUI e spero che non esplodano l'istanza in cui la mia missione è critica I DB sono (uno degli aspetti negativi del consolidamento).

Immagino di poterli mettere su un'altra istanza "isolata" in cui mettiamo tutti i fornitori che non giocano bene, ma quindi abbiamo bisogno di riconfigurare le Applicazioni per puntare alla nuova istanza SQL ( sospiro purtroppo non banale in questo caso).

Il venditore ha già respinto le mie preoccupazioni parlando di quanto siano cattivi i trigger. Quindi, ho "cercato su Google" un po 'su questo e sono venuto a vuoto. Qualcuno ha visto qualche link là fuori "dall'aspetto autorevole" che questa è una cattiva idea e posso farvi riferimento? O dovrei abbracciare il loro approccio?

Non credo di aver mai pubblicato in un forum sql prima di chiedere aiuto, quindi spero che la mia richiesta sia correttamente inquadrata.

EDIT: Stiamo eseguendo SQL Server 2008 Enterprise R2 x64 SP1 (Grazie per aver sottolineato che ho dimenticato di menzionare la versione!). Speriamo che non abbiano bisogno di cambiare i loro script di aggiornamento MSDB quando passiamo a una versione più recente.

Grazie per il tuo tempo! Ricco

IMO il tuo fornitore è effettivamente sulla strada giusta.

Un lavoro a livello di applicazione gli richiederebbe di ripetere molte funzioni SQL Agent predefinite (ad es. Logica per non eseguire un lavoro che è già in esecuzione, elaborare una soluzione di archiviazione di credenziali e sicurezza, integrare i risultati del lavoro con segnalazione errori e tracciamento risultati in SQL etc etc etc etc). E, soprattutto, fornire una soluzione di backup / HA / DC per la pianificazione. Non si desidera che la cronologia del ripristino di emergenza sia "e al termine del ripristino del server di standby, creare queste attività dello scheduler da 50 NT". Quindi ha ragione nel respingere usando lo scheduler di sistema, non ha nulla delle caratteristiche e delle capacità dell'Agente.

È ancora più giusto nel respingere i grilletti. La sostituzione di un lavoro periodico con un trigger sincrono aumenta la latenza della richiesta, aumenta la coesione e l'accoppiamento (si pensi alle modifiche dello schema ...), aumenta il rischio di downtime a causa di problemi di sincronizzazione (errore di trigger-> errore dell'app vs. errore del processo-> correggi e riprova più tardi) , aumenta notevolmente i problemi di deadlock (a causa di aggiornamenti incrociati tra tracked / trackee) e presenta molti altri problemi.

La soluzione più semplice è davvero un lavoro di agente e non msdbè assolutamente riservato ai DBA. Una soluzione più fantasiosa sarebbe quella di utilizzare i timer di conversazione e l'attivazione interna , il che avrebbe alcuni vantaggi rispetto ai lavori dell'agente, principalmente a causa del contenimento (tutto è all'interno del database dell'app, penso agli scenari di failover del mirroring), ma posso capire totalmente se il tuo fornitore è riluttanti a provare qualcosa che richiede un know-how molto specifico. A proposito, spero che non intendi un lavoro ogni 5 minuti per DB .

Per quanto riguarda le autorizzazioni sysadmin: il nome del gioco è la firma del codice . Puoi dare qualsiasi autorizzazione a procedure specifiche, ispezionate e validate da te, firmandole con il tuo certificato privato.

La mia preferenza personale sarebbe quella di utilizzare i trigger per gestire almeno una parte della sincronizzazione. Non mi interessa particolarmente la sincronizzazione pianificata del polling, poiché devi affrontare potenziali conflitti, dati non aggiornati, impatto sulle prestazioni del lavoro ripetuto, ecc. Se vogliono farlo in modo aggressivo da 1 a 5 minuti, suppongo serve a mitigare i conflitti e la stanchezza, e l'immediatezza di un trigger lo affronterebbe.

Se succede tutto all'interno dello stesso server, probabilmente stai bene inserendo il codice di sincronizzazione nei trigger o facendo in modo che i trigger chiamino una procedura memorizzata che sincronizza ogni record interessato. Se la sincronizzazione si estende su server o vuoi assicurarti che avere un database offline non impedisca l'utilizzo dell'altro database, cerca di utilizzare Service Broker per gestire gli aggiornamenti asincroni. Ho fatto questo per sincronizzare le cifre delle voci di vendita con i dati CRM tra due server diversi, consentendo nel contempo che entrambi i server fossero messi offline senza influire sull'altra applicazione. Una volta eseguito il backup, Service Broker recapita i messaggi e aggiorna i dati sul server remoto.

E non c'è davvero nulla di intrinsecamente negativo nei trigger, ma come la maggior parte degli aspetti di T-SQL, è molto possibile scrivere codice che funzioni in modo orribile. Ho scritto un articolo sulle insidie ​​comuni dei trigger, se questo aiuta.

Scrivere trigger ben educati