Vedo spesso "problemi" che implicano i requisiti per SQL Server per eseguire "lavori sporchi" come:
- Nel mio trigger devo copiare un file nella/dalla rete
- La mia procedura memorizzata ha bisogno di FTP un file
- Al termine del backup, ho bisogno di SQL Server per comprimerlo, crearne una copia e quindi archiviarlo
- Quando viene aggiunto un cliente, voglio creare un nuovo database e fare un sacco di cose in Active Directory
- Il mio processo di SQL Server Agent deve eseguire la scansione di una directory alla ricerca di file ed eseguire inserimenti in blocco quando ne trova di nuovi
Questa non è una lista esaustiva; Probabilmente potrei riempire una pagina. Il punto è che l'esecuzione di queste attività dall'interno di SQL Server presenta ostacoli significativi:
Sicurezza
In genere, per tutto ciò in cui ritieni che SQL Server necessiti di un file system o di un altro accesso a livello di sistema operativo, devi (a) concedere espliciti diritti di carta bianca all'account del servizio SQL Server (e/o agli account SQL Agent/proxy), oppure (b) impostare semplicemente gli account di servizio di SQL Server in modo che vengano eseguiti come account di dominio esistenti che dispongono già di tutti questi diritti. Questa è la soluzione "facile":ora, invece di concedere individualmente l'accesso a questa cartella e quella condivisione e quest'altra risorsa, ti pulisci le mani perché sono già amministratori di dominio. Quindi abiliti le impostazioni a livello di server che sono disabilitate per impostazione predefinita ma ti impediscono di eseguire una o più delle attività di cui sopra (ad es. xp_cmdshell ).
Non credo di dover spiegare il livello di esposizione che queste azioni possono rappresentare. O che tipo di problemi possono verificarsi se si tratta di un account di un dipendente reale e quel dipendente se ne va o determina di essere scontento prima che se ne vada. Yikes. Ho visto diversi casi in cui viene utilizzato un account comune per tutti i server SQL. Indovina cosa succede se/quando è necessario modificare la password per un account di dominio che viene utilizzato attivamente da decine o centinaia di istanze di SQL Server? Non importa quanto spesso accadrà se non escludi quell'utente dai criteri di reimpostazione della password?
Prestazioni
Oltre ai problemi di sicurezza, l'uscita dal server di database può introdurre ritardi mentre SQL Server si basa su alcuni processi esterni su cui non ha alcun controllo. La transazione del database deve davvero attendere la compressione e la copia di un file, il completamento di un trasferimento FTP o la risposta del controller di dominio di backup? In che modo questo si aggrava quando diversi utenti svolgono attività simili, tutti in competizione per la stessa larghezza di banda e/o testine del disco? Inoltre devi considerare che una volta che SQL Server ha detto a un file batch di fare qualcosa, viene eseguito il rollback della transazione contenente, non puoi ripristinare l'azione esterna.
La risposta
Bene, di solito, e ci sono sempre delle eccezioni, la risposta è usare processi esterni per queste attività che sono davvero esterne a SQL Server. Usa PowerShell, usa C#, usa file batch; diamine, usa VBScript. Pensa a quali di queste attività devono davvero essere gestite *immediatamente* e mentre la transazione è ancora attiva, sospetto non molte. Costruisci una tabella di coda per questi e scrivi nella tabella di coda all'interno della transazione (che verrà ripristinata se la transazione non va a buon fine). Quindi, disporre di un'attività o di uno script in background che utilizzi le righe della tabella della coda, esegua le attività associate ed elimini o contrassegna ogni riga come completata. Bonus aggiuntivo:SQL Server Agent non è richiesto qui, quindi puoi utilizzare qualsiasi utilità di pianificazione aziendale e la metodologia funziona ancora con SQL Server Express.
