Une autre journée de migration de bases de données..

Je pense qu’une bonne journée de travail est une journée vraiment plate que j’ai envie d’endormir, donc pas de surprise, pas d’improvisation, pas d’espace à la créativité parce que tout est comme l’on a prévu.

Parfois, nous sommes carrément obligés à migrer de bases de données sans faire tous les tests nécessaires. J’arrive au bureau, et je sens que je ne vais pas avoir une journée plate.

La journée commence bien sans pression d’une journée de migration de bases de données, je suis soulagé puisque je ne suis pas le responsable pour la migration. Bien que j’ai créé les scripts de migration, mais ce n’était pas à moi de tester et de vérifier. On repasse la procédure de migration avec le responsable  la migration (qui n’est pas moi!!). Alors, on exécute encore une fois les scripts, j’ai ajouté un mode test qui fait la copie des bases de données sans rien changer aux bases de données.

Apparemment, tout fonctionne… mais les apparences ne sont que des apparences…

Je sors plus tôt pour être disponible pour le moment de la migration. Jusqu’à ce moment, tout est en conformité avec la planification. Les bases de données sont copiées et restaurées…

Mais…. Je reçois un appel…

Il manque des Stores Procedures.  Je sais selon mon expérience que l’on n’a pas de moitié restauration de base de données, et spécialement avec des anciens codes ou données.

Mon hypothèse d’une explication raisonnable : possiblement, le script n’a pas été exécuté correctement, et il utilise d’anciens fichiers. Alors, je demande l’exécution du script, je vérifie les fichiers qui sont créés. Et… rien.. Il y a encore d’anciens Stores Procedures.  Je suis obligé d’écouté qu’avant il fonctionnait et que à cause de nouveau ajouté au script qu’il ne marche plus. Je vérifie encore  le script, c’est vrai que le script n’a plus l’apparence du premier script, mais cela ne va pas dire qu’il ne fait plus comme avant. Je dois reconnaitre que ma technique de création de scripts est un peu mélangeante, j’ai un script qui crée un script qui crée le script à être exécuté.

Je suis l’exécution du script avec un accès limité de l’écran, mais, apparentement, il n’y a pas de problème. Finalement, j’ai un appel,  la restauration des bases de données a été faite en utilisant  d’anciennes copies des fichiers. Mon hypothèse est validée, alors j’ai une théorie.

Une simple correction de chemin. Oui, ça nous aide quand nous sommes sur le bon chemin. Je suis soulagé, oui, précipitamment, soulagé. Alors, il exécute la procédure avec l’option de migration. Bien sûr, comme l’on l’a prévu! Le script exécute sans problèmes, oui, apparentement sans problèmes. J’attends la nouvelle qu’il est fini.

–

J’ai un message d’un autre problème d’accès à un utilisateur local qui manque de configuration. Alors, je suis déjà connecté donc je profite du temps disponible. Je change la configuration de l’utilisateur, je le mets à jour sur l’environnement de test, et on bascule le serveur de test, et je mets à jour sur l’environnement de production, bien sûr que je ne bascule pas le serveur de la production à 19hs sans avoir un vrai besoin. On doit le planifier!

Bien finit ce problème.

–

J’ai un nouvel appel. Il y a un problème pour établir une connexion vers le serveur. Erreur : " Logon failed for login due to trigger execution.". Ma connexion est toujours bonne.  Ça prend quelques minutes pour réaliser l’origine du problème et après faire quelques vérifications je suis conscient de la problématique. La procédure de migration met hors de service les bases de données après que chaque copie est faite. Cela assure que plus personne n’utilise la base de données sauf quand l’on a besoin de l’utiliser. Un “trigger”, possiblement utilisé avec l’objectif d’audit, qui enregistre les logins  effectués sur le serveur, mais, désormais, la base de données utilisée n’est plus disponible. On a une simple solution : il faut, alors, désactiver ou effacer le “trigger”. J’essaie de me brancher directement sur le serveur qui ne laisse pas connecter. Et, il n’y a pas de licence de connexion disponible. Je vais sur un autre serveur du domaine pour vérifier qui est branché, et quelle surprise, les deux connexions sont occupées par la même personne.

J’exécute un SQL Script en utilisant DAC (Dedicated Administrator Connection). J’efface le “trigger” et le problème est réglé!

Je fais un appel pour le confirmer, hum, je dois aussi désactiver tous les “Jobs”.  Après deux minutes, c’est réglé aussi.

Après une heure, je confirme que mon aide n’est plus nécessaire.

À moi, cette journée est terminée…

Lendemain, j’arrive au bureau, je reçois la nouvelle qu’on est retourné en arrière… tout est pété sauf les bases de données qui ont bien migré. C’est plutôt une bonne nouvelle.