[WEBINAR💻] NIS 2 en action : Stratégies et solutions pour une cyber-résilience renforcée ! Le replay est disponible dès maintenant🎙!

✖︎
Digora blog

La Haute Disponibilité et les environnements Oracle – partie 5

25/06/2011
Données

Dans la quatrième partie de notre dossier La Haute Disponibilité et les environnements Oracle, nous avons examiné  comment mettre en œuvre Oracle Maximum Availibility Architecture (MAA).

Voici la cinquième  partie de ce dossier dans laquelle nous allons examiner les Solutions Oracle de Haute Disponibilité pour les ARRETS DE PRODUCTION NON PLANIFIES.

 

Article précédent : La Haute Disponibilité et les environnements Oracle – partie 4 : Oracle Maximum Availibility Architecture (MAA)

Solutions Oracle de Haute Disponibilité pour les ARRETS DE PRODUCTION NON PLANIFIES :

Avertissement : Nous ne voulons pas inquiéter le lecteur. La technologie Oracle est très robuste. Mais tous les responsables de Production savent qu’une multitude de problèmes différents peut survenir de façon exceptionnelle sur un site, particulièrement si ce site comporte de très grosses bases avec une activité intense.  Oracle fournit un ensemble de solutions pour faire face à ces risques potentiels.

Etendue de la panne Solution Oracle Bénéfices
Défaillances de site Oracle Data Guard(Recommandation MAA)
  • Basculement avec démarrage rapide et Fast Application Notification (FAN) avec les clients Oracle adaptés
  • Réplication physique, hautes performances, support de tous les types
Défaillances de site Oracle GoldenGate et Oracle Streams
  • Solution de haute Disponibilité flexible de type actif-actif (voir note 1)
Défaillances de site Recovery Manager (RMAN)
  • Restauration de base entièrement automatisée et intégration avec Oracle Secure Backup
Défaillances de serveur Oracle Real Application Clusters (Oracle RAC) etOracle Clusterware(Recommandation MAA)
  • Poursuite d’exploitation malgré la défaillance de serveur ou d’instances
  • Fast application notification (FAN) avec basculement des clients Oracle adaptés
Défaillances de serveur Oracle RAC One Node
  • Service de base de données mono-instance toujours disponible
  • Meilleure disponibilité de la base que les solutions traditionnelles de type Cluster actif-passif
  • Consolidation de serveur de bases de données
Défaillances de serveur Fast-Start Fault Recovery
  • Récupération de base optimisable et prédictible lors d’une défaillance d’un serveur
Défaillances de serveur Oracle Data Guard
  • Basculement avec démarrage rapide et Fast Application Notification (FAN) avec les clients Oracle adaptés
Défaillances de serveur Oracle GoldenGate et Oracle Streams
  • Facilite la création d’une copie locale ou distante de la base de production qui peut être utilisées pour reprendre les traitements suite à une défaillance
Défaillances de stockage Oracle Automatic Storage Management – ASM(Recommandation MAA)
  • Le Mirroring et le Rebalancing automatique en ligne place des copies dupliquées des données dans des Failures Groups séparés
Défaillances de stockage Oracle Data Guard(Recommandation MAA)
  • Basculement avec démarrage rapide et Fast Application Notification (FAN) avec les clients Oracle adaptés
Défaillances de stockage Recovery Manager avec Fast Recovery Area et Oracle Secure Backup
  • Restauration de base entièrement automatisée et intégration avec Oracle Secure Backup pour gérer des sauvegardes sur disque et bandes
Défaillances de stockage Oracle GoldenGate et Oracle Streams
  • Reprise des traitements sur la réplique (locale ou distante) de la base de production
Corruption de données Logiciel Oracle Exadata Storage Server  (Exadata Cell) et Oracle Automatic Storage Management – ASM(Recommandation MAA)
  • Si Oracle ASM détecte une corruption et dispose d’un bon miroir, Oracle ASM récupère le bon bloc et répare la corruption durant l’I/O d’écriture suivante
  • Les cellules de stockage Exadata sont la solution la plus complète, pour empêcher l’écriture de corruptions sur le disque, et cette solution est conforma à la technologie HARD (voir note 2)
Corruption de données Prévention, détection et réparation de corruption(Recommandation MAA) Paramètres d’initialisation de base tels queDB_BLOCK_CHECKING,DB_BLOCK_CHECKSUM etDB_LOST_WRITE_PROTECT
  • Il existe différents niveaux de prévention et détection de corruption dans l’utilisation de la base
