La Haute Disponibilité et les environnements Oracle – partie 5

• 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

• Solution de haute Disponibilité flexible de type actif-actif (voir note 1)

• Restauration de base entièrement automatisée et intégration avec Oracle Secure Backup

• Poursuite d’exploitation malgré la défaillance de serveur ou d’instances
• Fast application notification (FAN) avec basculement des clients Oracle adaptés

• 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

• Récupération de base optimisable et prédictible lors d’une défaillance d’un serveur

• Basculement avec démarrage rapide et Fast Application Notification (FAN) avec les clients Oracle adaptés

• 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

• Le Mirroring et le Rebalancing automatique en ligne place des copies dupliquées des données dans des Failures Groups séparés

• Basculement avec démarrage rapide et Fast Application Notification (FAN) avec les clients Oracle adaptés

• Restauration de base entièrement automatisée et intégration avec Oracle Secure Backup pour gérer des sauvegardes sur disque et bandes

• Reprise des traitements sur la réplique (locale ou distante) de la base de production

• 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)

• Il existe différents niveaux de prévention et détection de corruption dans l’utilisation de la base

• 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

• 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

• Reprise des traitements sur la réplique (locale ou distante) de la base de production

• Restreint les accès de façon préventive

• Capacité de “rembobiner” la base tant avec une granularité fine qu’au niveau de toute la base

• Analyse des Redo Logs

• 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

• 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

• 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.