Discussion :

[pifor]

On peut utiliser TAF avec Data Guard 11.2 sous certaines conditions:
- utiliser Data Guard Broker
- utiliser Grid Infrastracture pour que Oracle Restart gère les services des instances.

Voir http://www.oracle.com/technetwork/da...ver-173305.pdf

[Marc Musette]

finalement, il y a peu d'amateurs RAC ... il faut absolument passer un coup de fil à Larry pour lui dire d'abandonner ce produit

[orafrance]

et pourquoi pas rac en enterprise edition ?

Parce que c'est cher

Rien n'interdit évidemment de prendre RAC en Enterprise mais j'avais cru comprendre qu'il y avait un souci économique derrière la question de départ

avec les possibilités qu'offrent les logical standby (et physical depuis la dernière release) d'être ouvertes en read et même en write, on peut vraiment décharger les batchs de reporting , de backups, et même les querys ad-hocs du décisionnel sur l'instance en standby

Si je ne m'abuse, en physical, quand tu ouvres la base tu n'appliques plus les archives, tu t'exposes donc à une recover plus long, ce qui peut poser problème dans le cadre d'un DRP. Pour moi, la standby c'est pour du disaster recovery, rien d'autre. Quand au logical, je reste réservé sur la solution tant Streams a de détracteur (bien que pour ma part je l'ai expérimenté avec succès ).

Je crois qu'il faut éprouver la logical standby avant de "descendre" cette option.
pas si nouvelle que çà d'ailleurs (2002)

En effet, pour l'avoir éprouvé, je ne comprends pas toutes ces réticences autour de la standby logique... ceci étant, c'est tellement complexe à mettre en oeuvre que je peux comprendre que pas mal de monde se rate

[orafrance]

Pour ce qui est de la haute dispo des dataguards, on peut vraiment faire quelque chose de très satisfaisant en paramétrant le mode FAILOVER du client, voir la discussion que nous avions eu dans les temps anciens:

http://www.developpez.net/forums/d23...-vers-standby/

Ce qui est bien avec ce paramétrage, c'est que les applicatifs ne détectent aucune perte de connexion (on l'a testé sur des applis de prod d'une très grosse entreprise française, c'était épatant) il y a simplement une "pause" dans les accès. Mais si on fabrique un processus de bascule efficace (ou il ne faut pas oublier d'éteindre le listener de la base cassée) cette pause peut etre insignifiante.

J'ai jamais réussi à faire marcher ça J'ai toujours une déconnexion des clients quand on switche

[remi4444]

Je crois qu'il faut éprouver la logical standby avant de "descendre" cette option.
pas si nouvelle que çà d'ailleurs (2002)

Oui ben, en attendant ce sont mes nerfs qui ont été éprouvés avec cette m... methode :p

j'ai vu souffrir les 9 process parallèles de logminer pour rattraper les requêtes, la base s'écrouler parceque certains plans d'exécution partaient en vrille et surtout...

J'ai du passer 2 jours à trouver une magouille non documentée et non supportée pour réussir à reconstruire à chaud la standby logique, car officiellement ce n'est pas possible (obligé de stopper la base maitre pour obtenir le SCN de départ)

La haute disponibilité offerte par le rac ne peut pas être atteinte avec du dataguard. Il n'y a pas - sauf erreur de ma part - de Transparent Application Failover sur dataguard.

en plus, lors d'un basculement, tu dois gèrer le time lag => les clients peuvent être en "pause" longtemps

Je n'ai pas dit que la standby physique était la perfection, mais dans une très grosse entreprise française dont j'ai fait partie de l'équipe des DBA, on a fini par en faire notre norme principale en matière de haute dispo et de sécuristation des données, et ce, même avant la 11g qui apporte encore des améliorations.

Aussi, d'expérience, on s'est aperçu qu'aussi bien le RAC que le clustering-système était (trop) souvent à l'origine d'incident alors que c'était censé les éviter.

On a élaboré des procédures solides en matières de construction de reprise et de bascule à chaud (en se passant de DG-Broker qui nous a pété dans les mains un jour.) Par exemple, construire à chaud une standby physique est devenu un jeu d'enfant avec rman.

Un atout majeur pour moi est que le système s'appuie sur du recover. C'est à dire que ça fait une pierre 2 coups en permettant de valider en permanance les sauvegardes de la base maitre. Car il ne faut pas oublier que lorsqu'une sauvegarde n'est pas régulièrement testée en restauration (plusieurs fois par an) il faut considérer cette sauvegarde comme non-fiable. La standby permet de résoudre ça et ça fait du boulot (et du stress) en moins...

Tant qu'à faire de la duplication logique des données, je trouve que c'est aussi bien de choisir carrément la réplication multi-master. C'est aussi une belle usine à gaz, mais au moins c'est plus souple et plus puissant... La standby logique est pour moi un hybride entre les 2 (stby physique et réplication multi-maitre) c'est pour ça que je n'y vois pas un grand intérêt, mais ce n'est que mon avis...

[remi4444]

J'ai jamais réussi à faire marcher ça J'ai toujours une déconnexion des clients quand on switche

tiens bizarre, moi ça fonctionnait bien, on l'a testé et éprouvé à de nombreuses reprises et parfois de manière involontaire! ...
faut faire attention aux paramètres du failover, à mettre un très grand nombre d'essais ("retries") et aussi à bien penser à eteindre le listener public avant toute maintenance sur la base principale.

[Marc Musette]

Parce que c'est cher

Rien n'interdit évidemment de prendre RAC en Enterprise mais j'avais cru comprendre qu'il y avait un souci économique derrière la question de départ

avoir une standby en attente de perdre ton site primaire , c'est également cher, non ?

d'ailleurs oracle est cher.

Si je ne m'abuse, en physical, quand tu ouvres la base tu n'appliques plus les archives, tu t'exposes donc à une recover plus long, ce qui peut poser problème dans le cadre d'un DRP. Pour moi, la standby c'est pour du disaster recovery, rien d'autre.

le standby snapshot database (11g) est la réponse à ce problème

que l'on soit bien clair, je suis un "fan" de dataguard, qui est pour moi la meilleure solution DRP pour une db oracle ; le rac, par contre est également une solution sensationnelle si bien mise en place mais beaucoup plus compliquée car elle impacte les applications

[orafrance]

avoir une standby en attente de perdre ton site primaire , c'est également cher, non ?

Oui mais l'option Dataguard est incluse dans la version enterprise. D'où ma réflexion : DG pour Enterprise et RAC pour Standard avec évidemment des destinations différentes.

d'ailleurs oracle est cher.

Pas encore assez à voir les parts de marché

le standby snapshot database (11g) est la réponse à ce problème

Sympa en effet

que l'on soit bien clair, je suis un "fan" de dataguard, qui est pour moi la meilleure solution DRP pour une db oracle ; le rac, par contre est également une solution sensationnelle si bien mise en place mais beaucoup plus compliquée car elle impacte les applications

Moi aussi je préfère Dataguard, RAC n'est d'ailleurs pas réellement destiné à un DRP puisqu'on ne peut pas avoir des serveurs trop éloignés Mais ça peut être plus économique