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]

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.

[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.

[Waldar]

Je crains que la citation de noms de sociétés sur ce forum ne soit pas dans les règles.

Tant qu'il n'y a pas diffamation ça ne pose aucun problème.

Un extrait des règles du forum :

Les insultes et la diffamation envers des individus et sociétés sont sévèrement punies par la loi, y compris sur les forums, et par conséquent interdites et supprimées à vue.

Peu d'entre nous savent en quoi consiste la diffamation. Un rappel :

Il n'est pas besoin que les affirmations soient fausses pour qu'il y ait diffamation. Le seul fait de citer une marque, une société, un individu et de tenir à son égard des propos qui peuvent lui porter préjudice constitue une diffamation, ce qui tombe sous le coup de la loi.

[IndianaAngus]

Si vous prenez RAC, je peux vous conseiller de le prendre en standard ou l'option RAC est offerte alors qu'elle est payante sur une EE (et c'est pas donné). Cela sera bien moins cher mais limité à 4 socket.
On peut faire aussi des snapshots avec ASM indépendamment du matériel ou même des images copy avec RMAN pour switcher très rapidement sur les datafiles en cas de problème + recover des dits datafiles mais ca va doubler votre espace disque utilisé.

Nous avons implémenter une db standy avec une standard edition (le dataguard du pauvre en quelque sorte :-) ), c'est très simple à mettre en place et ca fonctionne très bien. Le seul risque est de perdre les dernières transactions non archivé et non transférer sur le serveur standby, tout dépend de ce que vous êtes prêt à perdre.

[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]

'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]

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.