Go to Top

Encore une table supprimée ? Administrateur de bases de données SQL à la rescousse !

Administrateur de bases de données SQL

Toute personne qui occupe un poste informatique a deux sortes de journées de travail. Il y a les bons jours, c’est-à-dire ceux où personne ne les ennuie et où ils peuvent travailler sur les initiatives d’entreprise stratégiques qui leur ont été confiées pour améliorer le fonctionnement de leur entreprise. Et il y a les mauvais jours, qui sont ponctués de nombreuses interruptions sous la forme de « tickets » ou de demandes de la part du département juridique, en charge du développement ou autre qui a besoin de vos lumières en urgence pour être de nouveau opérationnel. Tout bon administrateur de bases de données a bien plus de mauvais jours que de bons, parce que les restaurations de tables et lignes SQL se produisent toutes les semaines, si ce n’est tous les jours.

Pourquoi en est-il ainsi ? Les raisons sont innombrables… L’équipe des finances a commencé à utiliser la mauvaise devise ou le mauvais taux de conversion sur un rapport à un certain moment et a besoin de le faire corriger. Un développeur a supprimé une table. Pendant une mise à jour de routine du système d’entreprise, un administrateur a supprimé des lignes dont il pensait qu’elles n’étaient pas importantes. Or, il s’avère qu’elles étaient utilisées par de nombreuses autres tables, ce qui a entraîné la défaillance du système. La liste est longue.

Dès qu’un problème est identifié, on vous appelle pour le résoudre. Je parie que votre approche est plus ou moins la suivante… D’abord, vous déterminez à quel moment les données étaient correctes. Ensuite, vous trouvez une sauvegarde qui contient la base de données avec la ou les tables contenant les « bonnes » données. La base de données complète devra être restaurée. Ce processus nécessite de trouver un serveur SQL et un espace de stockage suffisant. La restauration d’une base de données peut prendre plusieurs minutes, mais vous savez très bien qu’il faut souvent une ou plusieurs heures, suivant la taille de la base de données. Le processus nécessite une surveillance fréquente et votre coût horaire est élevé !

Une fois que la base de données est restaurée, vous l’examinez pour déterminer si la table souhaitée est présente. Si ce n’est pas le cas, vous continuez de restaurer des bases de données jusqu’à ce que vous trouviez la table, pas vrai ? Une fois que vous avez trouvé la table voulue, vous la copiez dans l’environnement de production à l’aide de scripts. De plus, si c’est une application cruciale pour le chiffre d’affaires qui est à l’arrêt, vous devez procéder à toutes ces étapes en ayant le DSI derrière vous en train de regarder par-dessus votre épaule…

Laisser un commentaire