Ces notions somme toutes basiques sont parfois confondues quant aux possibilités qu’elles offrent et le licensing Oracle nécessaire à leur usage peut être méconnu.

Cet article a pour vocation d’expliquer le plus simplement possible la différence entre ces deux solutions et les avantages et inconvénients majeurs de celles-ci.

RAC – Une solution de haute disponibilité

Pour une application, la notion de haute disponibilité ne concerne bien entendu pas que l’aspect base de données. Elle est liée à l’architecture de la brique applicative mais aussi du stockage et du réseau. Dans une architecture haute disponibilité, tous les composants de l’architecture doivent être redondés.
Côté database Oracle, seul le RAC permet une réelle haute disponibilité. En effet, une base unique est accédée par au moins deux ou plusieurs instances de telle sorte que si l’une d’elle présente un défaut, l’accès à la base soit encore possible par une instance survivante.
Le RAC présente par ailleurs un autre atout majeur, celui de répartir la charge sur l’ensemble des instances disponibles (via le Load Balancer).
En cas de défaillance d’une des instances, la reconnexion de l’application d’une instance à une autre peut être gérée soit au niveau applicatif soit par un mécanisme Oracle (Transparent Application Failover), mais il faut avouer que le TAF est rarement mis en place car il n’est pas compatible avec une répartition de charge « automatique ».

RAC et licensing

Avant la version 19, le RAC était disponible en Standard Edition et n’était pas soumis à licence à condition de respecter le nombre maximum de socket sur l’ensemble du Cluster Oracle (4 en SE et SE One, 2 en SE2).
Depuis la version 19, l’usage du RAC est réservé aux licences Enterprise Edition.
En Enterprise Edition, l’option RAC nécessite une licence spécifique en plus de la licence database.

Dataguard – Une solution de Reprise ou de Continuité d’Activité

Le Dataguard souvent considéré comme une solution de haute disponibilité correspond en réalité plus à une solution de reprise ou de continuité d’activité en cas de défaillance ou pour maintenance. La base de données étant dupliquée (contrairement au RAC), elle peut aussi être considérée comme une solution de protection des données.
Avec Dataguard, selon sa configuration, il est possible d’alimenter une base non accédée en situation nominale depuis les journaux de transactions en ligne et/ou les archivelogs. Cette seconde base peut être accédée en lecture seule mais cet usage nécessite l’acquisition d’une licences spécifique (Active Dataguard). En cas de défaillance, la Standby peut prendre le relais de manière plus ou moins transparente (mais toujours avec une interruption des connections applicatives à la base). La bascule (Switchover ou Failover) peut être gérée automatiquement via un broker, et la reconnexion des applications peut être pris en charge soit par l’application, soit par une définition spécifique dans la chaine de connexion (du client Oracle ou de l’application).

Dataguard et licensing

L’usage de Dataguard est restreint à l’Enterprise Edition et ne nécessite pas de licence supplémentaire.
Une fausse idée reçue largement relayée dit qu’il n’est pas nécessaire de licencier la base de secours.
Sachez que votre base de secours, tout comme votre base principale, doit s’exécuter sur des cœurs licenciés. Il n’y a pas d’exception malgré ce que l’on peut trop souvent entendre.

RAC et Dataguard

Ces deux solutions répondent donc à des besoins différents.
Bien sûr, elles peuvent être couplées pour répondre à des contraintes de haute disponibilité et de Reprise/Continuité d’Activité et de protection des données.

Solutions alternatives en Standard Edition

En Standard Edition, si l’usage de Dataguard n’est pas autorisé, il reste possible de mettre en place une solution de Standby, soit en scriptant l’alimentation d’une base de secours (qui doit aussi être licenciée) par les archivelogs seulement, soit par l’utilisation d’outils non-Oracle (Comme Dbvisit Standby dont le licensing de l’outil diffère de celui d’Oracle).