Discussion :

[Chris Mad]

Bonjour à tous
Je travaille dans une petite start-up (20 personnes) qui utilise oracle comme SGBD. Notre capacité financière s'améliorant, certains dirigeants envisagent une évolution vers Oracle RAC.
J'ai certaines questions/doutes à ce sujet: est ce qu'il est envisageable de déployer une solution RAC dans un contexte PME/start-up, sachant que nous n'avons pas de compétence DBA en interne? N'est ce pas sur-dimensionné?
Tout avis ou conseil éclairés sur le sujet seraient très utiles.
Merci par avance de votre aide!

[FSiebert]

Bonjour,

est ce qu'il est envisageable de déployer une solution RAC dans un contexte PME/start-up

Si on écarte un instant le coup de la solution (mais vous semblez indiquer que ce n'est pas un frein), la taille de l'entreprise n'a aucune importance : c'est la criticité de la base de données qu'il faut prendre en compte.

Si le niveau de disponibilité attendu justifie une solution RAC alors ce n'est pas surdimensionné.

[Pomalaix]

Pour savoir si le RAC est techniquement pertinent, il faudrait qu'on en sache plus sur les objectifs auxquels vous souhaitez répondre par cette solution.

En admettant que c'est bien ce qu'il vous faut, il ne fait aucun doute qu'un système RAC nécessite une administration.
Si vous n'avez pas les compétences internes, alors il faut vous tourner vers un service à distance de type "remote DBA", ce que proposent différentes sociétés en France.
Ils s'occuperont de la mise en place initiale du RAC, et vous offriront différentes formules pour les opérations récurrentes ou ponctuelles, une assistance téléphonique, etc.

[Chris Mad]

Merci pour cette réponse

mais vous semblez indiquer que ce n'est pas un frein

Ce n'est pas tout à fait le cas. Désolé si je me suis mal fait comprendre. Le coût est un paramètre important et celui qui signera le chèque (le PDG) attend d'être convaincu.
D'autres paramètres entreront en ligne de compte: faut il des compétences supplémentaires pour gérer oracle RAC par rapport à une solution enterprise? Est il nécessaire de recruter un DBA?
Oracle a une image "grand compte". Connaissez vous des déploiements RAC en contexte petite start up?
Y a t il également des solutions alternatives moins onéreuses?

[FSiebert]

Il faut évidemment des compétences supplémentaires sur la technologie RAC.
De là à recruter un DBA à temps complet pour gérer un RAC ça semble démesuré. Comme l'a dit Pomalaix, il existe des services d'administration à distance qui pourraient répondre à vos besoins.
Je pense d'ailleurs que c'est un point à prendre en compte que vous soyez en RAC ou en base standalone qui mérite tout autant d'être administrée.

[Chris Mad]

Nous faisons déjà appel à un prestataire pour l'administration de notre base Oracle. Cependant, je ne trouve pas les services au niveau de ce qu'on pourrait attendre: suite à un incident technique, on s'est retrouvés sans stand-by pendant près d'un mois. Et encore, c'est un de mes collègues qui a trouvé la solution...
Donc pour une solution technologique plus évoluée, j'ai des doutes.

[FSiebert]

Nous faisons déjà appel à un prestataire pour l'administration de notre base Oracle. Cependant, je ne trouve pas les services au niveau de ce qu'on pourrait attendre: suite à un incident technique, on s'est retrouvés sans stand-by pendant près d'un mois. Et encore, c'est un de mes collègues qui a trouvé la solution...
Donc pour une solution technologique plus évoluée, j'ai des doutes.

Avez-vous envisagé de travailler avec un prestataire compétent ?

[pachot]

Bonjour,

On passe en RAC pour 2 choses: très haute disponibilité (la base reste disponible lors de la panne d'un serveur) et performance/scalabilité (sur plusieurs noeuds, pas de limite au nombre de CPU, taile de mémoire, etc)

Pour la performance, on peut aujourd'hui mettre beaucoup de CPU et mémoire dans une seule machine. On peut aussi utiliser une Standby (Active DataGuard) pour faire pas mal de chose: backups, reporting, extractions de données etc. et décharger la machine primaire.
Donc le côté performance est peut être moins justifié, sauf très gros besoin de performance.

Pour la Haute Disponibilité, il faut voir que vu la complexité de RAC, et sans DBA, il y a plutôt un gros risque de se retrouver avec une base moins disponible. Une standby DataGuard peut garantir une disponibilité en quelques minutes après une panne, et pour une configuration beaucoup plus simple à administrer.

Donc à mon avis, le RAC n'est justifié que par un besoin de très haute disponibilité (on ne peut pas accepter 1 minute d'interruption en cas de panne) et s'accompagne du coût d'administration correspondant à ce besoin (votre solution actuelle est très loin de ça semble-t-il).

Sinon, s'il y a vraiment un besoin RAC, pour une PME je pense qu'une bonne solution est ODA
Plus simple à administrer (on n'a pas à patcher chaque composant une à un), et possibilité de rajouter les CPU (et licences correspondantes) progressivement.
Ça n'empêche que c'est toujours un cluster et qu'en cas de problème il faut un DBA qui connaisse bien RAC.


Donc en bref:

faut il des compétences supplémentaires pour gérer oracle RAC par rapport à une solution enterprise?

Oui

Est il nécessaire de recruter un DBA?

Il faut en recruter 2 (vacances, astreintes,...) ou s'adresser à une boite sérieuse pour externaliser.

Connaissez vous des déploiements RAC en contexte petite start up?

Oui plusieurs, avec deux ODA en DataGuard + un contrat d'administration externe

Y a t il également des solutions alternatives moins onéreuses?

Un DataGuard bien configuré peut faire un failover en une minute en cas de problème.

Cordialement,
Franck.

[ducho]

Bonjour,

il existe aussi Golden Gate , produit payant utilisable en standart Edition .
dataguard n'est pas fourni en Standard edition .

Quelle edition d'Oracle avez-vous ?

Cordialement

[Mohamed.Houri]

Un problème de design mineur dans une base de données ‘’single instance’’ peut s’exacerber et causer de sérieux problèmes de performance si vous convertissez en RAC. Par exemple, une séquence avec un cache mal définie en ‘’single instance’’ peut y passer inaperçue alors qu’en RAC elle peut être catastrophique en générant des temps d’attentes du type (gc buffer busy wait, enq –Tx index contention). Ceci sans parler de la gestion du buffer cache. Par exemple aussi, en single instance, un bloc dans le buffer cache appartient à une et une seule instance. S’il n’est pas dans le buffer cache alors il est forcément dans le disque. En RAC, le bloc peut être soit dans le cache de n’importe quelle autre instance soit dans le disque. Si le bloc ne se trouve pas dans le cache de l’instance qui le veut, un processus(FG) va identifier l’instance maitresse qui possède ce bloc. Ensuite un autre processus (LMS) va jouer le rôle d’un chef d’orchestre en faisant ceci (pour faire simple):

(a) Identifier le cache de l’instance qui possède la dernière version du bloc et envoi ce bloc à l’instance qui l’a demandé

(b) Si le bloc ne se trouve dans aucun cache d’aucune instance, il va le lire du disque et l’envoyer à l’instance qui l’a demandé

Ceci peut différer légèrement selon que le bloc ait été voulu en current mode ou en read consistent mode.

C’est pour cette raison que vous allez être confrontés à de nouveaux temps d’attente du type gc current bloc 2-way et gc current bloc 3-way.

Pour plus d’information à ce sujet je vous invite à lire le chapitre 8 ''RAC AND RUIN'' du dernier livre de Jonathan Lewis et les Chapitre 6, 10 et 11 du livre Expert Oracle RAC que les auteurs m’ont fait l’agréable surprise en m’offrant une copie et en me demandant de faire une ‘’review’’. N’ayant jamais travaillé sur RAC, je leur ai dit qu’ils se trompent peut-être. Lorsqu’ils ont insisté j’ai alors fait ma ‘’review’’ de ce livre et non seulement j’ai appris beaucoup de choses mais j’ai aussi appris qu’avant de penser RAC il faudrait d’abord penser à maîtriser ‘’single instance’’

[Chris Mad]

Bonjour
Toutes les excuses pour la réponse tardive

Quelle edition d'Oracle avez-vous ?
Cordialement

Aujourd'hui, nous utilisons une standard édition.
Nous avons avancé sur la définition de nos besoins en termes de disponibilité. On remplit notre contrat si on garantit une indisponibilité inférieure à 1/2 h. A ce jour, il nous faut 8 heures pour remonter une base à partir d'une sauvegarde et c'est rédhibitoire.

[Chris Mad]

'RAC AND RUIN'

avant de penser RAC il faudrait d’abord penser à maîtriser ‘’single instance’’

Merci du conseil!.
Si je comprend bien, le remède peut s'avérer pire que le mal si l'outil est mal maîtrisé.
Les questions qu'on se pose alors sont de savoir :

• quel est le niveau de maîtrise à avoir

• si on ne l'a pas, quel est le niveau de compétence et d'engagement à demander à un remote dba afin d'optimiser les coûts d'administration.

[Chris Mad]

Pour savoir si le RAC est techniquement pertinent, il faudrait qu'on en sache plus sur les objectifs auxquels vous souhaitez répondre par cette solution.

Nous avons maintenant une définition plus claire de nos objectifs:
Indisponibilité maximale : 1/2 h
En cas de corruption de donnée (corruption fonctionnelle notamment) Possibilité de repartir sur des données précédentes vieilles de plusieurs heures (le "plusieurs" est en cours de définition) toujours dans la 1/2 h impartie

[pachot]

Bonjour,

Indisponibilité maximale : 1/2 h
En cas de corruption de donnée (corruption fonctionnelle notamment) Possibilité de repartir sur des données précédentes vieilles de plusieurs heures (le "plusieurs" est en cours de définition) toujours dans la 1/2 h impartie

Donc la meilleure solution est d'avoir une base en standby: facile à mettre en oeuvre (je veux dire beaucoup plus facile que RAC), possibilité de failover en moins d'1/2 heure, possibilité de perdre moins d'une heure de transaction, tout ça possible en Standard Edition.

En passant en Entreprise Edition (bcp plus cher), la standby est gérée avec DataGuard: plus facile à gérer, possibilité de ne perdre aucune transaction en cas de failover.

Avec RAC vous allez introduire une plus grande complexité (qui peut amener à une plus faible disponibilité) et vous ne serez protégés que pour un crash d'instance. Pas pour les corruption. donc ce n'est pas la solution adaptée à ce besoin.

Cordialement,
Franck.

[Rams7s]

Ou des snapshots au niveau du NAS/SAN, si il y a en un?
C'est quand même supra-rapide, et le plus long du coup c'est le lancement de l'instance (avec un petit reset truc-logs). Je propose ça, au cas où vous avez le matériel derrière.

[pachot]

Bonjour,

Ou des snapshots au niveau du NAS/SAN, si il y a en un?
C'est quand même supra-rapide, et le plus long du coup c'est le lancement de l'instance (avec un petit reset truc-logs). Je propose ça, au cas où vous avez le matériel derrière.

Il y a aussi le recover (rejouer les archive logs) qui peuvent prendre du temps.
L'avantage de la standby est d'avoir un autre serveur tout prêt a être utilisé.

Mais c'est vrai que les backups par snapshot répondent au requirements.

Cordialement,
Franck.

[Chris Mad]

Il y a aussi le recover (rejouer les archive logs) qui peuvent prendre du temps.

C'est actuellement l'un des problèmes que nous cherchons à résoudre. Notre base fait plus d'un To et la reconstruction d'une instance prend 8h!

[Rams7s]

En fait c'est tout l'interet des snapshots.
(encore une fois si votre matériel au niveau de disque le fait, sinon c'est inutile comme piste )

Les snapshots vont grosso-modo faire du copy-on-write. C'est à dire qu'à partir du moment où vous effectuez un snapshot, le système de disques va enregistrer chaque block qui est modifié. Ce qui; grâce à un snapshot-restore va lui permettre de revenir quasi-instantanément à l'état au moment du snapshot en remplaçant les blocks mémoires modifiés par leur valeure originale. Votre base de 8To: elle se restaure (pour les datafiles) en moins de 3s., mieux que Rman non?
Ensuite, il va simplement manquer un redémarrage en reset redo logs si je ne m'abuse. Mais j'imagine que si vous faites ces snapshots toutes les 15minutes, ça devrait pas prendre beaucoup de temps.

Attention quand même à la durée de rétention. Gardez des snapshos toutes les 15minutes pendant 1semaies, ça va vite faire un espace disque énorme.

[pachot]

Bonjour,

Ensuite, il va simplement manquer un redémarrage en reset redo logs si je ne m'abuse.

Il y a quand même un petit recover à faire: appliquer le redo généré entre le dernier checkpoint et la fin du snapshot. Car je suppose que le snapshot tous les 15 minutes se fait base ouverte

Votre base de 8To: elle se restaure (pour les datafiles) en moins de 3s., mieux que Rman non?

Oui. Et en cas de blocs corrompus, on restaure aussi la corruption en 3s
Rman est plus long mais vérifile l'état des blocs au passage...

Bon, sans vouloir insister, une base en standby sera toujours prête, avec tout le redo déjà appliqué, prête à réouvrir la base sans perte de transaction avec une seule commande...

Le snapshot c'est très bien pour faire des backups journaliers. Mais je ne suis pas sûr que ça corresponde au besoin de disponibilité énoncé (RTO= 1/2 heure, RPO= quelques heures).

Cordialement,
Franck.

[Chris Mad]

Si vous n'avez pas les compétences internes, alors il faut vous tourner vers un service à distance de type "remote DBA", ce que proposent différentes sociétés en France.

Bonjour à tous
Je reviens sur mon sujet.
Avez vous à me suggérer des prestataires (compétents cela va sans dire ;-)) pouvant assurer un service de remote DBA et/ou de conseil pour l'établissement d'une architecture adaptée à nos besoins et nos moyens?
Merci de me répondre en privé. Je crains que la citation de noms de sociétés sur ce forum ne soit pas dans les règles.