Comment exécuter la trace du profileur SQL lorsqu'un problème doit être détecté de 3h00 à 3h30 du matin? Cela peut être fait à l'aide d'une trace côté serveur, mais cela est extrêmement gênant. Ce n'est pas difficile, mais inconfortable et toujours paresseux. Enfin, j'ai décidé d'automatiser cela une fois pour toutes. Comme ça:
Au fait, Jenkins ici est complètement optionnel et ne sert que d'interface pour appeler un script avec les paramètres nécessaires:
Je vais montrer la solution à grands traits, de toute façon il y a beaucoup de spécificités liées spécifiquement à notre infrastructure. Autrement dit, je ferai ce qui est montré à gauche:
Ainsi, le fichier bat fait quelque chose et transfère déjà l'action au script PowerShell auquel il transmet tous les paramètres et deux autres variables - '% BUILD_USER_ID%', '% BUILD_USER_EMAIL%' - reçues de Jenkins. Ils nous seront utiles ultérieurement:
Curieusement, il se passe peu de choses vraiment très utiles dans la ps1 elle-même: une certaine procédure y est appelée, qui crée et renvoie le nom du répertoire sur un partage spécial par le nom du serveur où ce fichier sera placé. Le serveur sur lequel ce répertoire sera créé dépend du centre de données où se trouve le serveur sur lequel la trace sera lancée. De plus, l'utilisateur a le droit de lire la trace et il existe un processus qui nettoie ces répertoires en quelques jours. Comme vous pouvez le voir, vous n'en aurez peut-être pas besoin et vous pouvez ignorer tout cela en toute sécurité.
Maintenant, l'action est déjà transférée sur le serveur où la trace sera lancée, dans le fichier SQL. loc est juste un paramètre contenant le chemin où la trace finie sera copiée. Vous pouvez le remplacer par une constante.
Nous devons d'abord trouver un endroit où nous allons écrire le fichier de trace localement. Par exemple, comme ceci:
Ensuite, un peu de nettoyage. Soudain, un tel fichier existe déjà, ou quelqu'un a-t-il exécuté la trace plus tôt? Vous devrez quitter sys.traces et arrêter / supprimer l'écriture de trace dans% jenkinsTraceSch%, s'il en existe déjà. Ensuite, créez une trace (limitez sa taille!) Et un peu d'ennui avec les appels sp_trace_setevent. Vous pouvez vous faciliter la vie en faisant CROSS JOIN entre les événements et les colonnes:
Maintenant, ajoutez des filtres au goût. Ici, vous venez de terminer votre hibou. C'est le premier endroit où nous utilisons des paramètres de script - type de filtre et nom de la base de données:
Maintenant, le thrash est allé:
Dans @j, vous formez une commande pour Job, qui sera:
- Attendez le bon moment avec WAITFOR
- Courez la piste
- Attendez l'heure commandée
- Arrêtez la course
- Attendez une seconde au cas où - opérations asynchrones
- Former une équipe pour copier la trace au bon endroit
- Réalisez-la
- Formulaire Objet et lettres de corps
- Envoyer une lettre au client via sp_send_dbmail avec un lien vers la trace
Nous devons maintenant créer Job avec l'étape 1 décrite dans @j. Cependant, j'ajoute encore le suicide à ce Job pour que Joba disparaisse sans laisser de trace à la fin du travail:
Ici, j'entends des cris à propos de xp_cmdshell ... Je ne veux pas faire de commentaire à ce sujet. En fin de compte, personne ne devrait témoigner contre lui-même devant le tribunal. Mais vous pouvez faire autrement. Il est peu probable que vous puissiez envoyer la trace par courrier - c'est gros. Bien que vous puissiez l'emballer. Eh bien, laissez-le sur le serveur lui-même et laissez l'utilisateur le récupérer lui-même ou tirez-le via UNC à un endroit accessible à l'utilisateur
Vous avez donc:
- Jenkins appelle la chauve-souris
- chauve-souris appelle PowerShell
- PowerShell appelle le script SQL via sqlcmd
- Le script crée Job
- Job crée une trace et envoie du courrier avant le suicide:
Je n'aurais jamais pensé qu'une aussi longue chaîne fonctionnerait. Mais ça marche ...
PS: Et oui, même si xp_cmdshell est interdit et que vous ne pouvez pas l'activer, vous avez au moins 2 façons d'écrire my_xp_cmdshell. Cette "protection" ne protège donc contre rien.