Corruption de données Data Recovery Advisoret Recovery Manageravec Fast Recovery Area(Recommandation MAA)
  • Data Recovery Advisor détecte automatiquement les corruptions de données et recommande le meilleur plan de récupération
  • Le temps de récupération de bloc ONLINE avec RMAN est plus court car RMAN peut utiliser les Flashback Logs pour restaurer une copie de bloc de données plus récente avant d’effectuer un RECOVER dessus
Corruption de données Oracle Data Guard(Recommandation MAA)
  • Réparation de blocs de données Primaires en temps réel à partir d’une copie de bloc valide issue d’une base StandBy physique
  • Basculement avec démarrage rapide et Fast Application Notification (FAN) avec les clients Oracle adaptés
Corruption de données Oracle GoldenGate et Oracle Streams
  • Reprise des traitements sur la réplique (locale ou distante) de la base de production
Erreurs humaines Oracle Security Features
  • Restreint les accès de façon préventive
Erreurs humaines Oracle Flashback Technology
  • Capacité de “rembobiner” la base tant avec une granularité fine qu’au niveau de toute la base
Erreurs humaines LogMiner
  • Analyse des Redo Logs
Ecritures perdues Oracle Data GuardRecovery Manager, et le paramètre d’initialisationDB_LOST_WRITE_PROTECT
  • La paramètre d’initialisation DB_LOST_WRITE_PROTECT  permet de détecter les “écritures perdues”.
  • Si une “écriture perdue” survenue sur la base Primaire est détectée soit par la StandBy physique, soit pendant le Media Recovery de la base Primaire, le Recover est arrêté pour préserver l’intégrité de la base. Par contre, un Failover sur la base StandBy utilisant Oracle Data Guard peut provoquer quelques pertes de données.
  • Si une “écriture perdue” est détectée sur la base StandBy, vous pouvez restaurer le fichier affecté et relancer le Redo Apply si l’ “écriture perdue” est isolée et si le problème Hardware est corrigé

Note: Des “écritures perdues” peuvent corrompre entièrement une base, ce qui peut nécessiter la reconstruction de la base concernée après avoir résolu le problème hardware

Ecritures perdues Oracle Data GuardLogiciel Oracle Exadata Storage Server Software (Exadata Cell)
  • La détection et la prévention d’écritures perdues ou écrites dans un autre fichier de données. Vérifier avec votre fournisseur de stockage compatible HARD pour savoir s’il a implémenté cette protection supplémentaire. Pour assurer la meilleure protection contre les écritures perdues, utiliser Oracle Data Guard
  • HARD ne détecte pas une écriture perdue dans les cas suivants :
    • si une des couches logicielles ou matérielles (pilote logiciel, volume manager, carte adaptateur, logiciel de la baie disque) confirme l’écriture mais ne l’effectue pas
    • si l’écriture s’est produite par erreur dans un fichier autre qu’un fichier de base de données (ex. un fichier swap)
  • Les serveurs de stockage (cellules) Exadata sont compatibles avec les spécifications HARD, et implémentent tous les contrôles HARD. A la différence des autres implémentations des contrôles HARD, les contrôles HARD effectués avec les cellules EXADATA s’effectuent de façon complètement transparente.
  • Pour assurer la protection la plus complète possible contre les écritures perdues, utiliser Oracle Data Guard et positionnez le paramètre DB_LOST_WRITE_PROTECT (à TYPICAL ou FULL) à la fois sur la base Primary et la base StandBy
Blocages ou ralentissements Oracle Database et Oracle Enterprise Manager
  • Oracle Database surveille automatiquement les blocages de base et s’efforce de les résoudre
  • Oracle Enterprise Manager ou une application de monitoring spécialisée (de type Heartbeat) peut être configurée pour détecter un ralentissement d’application ou une augmentation du temps de réponse et réagir à ces non-respects des SLA.

Vous pouvez par exemple configurer  Enterprise Manager Beacon pour surveiller les temps de réponse des applications. Puis, après dépassement d’un seuil fixé, Enterprise Manager peut lancer la procédure PL/SQL Oracle Data Guard “DBMS_DG.INITIATE_FS_FAILOVER” pour provoquer un Failover.

 

A suivre : Solutions Oracle de haute Disponibilité pour les ARRETS DE PRODUCTION PLANIFIES.

  •  
  •