Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
haute disponibilité D'un serveur BD
Bonjour,
j'ai une BD oracle 10G dans mon entreprise qui est très importante.
nous voulons minimiser la tolérance de panne.
comme matériel nous avons:
- 2 serveurs HP Proliant DL 580 G5 4 disques chacun, 8 Go de RAM.
Quelle peut etre l'architecture à utiliser et quel est le meilleur OS à utiliser (Windows server 2008 ou Linux).
Merci.
linux ou windows? cela dépend de tes compétences ? fort à parier que tu es plutôt windows => reste windows
sinon celon que tu accepte ou non une perte de connexions (fort à parier que oui), tu choisiras d'installer RAC ou configurer une standby database
est ce que Oracle Data Guard peut etre la solution?
Data guard et Stand by designent en fait la même chose. C'est une très bonne solution testée, éprouvée et approuvée pour ma part... à ceci pres que d'expérience (dont une qui a eu pour conséquence la perte d'une base!), c'est plus sur de le faire en mode simple avec du scripting s'appuyant sur les fonctions oracle standart plutot que d'utiliser dg_broker (outil d'automatisation oracle bof, bof...)
Sur une Enterprise se sera Dataguard et RAC en standard si c'est techniquement possible (proximité des serveurs notamment).
Perso, j'ai jamais eu de souci avec DG_BROKER, tout au plus on pourra éviter de démarrer l'observer pour ne pas avoir de bascule automatique.
Sous windows, si on a un stockage partagé, il y a FailSafe qui est très facile à mettre en oeuvre, et qui se base sur MSCS (cluster microsoft)
En cas de de crash, l'instance est redémarré sur un autre noeud
En effet, je croyais que ça n'existait plus mais c'est une solution très sympa
Edit : ha oui, en fait ça ne supporte pas Windows Server 2008 visiblement
je crois que pour utiliser RAC il me faut un bais de disque!
alors que nous avons fait un investissement pour l'achat des serveurs, je me demande est ce que je peut utiliser Data Guard pour ces deux serveurs qui seront dans le meme LAN.
Si je ne m'abuse, RAC garanti la haute dispo de l'instance, mais ce n'est pas en soit de la sécurisation des données.
Moi j'aime bien la dataguard parceque ça s'appuie exactement sur le même système que les sauvegardes (pilotées par rman) le principe c'est que c'est une base en restauration permanante à partir des sauvegardes de ta base maitre. Ce qui fait que ça te garanti et, la haute dispo des données, et que la sauvegarde se déroule bien... pour ça, il est meme possible d'ouvrir la base en lecture seule et prévoir quelques requêtes de vérification quotidiennes.
si si d'après la page de téléchargement http://www.oracle.com/technetwork/da...ex-082893.html ca marche sous windows 2008Envoyé par orafrance
En effet, je croyais que ça n'existait plus mais c'est une solution très sympa
Edit : ha oui, en fait ça ne supporte pas Windows Server 2008 visiblement
le RAC apport la meilleure disponibilité mais a surtout un coup de licence trés élevé par contre il permet d'economiser sur le hard. Tes deux serveurs marche il n'y en a pas un qui ne sert que en cas de panne.
ASM me semble une solution dans ton cas pour fair du RAC sans baie.
Data guard garanti mieux les données avec une possiblité de ne pas faire la replication en temps réel se qui peu te permettre de facilement recupére par exemple les erreurs humaine de la journée.
Pour préciser la remarque de a.presles sur les dataguard, il faut savoir que même si on restaure les données en différé, celles ci sont quand même sauvegardées en temps réel sur le serveur 2, elles sont juste en attente de restauration, la sécurité est donc bien présente meme lorsqu'on prend cette option.
En effet, mais quand on parle de haute dispo, le RAC peux suffire pourvu que le stokage soit prévu en conséquence : switch redondant, Raid, double alim, etcmais sans SAN, c'est réglé
+1 DG + flashbacklog pour moi c'est la garantie de répondre à tous les risques que ce soit physique ou logiqueJe regrette juste qu'Oracle n'est pas prévu un assistant d'installation parce que c'est quand même pas super évident à mettre en place et le diagnostic des incidents est assez délicat à faire je trouve.
ha oui... décidément, j'étais pas reveillé
RAC est inclus dans la version standard qui en plus facture au CPU et non au core, c'est donc de loin le plus économique mais ça ne répond pas à tous les besoins, notamment si on veut absolument une version Enterprise
T'as les flashbacklogs pour ça, nettement plus facile à gérer
<mauvaise-langue>
En meme temps quand on voit la tete, l'ergonomie et la solidité de certains assistants c'est peut être mieux qu'ils se soient abstenus!
</mauvaise-langue>
De manière générale, quand on est du dommaine du traitement des incidents, je me méfie des assistants comme de la guigne, parcequ'on est toujours dans des conditions particulières, imprévues, tendues... c'est donc souvent que l'assistant lui même se prenne les pieds dans le tapis et rajoute une nouvelle couche de problème dont on se passerait bien...
C'est sur que c'est moins sexy de se palucher des lignes de commande, mais au moins, ça oblige à rentrer dans le coeur du système et surtout, ça permet de vérifier chaque étape pas à pas.
et pourquoi pas rac en enterprise edition ? pour info, les strech cluster sont également supportés en rac donc, avec du dwdm, on peut avoir les noeuds sur deux sites distants, avec un 3è site pour le 3ème voting disk.
rac est la solution HA d'oracle, dataguard est une solution de DISASTER RECOVERY : il y a toujours une perte de connexion au niveau client lorsqu'on perd la primary database ; ce qui n'est pas le cas avec le rac.
par contre rac est beacoup plus compliqué à administrer et une appli mal écrite va réellement souffrir sur rac à cause des mécanismes de cache fusion
pour le reste, il est également faux de prétendre que dans le cas d'une solution DG, le second serveur est inactif : 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 l'appli tolère une coupure, alors on prendra DG ; si pas le rac, et si on veut bénéficier de l'ensemble des avantages des 2 solutions, il suffit de les combiner (voir le white paper MAA d'oracle)
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.
A l'époque, il n'était pas possible d'ouvrir une base qui était en mode recover, et pourtant on arrivait déjà à faire des trucs pas mal. Je n'ai pas testé le système en 11g mais je suppose qu'il ouvre encore de nouvelles possibilités.
En revanche, je déconseillerais fortement la standby logique qui, bien qu'ayant un nom voisin de la standby physique n'a dans son fonctionnement que très peu de rapport.
Pour résumer, la standby physique s'appuie sur le bas niveau, sur le système éprouvé depuis des décénies des recover d'archivelog alors que la standby logique est un passage 'par au dessus', c'est à dire par des générations de requêtes SQL à partir de logminer, requêtes rejouées sur la base secondaire.
C'est vraiment une grosse usine à gaz, d'expérience peu efficace. Je me souviens dans la meme entreprise avoir eu le cas ou le re-jeu des SQL prenait presque autant de temps que les modifs de la base primaire!
En outre la standby logique, comme son nom l'indique ne peut pas etre considérée comme une sauvegarde sécurisée mais comme une copie logique de certaines tables, ce qui n'est pas la même chose.
La session est transférée oui mais pas la transaction: seules les requêtes SELECT sont reprises ; ce qui n'est pas un détail pour l'application et pour l'utilisateur si l'application ne sait pas faire.
d'après http://download.oracle.com/docs/cd/E....htm#RACAD8268TAF can restart a query after failover has completed but for other types of transactions, such as INSERT, UPDATE, or DELETE, the application must rollback the failed transaction and resubmit the transaction. You must also reexecute any session customizations, in other words, ALTER SESSION statements, after failover has occurred. However, with TAF, a connection is not moved during normal processing, even if the workload changes over time.
Je crois qu'il faut éprouver la logical standby avant de "descendre" cette option.
pas si nouvelle que çà d'ailleurs (2002)
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
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager