La dernière fois que le serveur SQL a subi une panne ou une perte de données, que s'est-il passé ?

Autre que la classique déclaration de mise à jour/suppression "J'ai oublié d'inclure la clause WHERE et je n'étais pas dans une transaction" ?

Les bases de données d'un serveur sont toujours hors ligne dans notre environnement de laboratoire. Le lecteur sur lequel se trouvaient les fichiers MDB disparaissait, SQL avait un problème et je devais remettre les bases de données en ligne manuellement lorsque le lecteur réapparaissait (généralement quelques minutes plus tard). J'ai passé la majeure partie de la semaine avec les gars des opérations pour essayer de déterminer pourquoi le disque disparaissait. Il s'agissait d'un LUN sur le SAN, avec des chemins redondants vers le commutateur.

Pour faire court, il s'est avéré que les câbles de fibre n'étaient pas complètement encliquetés dans leurs ports sur le commutateur, et que les câbles avaient été déplacés lors d'une maintenance récente. Ils se trouvaient maintenant dans la cavité entre la porte du rack et la cavité dans laquelle elle se ferme. Lorsque la porte s'est fermée, elle a tiré sur les câbles juste assez pour que les fiches sortent et rompent la connexion. La porte n'était pas verrouillée, elle oscillait librement, et lorsque la porte du laboratoire était ouverte/fermée, le mouvement de l'air faisait osciller la porte du rack d'avant en arrière.

Dans une petite entreprise où je travaillais, nous venions de mettre en place un site Sharepoint de base. Nous étions petits, mais nos employés étaient répartis dans le monde entier, de sorte que l'accès au Web et l'intégration de MS Office pour Sharepoint étaient extraordinaires (tout le reste était nul, mais c'est une autre histoire). Comme nous n'avions pas beaucoup d'argent et que nous étions petits, nous avons gardé les choses simples, un serveur SQL avec RAID et un serveur Web également avec RAID. Après environ une semaine et 5 gigas de données de projet, l'alimentation électrique du serveur SQL est tombée en panne. Nous avons eu une journée d'interruption de service en attendant la livraison de la nouvelle alimentation. Nous aurions pu transférer les sauvegardes sur un autre serveur, mais comme nous étions encore novices dans le domaine de Sharepoint, le plan de secours était encore en cours d'élaboration et nous nous sommes dit que cela prendrait autant de temps de tout comprendre que d'attendre l'arrivée de l'alimentation électrique, et comme nous savions que dès que nous aurions une nouvelle alimentation électrique, nous serions en ligne et n'aurions pas à faire de retour en arrière, nous avons simplement choisi d'attendre et de ne pas risquer de mettre en péril Sharepoint.

Une erreur humaine a entraîné la suppression de tous les index d'une base de données MS-SQL de deux téraoctets. Ils s'en sont aperçus assez rapidement et ont décidé de reconstruire les index. Malheureusement, ce processus a pris plus de 48 heures. En rétrospective, il aurait été plus facile (et aurait causé beaucoup moins de temps d'arrêt) de restaurer à partir d'une bande.

Il y a quelques années, alors que je travaillais pour une société de financement automobile, j'ai fait tomber un serveur de base de données lors d'un déploiement. C'est l'une des plus grandes erreurs que j'ai commises dans ma vie professionnelle, bien que je sois sorti indemne de ce problème.

Nous avions une réplication transactionnelle unidirectionnelle de SQL 2K (SP3) à SQL 2K (SP3) et pendant les déploiements, la réplication devait être démantelée et reconstruite selon la politique de l'entreprise si elle impliquait une ou plusieurs tables dans la réplication. À un moment donné, il a été décidé de passer à SP4 et les changements ont été appliqués à tous les serveurs de production, mais la réplication n'a pas été reconstruite après la mise à niveau.

Quelques semaines plus tard, mon projet (j'étais un développeur de base de données et un entrepreneur) devait être déployé et je me trouvais au centre de données pour assister le déploiement (les déploiements sont généralement effectués à minuit). La réplication a été interrompue, le déploiement du projet s'est déroulé avec succès et pendant la reconstruction, la réplication a échoué après 2 heures. La personne chargée du SCM l'a relancée sans lire le message d'erreur complet à 3 heures du matin et elle a de nouveau échoué au bout de 2 heures, alors que nous approchons du SLA. Je savais que je devais appeler mon responsable à 5 heures du matin et de nombreux appels ont été passés pour faire remonter le problème à tous les niveaux/groupes.

Le groupe DBA a pris en charge le problème à 6 heures du matin et j'ai été tenu dans l'ignorance des étapes de dépannage et mon responsable m'a demandé 3 fois en 2 heures de vérifier si mes scripts sont responsables de l'erreur. Ma tête était sur la ligne. 4 Prod DBA's et 2 managers étaient chauds sur ce problème & un Ticket a été soulevé avec MSFT, et même après 15h le problème n'a PAS été résolu jusqu'à ce que je comprenne ce qui s'est réellement passé. Dans un article (table), nous avions un index unique sur une colonne mais la qualité des données n'était pas bonne. Nous avions '' et une valeur nulle et les millions d'enregistrements restants étaient des valeurs légitimes bien que certaines données anciennes étaient douteuses. Après la mise à jour SP4, SQL Server a essayé de transformer les valeurs '' et null en null du côté de l'abonné et cela a échoué à cause de la violation de la clé unique/de l'index. Les mauvaises données ont été supprimées après avoir obtenu des autorisations de haut niveau de la part du groupe d'affaires et j'ai pu conserver mon emploi pendant une année supplémentaire.

Leçon apprise : Testez, testez et testez chaque programme que vous avez avant de passer à une mise à niveau.