L’automatisation du redémarrage des services de base de données permet d’assurer une réactivité rapide, sans attendre une intervention humaine.
Un incident peut survenir la nuit, le week-end ou pendant les fêtes de fin d’année, alors que vous passez de bons moments avec vos proches.
Dans beaucoup d’environnements, la base de données peut survivre à un incident, mais les services restent arrêtés, les connexions ne reviennent pas et l’exploitation dépend d’une intervention humaine, parfois trop tardive.
SOLUTION COURANTE
Dans de nombreux environnements, le redémarrage des services après incidents repose encore sur des mécanismes partiels ou incomplets.
Redémarrage des services via cron et systemd
Par exemple, le redémarrage des services Oracle est souvent effectué via cron ou systemd après un arrêt du système.
Ces scripts s’exécutent sans analyser l’état réel de la base de données avant l’incident (arrêt propre, crash, récupération requise).
Ils interviennent principalement au démarrage du serveur, sans assurer une surveillance continue des services susceptibles de s’arrêter brutalement en cours de fonctionnement.
Protection des instances via Oracle RAC sans prise en compte des sessions
Dans sa configuration par défaut, Oracle RAC protège avant tout la disponibilité des instances, mais pas la continuité des sessions applicatives.
En cas de panne brutale d’une instance, toutes les sessions connectées à cette instance sont interrompues.
- Toutes les sessions connectées à cette instance sont interrompues.
- Les utilisateurs ou applications doivent alors se reconnecter manuellement aux instances restantes.
- Ce qui peut provoquer des interruptions visibles côté métier.
Réplication des données avec Oracle Data Guard sans bascule automatique
Une configuration standard d’Oracle Data Guard assure la réplication des données, mais ne déclenche pas automatiquement la bascule vers le site de secours.
Résultat : Les données sont disponibles sur le site de secours, mais les services de base de données ne sont pas activés automatiquement. L’intervention humaine reste nécessaire pour restaurer le service applicatif.
Les connexions des clients sont figées vers un serveur unique.
Très souvent, les paramètres de connexion des applications pointent vers :
- un nom de serveur.
- ou une adresse IP unique du site de production.
En cas d’incident ou de bascule, il faut donc reconfigurer l’ensemble des clients, même si la base de données est techniquement capable de basculer automatiquement.
RECOMMANDATION
Pour garantir un redémarrage automatique, et dans le bon ordre, des services et limiter l’impact des incidents sur les utilisateurs et les applications, Oracle met à disposition des mécanismes qu’il est fortement recommandé d’intégrer dès la conception.
Oracle Restart assure une surveillance continue des ressources critiques (instances, listeners, services).
En cas d’arrêt brutal, il redémarre automatiquement et dans le bon ordre les composants nécessaires, en tenant compte de leur état.
TAC (Transparent Application Continuity) permet de préserver les sessions applicatives actives lors d’un incident sur une instance.
Les transactions en cours sont automatiquement rejouées sur une autre instance disponible, sans intervention côté application.
Les utilisateurs ne perçoivent qu’une simple latence, sans déconnexion ni perte de contexte.
FAN (Fast Application Notification) diffuse en temps réel des événements vers les applications et les pools de connexions.
Lorsqu’un nœud devient indisponible, les connexions associées sont immédiatement retirées.
Les applications cessent d’envoyer du trafic vers les ressources défaillantes, ce qui réduit fortement les erreurs et les temps d’attente.
Fast-Start Failover (FSFO) automatise la bascule entre le site principal et le site de secours dans une configuration Oracle Data Guard.
Il détecte la perte du site primaire, déclenche automatiquement la promotion du site de secours et remet les services à disposition sans attendre une action humaine.
Cette automatisation réduit drastiquement le RTO et garantit la continuité du service, même en dehors des heures ouvrées.
✨ EN BONUS
Configurez vos services avec srvctl et connectez-vous uniquement via ces services.
Les services Oracle constituent le point d’entrée logique vers la base de données.
Déclarez et gérez systématiquement vos services avec srvctl et évitez toute connexion directe vers une instance à travers le service par défaut.
Cela permet aux mécanismes RAC, TAC, FAN et FSFO de fonctionner correctement et d’orienter les connexions vers les ressources disponibles.
Testez régulièrement la réaction de la base de données face aux incidents connus.
Un mécanisme non testé est un mécanisme non maîtrisé.
- Simulez des arrêts d’instance, de nœud, de listener ou de site.
- Mesurez les temps de reprise, observez le comportement des applications et corrigez les points bloquants avant qu’un incident réel ne survienne.
Choisissez soigneusement l’emplacement de l’Observer (FSFO).
L’Observer est un composant critique de la bascule automatique.
Il doit être positionné sur un site indépendant du site primaire et du site de secours, avec une connectivité réseau fiable.
Un mauvais positionnement peut empêcher la bascule, voire déclencher une bascule non souhaitée.
Préparez les clients à se connecter à la base de données réellement disponible.
Les paramètres de connexion doivent intégrer la notion de service et de disponibilité.
- Utilisez des chaînes de connexion dynamiques compatibles avec RAC et Data Guard.
- Assurez-vous que les clients savent automatiquement vers quelle base se connecter après un incident, sans reconfiguration manuelle.
