Je vois souvent des "problèmes" qui impliquent des exigences pour que SQL Server effectue un "sale boulot" comme :
- Dans mon déclencheur, je dois copier un fichier vers/depuis le réseau
- Ma procédure stockée doit transférer un fichier par FTP
- Une fois la sauvegarde terminée, j'ai besoin de SQL Server pour la compresser, en faire une copie, puis l'archiver
- Lorsqu'un client est ajouté, je souhaite créer une nouvelle base de données et faire un tas de choses dans Active Directory
- Mon travail de l'Agent SQL Server doit analyser un répertoire à la recherche de fichiers et effectuer des insertions en bloc lorsqu'il en trouve de nouveaux
Ce n'est pas une liste exhaustive; Je pourrais probablement remplir une page. Le fait est que l'exécution de ces tâches depuis SQL Server présente des obstacles importants :
Sécurité
En règle générale, pour tout ce pour quoi vous estimez que SQL Server a besoin d'un système de fichiers ou d'un autre accès au niveau du système d'exploitation, vous allez soit (a) donner des droits explicites de carte blanche au compte de service SQL Server (et/ou aux comptes SQL Agent / proxy), ou (b) configurez simplement les comptes de service SQL Server pour qu'ils s'exécutent en tant que compte de domaine existant disposant déjà de tous ces droits. C'est la solution "facile" - maintenant, au lieu d'accorder individuellement l'accès à ce dossier et à ce partage et à cette autre ressource, vous vous essuyez simplement les mains car ils sont déjà des administrateurs de domaine. Ensuite, vous activez les paramètres au niveau du serveur qui sont désactivés par défaut mais qui vous empêchent d'accomplir une ou plusieurs des tâches ci-dessus (par exemple, xp_cmdshell ).
Je ne pense pas avoir à expliquer le niveau d'exposition que ces actions peuvent représenter. Ou quel genre de problèmes peuvent survenir s'il s'agit d'un compte d'employé réel et que cet employé s'en va - ou détermine qu'il est mécontent avant de partir. Ouais. J'ai vu plusieurs cas où un compte commun est utilisé pour tous les serveurs SQL. Devinez ce qui se passe si/quand vous devez changer le mot de passe d'un compte de domaine qui est activement utilisé par des dizaines ou des centaines d'instances SQL Server ? Peu importe combien de fois cela se produira si vous n'excluez pas cet utilisateur des politiques de réinitialisation de mot de passe ?
Performances
En plus des problèmes de sécurité, sortir du serveur de base de données peut entraîner des retards alors que SQL Server s'appuie sur un processus externe sur lequel il n'a aucun contrôle. La transaction de base de données doit-elle vraiment attendre qu'un fichier soit compressé et copié, ou qu'un transfert FTP soit terminé, ou que votre contrôleur de domaine secondaire réponde ? Comment cela se complique-t-il lorsque plusieurs utilisateurs effectuent des tâches similaires, tous en concurrence pour la même bande passante et/ou les mêmes têtes de disque ? Vous devez également considérer qu'une fois que SQL Server a demandé à un fichier de commandes de faire quelque chose, la transaction contenante est annulée, vous ne pouvez pas annuler l'action externe.
La réponse
Eh bien, généralement - et il y a toujours des exceptions - la réponse est d'utiliser des processus externes pour ces tâches qui sont vraiment externes à SQL Server. Utilisez PowerShell, utilisez C #, utilisez des fichiers de commandes ; diable, utilisez VBScript. Pensez à laquelle de ces tâches doit vraiment être traitée *immédiatement* et pendant que la transaction est toujours active - je suppose qu'il n'y en a pas beaucoup. Construisez une table de file d'attente pour ceux-ci et écrivez dans la table de file d'attente à l'intérieur de la transaction (qui sera annulée si la transaction échoue). Ensuite, ayez une tâche ou un script d'arrière-plan qui consomme des lignes de la table de file d'attente, exécute la ou les tâches associées et supprime ou marque chaque ligne comme terminée. Bonus supplémentaire :l'agent SQL Server n'est pas requis ici, vous pouvez donc utiliser n'importe quel planificateur d'entreprise, et la méthodologie fonctionne toujours avec SQL Server Express.
