Il existe plusieurs moyens de rendre une base de données Oracle hautement disponible. Choisir la bonne approche, c’est obtenir un compromis entre un objectif de haute disponibilité et une contrainte budgétaire. Plus vos exigences de disponibilité sont élevées, plus le budget à allouer est important. Voici nos conseils pour trouver le bon niveau de disponibilité selon votre version de base de données Oracle.

En cas d’incidents (matériel ou logiciel), une base de données Oracle hautement disponible doit être à nouveau opérationnelle le plus rapidement possible et ce sans perte de données, soit :

–       en utilisant le même jeu de fichiers de données (appelés datafiles par Oracle);

–       en utilisant une copie de vos fichiers de données.

Nous analyserons par ailleurs les subtilités des licences Oracle dans un prochain post. Dans cet article, nous nous concentrons sur les 2 versions de la base de données Oracle:

–       Standard Edition 2

–       Enterprise Edition

Le type de version dont vous disposez va conditionner vos options ainsi que la performance qui en découle.

Base de données Oracle : Standard Edition

Si vous disposez d’une version Standard de la base de données Oracle, votre seule option est de choisir d’utiliser le même jeu de fichiers. Pour cela, vous avez deux possibilités :

1. En installant votre base Oracle dans une machine virtuelle supportée par un cluster d’hyperviseurs avec un stockage centralisé. C’est une approche valable si vous mettez en oeuvre Oracle VM. Si vous utilisez une autre technique de virtualisation, cette première approche peut être risquée au niveau des coûts de licences. 
2. En utilisant le cluster Oracle pour assurer un redémarrage de votre base de données. Ceci est possible sans utiliser Rac ou Rac one Node. Leur usage est de toutes façons banni par Oracle depuis la version 19 de Standard Edition. Cette technique n’est ni documentée, ni supportée par Oracle.  Toutefois, chez CarteSoft, nous l’avons plusieurs fois mis en oeuvre avec succès. 

Le choix entre ces deux approches dépend de vos contraintes.  Gardez à l’esprit que :

• dans les deux cas, un crash hardware entraîne une indisponibilité de quelques minutes. Soit le temps nécessaire au redémarrage de la base de données;
• dans le deuxième cas, avec une configuration efficace, il est possible de se protéger d’un crash logiciel de la base de données. Le cluster redémarre alors automatiquement la base de données.

Comment une base de données Standard Edition 2 peut-elle être protégée par un mécanisme de réplication de type Data Guard? Cette question mériterait un article en soi. De toute évidence, cela ne peut se faire sans perte de données en cas d’incidents.

Base de données Oracle: Enterprise Edition

Si vous disposez d’une base Enterprise Edition, les procédures relatives à la version Standard peuvent être mise en oeuvre. Elles représentent les solutions les plus économiques d’une stratégie de haute disponibilité pour une version Enterprise. Avec la version Enterprise, vous disposez d’avantages d’options. 

Si vous privilégiez l’utilisation d’un même jeu de fichiers, voici les options payantes possibles :

• Rac. Elle permet de limiter les indisponibilités de votre base de données à 0. En cas de crash hardware ou logiciel, une autre instance de DB déjà démarrée est disponible. Attention, c’est une option payante. Celle-ci demande de licencier tous les noeuds du cluster Oracle.
• Rac One Node. Elle n’offre pas de disponibilités supplémentaires par rapport à l’option cluster Oracle détaillée pour la Standard Edition. Elle permet cependant une mise hors service contrôlée d’un noeud du cluster. Même mise en garde que pour Rac, Rac One Node est une option payante elle aussi. Celle-ci demande également de licencier tous les noeuds du cluster.

 Si vous privilégiez l’utilisation d’un jeu de fichiers différents, vous pouvez recourir à DataGuard pour assurer la réplication entre deux bases de données. Incluse avec la version Enterprise Edition, cette fonctionnalité de base permet de répliquer une base de données vers une autre base de données. En ce faisant, vous pouvez conserver sur une autre machine  – localement ou à distance – une parfaite copie de votre DB. En cas de crash hardware ou logiciel, l’utilisation de DataGuard vous permet d’assurer un redémarrage en quelques minutes. Si les clients ont été correctement configurés, la redirection des connexions vers la nouvelle base de données est automatisée. 

Quid du SAN ?

Toutes les technologies à base de Cluster supposent un stockage centralisé de type SAN (Storage Area Network). Ce qui implique que la disponibilité de la base de données soit directement liée à celle de votre SAN. En l’absence de SAN ou si celui-ci ne garantit pas les conditions de disponibilité requises, DataGuard reste votre meilleure option si tant est que vous disposiez de la version Enterprise.