La Haute Disponibilité et les environnements Oracle – partie 3

Dans la deuxième partie de notre dossier La Haute Disponibilité et les environnements Oracle, nous avons examiné  l’Importance de la Disponibilité et les Coûts des arrêts de Production.

Voici la troisième partie de ce dossier dans laquelle nous examinerons les causes d’arrêts de Production.

Article précédent : La Haute Disponibilité et les environnements Oracle – partie 2 : Importance de la Disponibilité et les Coûts des arrêts de Production.

Arrêts planifiés et non-planifiés

Un des défis dans la conception d’une solution de haute disponibilité consiste à examiner et à traiter toutes les causes possibles des arrêts de Production. Il est important d’examiner à la fois les arrêts planifiés et non-planifiés. Les arrêts de Production planifiés peuvent être aussi perturbateurs que les arrêts non-planifiés, en particulier dans le cas des entreprises internationales qui ont des utilisateurs répartis dans le monde entier.

Causes d'arrêts non-planifiés

1. Défaillance du site : elle risque d’affecter l’ensemble des traitements d’un centre de données, ou un sous-ensemble des applications prises en charge dans ce centre de données...
   
   • Panne de courant sur tout le site
   • Cataclysme naturel rendant le site informatique hors service
   • Attaque terroriste ou malicieuse contre les applications ou contre le site
     .
2. Défaillance du Cluster : l’ensemble du Cluster hébergeant une base Oracle RAC est non disponible ou en panne.
   
   • Le dernier nœud survivant d’un cluster Oracle RAC s’arrête et il est impossible de le redémarrer
   • Les deux connexions redondantes INTERCONNECT sont inutilisables ou l’ensemble du Cluster est inutilisable
   • Une corruption de la base de données est si grave que la continuité n’est pas possible sur le serveur Oracle actuel
   • Erreur d’accès aux disques
     .
3. Défaillance de l’ordinateur : lorsque le système exécutant la base de données devient indisponible parce qu’il est en panne ou non accessible.
   
   • Défaillance matérielle du serveur de base de données
   • Défaillance du système d’exploitation
   • Défaillance de l’instance Oracle
   • Défaillance de l’interface réseau
     .
4. Défaillance du stockage de données : lorsque les éléments de stockage de tout ou partie de la base ne sont plus accessibles.
   
   • Panne de disque
   • Panne de contrôleur disque
   • Panne de Baie SAN
     .
5. Corruption de données : un bloc corrompu est un bloc altéré de telle sorte qu’il est différent de ce qu’Oracle s’attend à trouver.
   .
   Il existe des corruptions logiques et physiques. On peut aussi parler de corruption intra-blocs et inter-blocs.
   .
   Une défaillance due à la corruption de données se produit quand un matériel, un logiciel, ou un composant réseau provoque la corruption de données en lecture ou en écriture. L’impact sur le niveau de service suite à une corruption de données peut varier, avec un faible impact éventuellement dans le cas d’un ou plusieurs blocs corrompus dans la base ou un blocage de la base dans le cas de corruptions plus importantes.
   .
   Voici quelques éléments pouvant conduire à une corruption :

    

   • Défaut sur le système d’exploitation ou le driver disque
   • Adaptateur de bus défectueux
   • Défaut d’un contrôleur disque
   • Erreur de gestionnaire de volume disque provoquant une erreur de lecture ou d’écriture disque
   • Défaut logiciel
     .
6. Erreur humaine : un utilisateur a involontairement modifié ou supprimé des données dans une base ou quelqu’un a commis des modifications délictueuses; suivant le type d’erreur les conséquences seront plus ou moins graves.
   
   • Suppression de fichiers de données appartenant à une base
   • Suppression d’objets dans une base (tables, etc…)
   • Modification involontaire de données
   • Changement de données frauduleux
     .
7. Ecritures manquantes : une écriture manquante est une autre forme de corruption des données, mais il est beaucoup plus difficile de la détecter et de la réparer rapidement. Un bloc de données égaré ou manquant se produit lorsque :
   
   • Dans le cas d’une écriture manquante (lost write), le sous-système I/O a validé l’écriture d’un bloc alors qu’il n’a pas été écrit sur disque; par suite, la prochaine lecture de ce bloc retournera une version ancienne de celui-ci, causant une cascade d’erreur dans les traitements et dans la base
   • Dans le cas d’une écriture égarée (stray write), l’écriture est effectuée, mais à un emplacement incorrect; par suite, la prochaine lecture de ce bloc retournera une version ancienne de celui-ci, causant une cascade d’erreur dans les traitements et dans la base
   • Dans le cas d’une base Oracle RAC, la lecture d’un bloc sur un nœud retourne des données périmées lorsqu’un autre nœud vient d’écrire ce bloc sur disque (lost write). Ceci peut se produire lorsque NFS est utilisé sans l’option “noac”.
     .
8. Blocage ou ralentissement : Un blocage ou un ralentissement se produit lorsque la base de données ou l’application n’est pas en mesure de traiter les transactions en raison d’un conflit de ressources ou d’un verrou. La perception d’un blocage peut être causée par un manque de ressources système.
   
   • Deadlocks de l’application ou de la base
   • Processus “hors contrôles” qui consomment des ressources systèmes
   • “Tempête” massive de connexions ou erreurs systèmes
   • Situation de pics de charge des applications avec un manque de ressources système ou base de données
   • Manque de place sur la destination des fichiers ARCHIVE LOGS ou l’espace FRA (Flash Recovery Area)

Causes d'arrêts planifiés

1. Mise à jour du logiciel système ou Base de Données : un arrêt planifié est soit périodique (pour des tâches de maintenance), soit occasionnel (pour des tâches d’évolution des logiciels système ou bases de données ou des infrastructures). La durée de l’arrêt dépend de nombreux facteurs. Voici quelques exemples :
   
   • Ajouter ou enlever un processeur sur un serveur SMP
   • Ajouter ou enlever des nœuds à un Cluster
   • Ajouter ou enlever des disques ou des baies SANs
   • Modifier des paramètres de configuration
   • Mettre à jour ou patcher le serveur ou le système d’exploitation
   • Mettre à jour ou patcher le logiciel Oracle
   • Mettre à jour ou patcher le logiciel de l’application
   • Migrer la plate-forme matérielle utilisée
   • Déplacer la base
   • Passer de 32 à 64 bits
   • Passer à une architecture Cluster
   • Migrer vers un nouveau stockage
     .
2. Modification sur les données : C’est le cas lors des changements de structure logique ou de l’organisation physique des objets de base de données Oracle. Ces changements ont souvent pour but d’améliorer les performances ou la maniabilité. Voici quelques exemples :
   
   • Modification sur la définition des tables
   • Mise en œuvre du partitionnement de tables
   • Création ou reconstruction d’index
     .
3. Changements sur les applications : Ces changements sur les applications peuvent inclure d’une part des changements sur les données et le schéma de la base et d’autre part des changements sur les programmes.

Oracle propose différentes solutions pour éviter tant les arrêts planifiés que les arrêts non planifiés et pour pouvoir faire face aux différentes défaillances possibles. Ces solutions seront développées dans des articles futurs.

A suivre : mise en œuvre d’Oracle Maximum Availibility Architecture (MAA).