Je participais à un fil de discussion récent sur la communauté OTN où quelqu'un posait des questions sur la rétrogradation après une mise à niveau de la base de données. L'une des réponses demandait combien de personnes pratiquaient réellement les rétrogradations de bases de données. J'ai créé ce sondage pour le savoir.
J'ai été surpris de trouver une contribution à ce fil qui disait :
Maintenant, cette affiche ne le disait pas explicitement, mais c'était presque comme si cette personne disait que la pratique des rétrogradations était une perte de temps parce qu'elle n'en aurait jamais besoin. Je vais donner à l'affiche le bénéfice du doute et que cet employé d'Oracle ne disait pas vraiment cela. Je n'essaie pas de m'en prendre à cet individu. Je vais laisser ce fil me donner l'occasion de discuter du sujet d'un point de vue plus générique. (Mise à jour : l'auteur qui m'a incité à écrire cette entrée de blog est revenu sur le fil de discussion pendant le temps qu'il m'a fallu pour écrire ceci et a dit : " ne voulait pas dire que nous ne devrions pas "tester" les rétrogradations." )
En juillet, j'ai écrit un article de blog sur The Data Guardian. Dans ce billet de blog, j'ai dit :
Le DBA doit protéger les données. C'est le travail n°1. Le travail #2 consiste pour le DBA à fournir un accès efficace et opportun aux données. À quoi bon disposer des données si les personnes qui en ont besoin ne peuvent pas accéder aux données ? Si ces personnes ont des performances médiocres lorsqu'elles interagissent avec les données, elles pourraient tout aussi bien ne pas y avoir accès.
En tant que DBA, nous devons effectuer une gestion des risques. Nous devons déterminer quels risques pourraient devenir réalité. Le travail du DBA consiste à mesurer ces risques et à déterminer deux plans d'action. Quelles mesures puis-je prendre pour éviter que ce risque ne devienne réalité et quelles mesures dois-je prendre pour résoudre le problème lorsque ce risque devient réalité ?
Même un DBA de niveau junior comprendra l'importance des sauvegardes. Les sauvegardes sont une stratégie de gestion des risques. Si des données sont perdues, nous pouvons récupérer les données de la sauvegarde. Et même un DBA de niveau junior comprend l'importance de pouvoir restaurer à partir de la sauvegarde.
Dans ce fil OTN, j'ai écrit ceci :
Pour moi, c'est une sorte de loi de Murphy. J'ai dit des choses similaires dans le passé. L'idée (et c'est tout l'intérêt de cette entrée de blog) est que si je ne prends pas les mesures appropriées de gestion des risques, je demande simplement aux dieux de transformer ce risque en réalité. Si je refuse de régler mon rétroviseur et de l'utiliser lorsque je recule mon véhicule, eh bien c'est le jour où je reviens à quelque chose. Si je refuse d'attacher mes lacets, eh bien c'est le jour où je marche dessus et je trébuche. Le jour où je refuse de porter des lunettes de protection lors de l'utilisation d'un outil électrique, c'est le jour où j'ai quelque chose dans l'œil. Le jour où je vais à la plage et refuse de mettre de la crème solaire, c'est le jour où je rentrerai avec un coup de soleil. Vous voyez l'idée.
Certains lecteurs peuvent penser que je suis fou et que l'univers n'a pas ce plan directeur pour se foutre de moi simplement parce que je suis complaisant. Et je serais d'accord. Donc je vais le dire autrement, si je ne prévois pas d'atténuer le risque, alors je n'ai rien fait pour l'empêcher de devenir une réalité. Les chances qu'il devienne une réalité ne diminuent pas à cause de mon inaction.
La gestion des risques comporte deux volets principaux. 1) déterminer la probabilité que cet élément de risque se produise et 2) déterminer l'impact lorsque ce risque se produit. Les éléments qui ont la probabilité la plus élevée de se produire sont d'abord atténués. C'est facile et c'est ce que font souvent beaucoup de personnes travaillant sur la gestion des risques. Ils placent les éléments de risque dans une feuille de calcul et remplissent une valeur pour la probabilité que ce risque se produise. Une fois terminés, ils trient sur la colonne de probabilité et commencent l'atténuation des risques de haut en bas. De nombreuses stratégies de gestion des risques tracent une ligne quelque part au milieu de la liste et décident que tout élément de risque en dessous de cette ligne a une probabilité trop faible pour que nous ne nous inquiétions pas de cet élément de risque. Nous ne pouvons pas atténuer tous les risques possibles dans l'univers. Il n'y a tout simplement pas assez de temps pour tout gérer. Nous devons donc tracer la ligne quelque part.
L'un des défauts que je vois tout le temps est que la gestion des risques ne passe pas beaucoup de temps à se concentrer sur l'impact que ce risque devienne réalité. La feuille de calcul doit inclure une colonne similaire fournissant une évaluation de l'impact sur l'entreprise pour cet élément de risque. Le gestionnaire de risques doit également trier la feuille de calcul sur cette colonne. Tout élément qui a un impact important doit faire l'objet d'activités d'atténuation des risques, même si cet élément a une faible probabilité de se produire ! Malheureusement, trop de personnes travaillant dans le domaine de la gestion des risques n'incluent pas cette étape d'évaluation de l'impact des risques. Encore une fois, lorsque la feuille de calcul est triée par impact sur l'entreprise, une ligne est tracée quelque part.
On peut constater que les éléments à risque avec une probabilité ÉLEVÉE avoir un impact FAIBLE voire TRÈS FAIBLE à l'entreprise. J'aime les feuilles de calcul de gestion des risques qui incluent une troisième colonne qui est "probabilité x impact". Cette colonne permet de comprendre la relation entre les deux composants de risque.
Revenons à la question de mise à niveau de la base de données qui a suscité ce billet de blog. Je pense que tous ceux qui lisent cet article de blog devraient convenir que la mise à niveau d'une base de données Oracle est une proposition risquée. Il y a tellement de choses différentes qui pourraient mal tourner avec une mise à niveau de la base de données Oracle. La probabilité d'un échec de mise à niveau est ÉLEVÉ. Les éléments d'atténuation des risques incluent souvent, mais sans s'y limiter, la pratique de la mise à niveau sur des clones de production et la sauvegarde de la base de données avant le début du processus de mise à niveau. Pourquoi faisons-nous cela? Eh bien, l'impact à l'entreprise est TRÈS ÉLEVÉ. Si nous échouons lors de la mise à niveau de notre base de données de production, nos utilisateurs professionnels n'ont pas accès aux données. Nous ne sommes pas un très bon Data Guardian si nous ne pouvons pas surmonter cet échec. Si nous pratiquons suffisamment la mise à niveau dans des environnements hors production, nous pouvons réduire la probabilité de l'élément de risque à MOYEN. Mais selon toute vraisemblance, nous ne pouvons pas réduire cette probabilité de risque spécifique à FAIBLE. C'est pourquoi nous effectuons la sauvegarde avant le début de la mise à niveau. Devrait encore avoir des problèmes même si nous avons fait de notre mieux pour réduire la probabilité de cet élément de risque, l'impact à l'entreprise est encore TRÈS ÉLEVÉ. La stratégie de correction des risques du DBA consiste donc à prendre des notes sur où et ce qui a causé l'échec de la mise à niveau, et à restaurer à partir de la sauvegarde. La base de données est opérationnelle et nous avons éliminé l'impact à l'entreprise. Le DBA retourne ensuite à la planche à dessin pour déterminer comment résoudre ce qui n'a pas fonctionné. Le DBA tente de réduire la probabilité que ce problème se reproduise lorsqu'ils reviennent ultérieurement pour refaire le processus de mise à jour.
Revenons donc au commentaire dans le fil OTN où il semblait dire que la pratique des rétrogradations de base de données ne vaut pas la peine. Je ne suis pas d'accord. Et mon désaccord a tout à voir avec l'impact à l'entreprise. Je suis d'accord avec le commentaire que l'affiche a dit dans sa réponse.
Je suis d'accord avec ça à 100%. Pourquoi faisons-nous ces « tests approfondis » ? Tout cela est dû à l'atténuation des risques. Nous essayons de réduire la probabilité que la mise à niveau entraînera de mauvaises performances ou une interruption des fonctionnalités de l'application. Mais même comme le disait cette affiche, "Il y aura toujours des problèmes qui apparaîtront en production après la mise à niveau car il est impossible de tester 100% de votre application." Encore une fois, je suis d'accord à 100% avec ce que dit cette affiche ici. Mais qu'en est-il de l'impact à l'entreprise ? J'y reviendrai dans une minute, mais je dois d'abord faire une petite digression dans ce paragraphe suivant…
J'ai récemment mis à niveau un système de production critique de la version 11.2.0.4 à la version 12.1.0.2. Là où je travaille, nous avons plus de tests d'application que je n'en ai jamais vu dans mes autres emplois. Nous avons une équipe d'assurance qualité complète qui effectue les tests pour nous. Nous avons même une équipe qui est en charge de nos efforts de tests automatisés. Nous avons des robots automatisés qui exercent notre code d'application la nuit. En plus de tout cela, nous avons une autre routine automatisée qui, chaque fois que les gens poussent les modifications de code vers Test ou Prod, effectue un examen rapide des chemins de code critiques. J'ai mis à niveau les environnements de développement (plus de 15 d'entre eux) vers 12.1.0.2, puis j'ai attendu un mois. J'ai ensuite mis à niveau Test et attendu 3 semaines avant de mettre à niveau la production. Des problèmes ont été détectés et résolus avant la mise à niveau de la production. Mais même après tout cela, j'ai eu de gros problèmes une fois la production mise à niveau. Vous pouvez visiter mes articles de blog de la mi-octobre à la mi-décembre pour voir certains de ces problèmes. J'étais sur le point de rétrograder cette base de données, mais j'ai réussi à résoudre les problèmes à la place. Revenons maintenant au point que je faisais…
Une fois la mise à niveau terminée, la base de données est ouverte aux entreprises. Les utilisateurs de l'application sont désormais autorisés à utiliser l'application. Que se passe-t-il dans la base de données à ce stade ? Transactions! Et les transactions signifient des changements de données. Au moment où le DBA ouvre la base de données pour les entreprises après la fin d'une mise à niveau, les modifications de données commencent à se produire. Après tout cela, c'est tout l'intérêt de la base de données, n'est-ce pas ? Capturez les modifications de données et mettez les données à la disposition des utilisateurs finaux de l'application.
Alors que se passe-t-il si vous êtes dans le bateau où j'étais l'automne dernier avec la mise à jour de ma base de données ? Je frappais des choses que nous n'avions pas vues en non-production, même après tous nos tests. L'impact à l'entreprise était ÉLEVÉ. Je dois être en mesure de réduire cet impact sur l'entreprise. J'avais trois options. 1) Corrigez les problèmes, un par un. 2) Restaurer à partir de la sauvegarde que j'ai effectuée avant la mise à niveau afin de pouvoir récupérer la base de données à l'ancienne version. 3) Rétrogradez la base de données et revenez à la planche à dessin. J'ai choisi la première option. comme je l'ai toujours fait au cours de ma carrière. Et si cela ne suffisait pas ? Cela peut prendre du temps pour résoudre les problèmes. Certaines entreprises ne peuvent tout simplement pas se permettre ce genre de temps avec cet impact négatif à l'entreprise. Combien de sites Web ont été abandonnés parce que les performances étaient mauvaises ou que les choses ne fonctionnaient pas correctement ? Et pour la grande majorité des bases de données de production, l'option 2 a un impact très terrible à l'entreprise ! Vous perdrez des transactions une fois la mise à niveau terminée ! L'administrateur de base de données ne pourra pas continuer après la mise à niveau tout en conservant la base de données à l'ancienne version, de sorte que les données seront perdues et pour de nombreuses bases de données de production, cela est inacceptable. L'entreprise peut être en mesure de se permettre une heure de perte de données, mais combien de personnes pourraient appuyer sur la gâchette de cette action dans l'heure suivant la mise à niveau ? Selon toute vraisemblance, cette action serait effectuée quelques jours après la mise à niveau et l'impact à l'entreprise pour ce type de perte de données est bien au-dessus de TRÈS ÉLEVÉ. Cela laisse donc l'option 3 comme l'option avec le plus faible impact à l'entreprise pour l'aider à résoudre tout impact subi par l'entreprise après la mise à niveau.
Vous pouvez probablement dire à partir de ce dernier paragraphe que je pense qu'il est important pour l'administrateur de base de données Oracle de savoir comment rétrograder sa base de données une fois la mise à niveau terminée. Je concéderai que la probabilité du DBA devant effectuer une rétrogradation est TRÈS FAIBLE. Mais l'impact de ne pas déclasser peut être catastrophique pour l'entreprise. (Il y a encore ces deux mots). Parce que la probabilité est faible, je ne pratique pas souvent les rétrogradations, mais parce que l'impact de ne pas pouvoir rétrograder est très élevé, je les pratique de temps en temps.
Donc, en terminant, je vais revenir à nouveau sur cette loi de Murphy. L'univers ne conspire pas contre moi, mais en tant que Data Guardian, je dois appliquer de bons principes de gestion des risques. Cela signifie évaluer la probabilité et l'impact des éléments de risque imposés par mon changement. Bien que l'univers et les dieux ne fassent peut-être pas passer la loi de Murphy ou ses cousins à la vitesse supérieure, je ne me rends pas service en atténuant les éléments à risque. Je ne réduis pas la probabilité d'un bit.
