Discussion :

[privatelab]

Le problème est principalement lié à deux caractéristiques des SGBDs.

1 : ils sont un SPOF (single point of failure) des archi classiques; c'est à dire que si le serveur sur lequel ils tournent tombe, alors il y a interruption de service
2 : ils ne sont pas scalable horizontalement

Pour répondre au point 1, le mode write-behind de coherence (par exemple) permet de masquer au serveur d'application une panne de la base, en accumulant et compactant les update en RAM et ce de manière distribuée; la base tombe, le système continue à vivre, les transactions aussi; la base remonte, les transactions sont flushées vers le SGBD.

Pour le point 2, ces technos de caches transactionnels permettent des choses assez surprenantes comme la capacité d'aggréger plusieurs mises à jour en une seule; exemple, une transaction effectue deux ordres SQL update sur la même ligne; coherence est capable de les compacter en un seul; multipliez cela par des milliers voire des millions de transactions et vous vous apercevez que le nombre de hits sur la base est considérablement réduit; ce qui améliore d'autant les performances générales du système; comme une partie de la gestion de la persistence est faite par les serveurs d'applications et que ceux-çi peuvent se clusteriser, le système est alors scalable horizontalement.

Quant au domaine d'application, il s'agit juste de d'applications de front office bancaire et/ou de gestion de flux financiers; rien de sorcier.

Cordialement,
Laurent.

[Fabien Celaia]

Le problème est principalement lié à deux caractéristiques des SGBDs.

1 : ils sont un SPOF (single point of failure) des archi classiques; c'est à dire que si le serveur sur lequel ils tournent tombe, alors il y a interruption de service
2 : ils ne sont pas scalable horizontalement

...
Cordialement,
Laurent.

=> à quoi servent alors, les technologies cluster, les modules haute disponibilité, les réplication warm/hot standby ?

[orafrance]

Si Oracle tombe, le système continue de fonctionner de manière transparente. En revanche, si un des solaris tombe, le système est conçu pour que les 29 autres se répartissent la charge sans broncher et sans pertes d'infos.
L'EASDAQ comme d'autres bourses sont effectivement très en avance par rapport à ce que l'on peut trouver ailleurs et leur architecture est un assemblage de middleware plutôt sophistiqués comme Tibco pour la messagérie asynchrone publish/subscribe et un data grid propriétaire.
Les SGBDR traditionnels continueront encore longtemps d'être le SPOF de nos architectures sauf dans les cas (comme celui que je viens de décrire) où l'on ne peut pas s'arrêter de travailler.

Bonjour, il me semble que vous devriez vous intéressez à la 9i RAC parce que, sauf erreur de ma part, il n'est pas question d'une quelconque limite dans le nombre de node. Par ailleurs, une archi en avance alors que la clusterisation du SGBD n'est pas mise en place et qu'aucune solution de haute dispo n'est mise en oeuvre (la Standby database par exemple pourrait profiter à cette archi ) désolé mais c'est pas très efficace pour moi

[orafrance]

ou encore de la 10g Unbreakable !!!.

c'est la 9i qui est unbreakable... et force est de constater que j'ai jamais eu à déplorer de perte de données malgré des incidents TRES pointu

Décidément, je crains que vous ne maitrisiez pas complétement le sujet

Oracle ne s'engage jamais sur une dispo de 100% sur 8 heures de suite, tout simplement parcequ'ils ne maitrisent pas le hardware et que ni SUN, ni HP, ni IBM ne s'engagent non plus sur la panne 0.

En effet, il préfère s'engager sur une dispo 24h/24 7j/7

il y en a toujours au moins une qui 'tombe' tous les mois et lorsqu'il s'agit d'une machine qui héberge une base (Oracle, DB2, Sybase, SQLserver...) il y a toujours une interrruption de service. C'est un fait indiscutable.

Bien sûr que c'est discutable, en RAC la perte d'une node ne cause aucune perturbation... bien sûr il faut y mettre les moyens et surtout les bonnes personnes

Je re-affrime que certaines archi, sont obligées de faire sans SGBD pour les raisons que j'ai déjà expliquées; ce qui ne veut pas dire que c'est le cas de toutes les archi.
Les SGBDR répondent à bcp de besoins, mais pas à tous. point.

BNP, Banque Populaire, caisse d'épargne et crédit agricole travaille toutes sous Oracle (et Sybase)... croyez-vous qu'elles se permettent d'assumer des interruptions de service ? Restons sérieux, vous avez UNE expérience différente mais loin d'être exemplaire puisque de votre propre aveu, vous êtes incapable d'assurer un service continu

[privatelab]

Bonjour,

vous insistez .... et moi aussi.

Donnez-moi un exemple d'application avec Websphere ou Weblogic devant Oracle avec RAC sur plus de deux noeuds....

Montrez-moi un contrat dans lequel Oracle promet une dispo 100% 24/24, 7/7...

RAC est une véritable saleté complètement propriétaire qui génère des codes retours obscurs non JDBC compliant (je veux parler des codes TAF, transparent application failover).
Et pour parler de leur driver JDBC, c'est une vrai farce...OCI ou thin ? même Oracle est flou sur cette question.
Posez-leur la question sur les fonctions "batchupdate" de leur drivers JDBC...
Demandez-leur comment sont gérés les blobs à partir de JDBC...
et je ne parle pas du mode XA complètement buggé et desesperement lent...
Non, avoir Oracle en RAC et avec du J2EE devant ça fonctionne mal et si cela fonctionnait, de toute façon, à moins que vous me trouviez un contre exemple, RAC sur plus de 2 machines, c'est juste du marketing.

Franchement, je n'aime pas trop le ton condescendant de vos réponses...
du genre : nous - les experts SGBD - nous sommes intouchables du haut de notre savoir faire sacré.
Que vous le vouliez ou non, des architectes, des ingénieurs brillants, mettent en oeuvre des solutions qui leur évitent d'avoir à supporter le mépris que certains DBAs affichent à l'égard des développeurs.
Il y a un monde, où le DBA, n'est qu'un mal necessaire et dans lequel il ne peut plus faire le courageux pompier quand les mauvais développeurs ont codé du mauvais SQL.
Prennez du recul, investiguez et regardez juste à côté de votre chapelle.
Chez Oracle, il y a toplink, mais bien sûr vous n'avez pas une demi idée de ce que produit peut faire, c'est de l'objet....bouhhh.
En fait, le ton de vos réponses montre à quel point vous sentez le danger et refusez d'admettre que faire carrière sur une seule techno, un seul produit est un risque...
Concernant mes expériences : elles sont bien réelles, ne reflètent pas la majorité des cas.

Et oui, chez BNPParibas (où je travaille depuis 10 ans), aucun des SLAs ne garantit du 100% de dispo....et le business tolère des interruptions de services....et je n'ai pas dit pertes de données...encore heureux !

Mais, je suis sûr que ce dialogue de sourd ne va pas s'arréter là...


Cordialement,

Laurent.

[orafrance]

Franchement, je n'aime pas trop le ton condescendant de vos réponses...
du genre : nous - les experts SGBD - nous sommes intouchables du haut de notre savoir faire sacré.

Ce n'est pas du tout le cas et veuillez m'excuser si c'est ce que j'ai laissé croire. En revanche, permettais moi d'émettre des doutes sur votre analyse, n'ayant moi-même jamais rencontré de problème de ce type alors que vous n'apportez aucun élément probant.

Que vous le vouliez ou non, des architectes, des ingénieurs brillants, mettent en oeuvre des solutions qui leur évitent d'avoir à supporter le mépris que certains DBAs affichent à l'égard des développeurs.

Et bien que vous le vouliez ou non, il est tout à fait possible d'avoir une qualité de service continue sous Oracle même sans le RAC

Prennez du recul, investiguez et regardez juste à côté de votre chapelle.
Chez Oracle, il y a toplink, mais bien sûr vous n'avez pas une demi idée de ce que produit peut faire, c'est de l'objet....bouhhh.

Je ne comprends pas Vous pensez que je hais l'objet parce que je travaille sous Oracle ? Je vous rassure, je suis très conscient qu'un SGBD sans IHM n'a pas grand intérêt
Par ailleurs, ayant été moi-même développeur, je connais bien les travers de ce métier et en effet, ces développeurs ont du mal à me mener en bateau

Et oui, chez BNPParibas (où je travaille depuis 10 ans), aucun des SLAs ne garantit du 100% de dispo....et le business tolère des interruptions de services....et je n'ai pas dit pertes de données...encore heureux !

Non, en salle des marchés une interruption de service n'est pas tolérable

Mais, je suis sûr que ce dialogue de sourd ne va pas s'arréter là...

Si vous voulez bien garder votre calme et argumenter d'avantage je suis sûr qu'on pourra mener un débat intéressant pour tout le monde. Si en revanche vous préfèrez asséner vos vérités sans tolérer la critique, en effet, la discussion est close

[Maître Kenobi]

pour alimenter ce débat, et pour qu'il reste constructif et argumenté, ce serait bien que chacun des pros, ici, nous donnent des faits, des exemples vécus, factuels, etc.
Merci pour les newbies comme moi qui se délectent d'apprendre des choses dans ce post !

[privatelab]

Bonjour,

c'est un vrai dialogue de sourd...
vous ne répondez pas à mes questions.
Dans un post vous me parlez de RAC, dans le suivant, je vous en donne mon expérience, et dans la réponse qui suit vous me dites que l'on peut faire sans...je suis perdu.

En salle de marché, ils font ce qu'ils peuvent et si vous relisez un de mes posts, vous verrez que c'est justement là qu'à Chicago et à l'EASDAQ, ils mettent en place des archis où la base est un accessoire.

quant au éléments probants, il faut me croire sur parole, où alors on se donne rdv pour en causer autour d'une bierre; je commence à me lasser de ne pas pouvoir parler directement.

Je vous envoie mon numéro de portable sur votre mail perso si je le trouve....ou si vous me le donnez.

Cordialement,
Laurent.

[Maître Kenobi]

excusez mon ignorance, mais c'est quoi RAC ?

[orafrance]

excusez mon ignorance, mais c'est quoi RAC ?

C'est un systéme de clusterisation. La base de données tourne sur plusieurs serveurs, ainsi, si l'un d'eux est défaillant, les autres assument sa charge

[orafrance]

Bonjour,
Je vous envoie mon numéro de portable sur votre mail perso si je le trouve....ou si vous me le donnez.

Même si l'invitation est sympatique ça n'aidera pas nos lecteurs

Vous voulez du probant ? En voila :

- Nombre de nodes supporté par 9i RAC : http://www.etagon.com/products/faq.html#faq13
http://www1.ap.dell.com/content/topics/topic.aspx/ap/topics/alliances/en/oracle_solution?c=au&l=en&s=bsd&~tab=4

- Haute dispo : http://www.dbasupport.com/oracle/ora9i/rac.shtml

Par l'exemple : http://www.oracle.com/global/fr/customers/profiles/ghh.html?_template=/ocom/ocom_item_templates/ocom_blank_template_with_site_cat

Les solutions au niveau SGBD existe bel et bien

[orafrance]

A noter que je n'ai rien trouvé sur une quelconque dégradation des perfs... le problème que vous avez rencontré vient peut-être uniquement d'une mauvaise version des drivers ou une mauvaise utilisation

[privatelab]

Bonjour,

le seul exemple que vous me donnez, celui du Groupe Hospitalier du Havre est très clair sur deux points que je m'acharne à défendre depuis le début de ce forum.

Je cite l'article :

1 :

[...] comprend 2 serveurs HP ES 45 (Tru64 sous Unix) en cluster, équipés de Oracle 9iRAC qui assure la haute disponibilité, 7j/7 et 24h/24

il n'y à donc que 2 noeuds Oracle et même si 'Officielement Oracle en supporte 64', la réalité est bien celle que je décris : 2 noeuds en pratique.

2 :

[...] En cas de sinistre, l'infocentre est arrêté automatiquement et les applications critiques prises en charge : La bascule d'un site sur l'autre ne requiert que quelques minutes

ah ? et que se passe-t-il pendant ces quelques minutes de bascule ? il y a interruption de service ! ok, pendant qques minutes seulement mais cela suffit à montrer que je n'ai pas totalement tort

De plus, ce que j'attends ce sont des exemples que vous avez vécus et non pas le résultat d'une requête google...
Les exemples que je donne sont des cas réels, que j'ai vus de mes yeux; ils reflètent cette réalité que vous ne voulez pas voir : il y a de la place pour des archis où la base est juste un accéssoire.

Maintenant, d'après ce que je lis, nos amis du Groupe Hospitalier vont tenter de mettre des serveurs J2EE devant leur base

[...] dont cinq dédiés à de futures applications J2EE

(à noter que pour l'instant, ils sont en client-serveur)....et là, je leur souhaite vraiement du courage.

Ils vont mettre le pied dans un monde étrange, où ils vont tomber sur les problèmes que je décris avec les drivers JDBC d'Oracle, sans parler de la gestion des codes TAF et du réglage des moniteurs JTA de leur serveurs d'application censés coordonner les transactions.

Merci pour cet exemple, qui va exactement dans mon sens.

Cordialement,
Laurent.
[/i]

[orafrance]

il n'y à donc que 2 noeuds Oracle et même si 'Officielement Oracle en supporte 64', la réalité est bien celle que je décris : [b]2 noeuds en pratique.

Bah oui, la probabilité que les 2 nodes tombent en même temps est tellement faible qu'elle ne justifie pas le cout d'une 3° node... c'est évident mais c'est juste une problèmatique financière

ah ? et que se passe-t-il pendant ces quelques minutes de bascule ? il y a interruption de service ! ok, pendant qques minutes seulement mais cela suffit à montrer que je n'ai pas totalement tort

Pendant ces quelques minutes, les transactions en cours sont jouées sur le nouveau noeud et les utilisateurs mis en attente, mais le principal est bien qu'aucune transaction n'est perdue

De plus, ce que j'attends ce sont des exemples que vous avez vécus et non pas le résultat d'une requête google...

J'ai vu le même type d'archi à l'hopital Ambroise Paré à Marseille

Les exemples que je donne sont des cas réels, que j'ai vus de mes yeux; ils reflètent cette réalité que vous ne voulez pas voir : il y a de la place pour des archis où la base est juste un accéssoire.

Et j'ai jamais soutenu le contraire. Il y a bien une différence entre : "les SGBD vont disparaitre" et "il existe des alternatives aux SGBD"

Ils vont mettre le pied dans un monde étrange, où ils vont tomber sur les problèmes que je décris avec les drivers JDBC d'Oracle, sans parler de la gestion des codes TAF et du réglage des moniteurs JTA de leur serveurs d'application censés coordonner les transactions.

J'ai travaillé pour un client qui utiliser Oracle Fail Safe sous windows pour gérer les pertes de dispos d'un serveur Oracle (SGBD + AS) et 9iAS est un serveur appli J2EE si je ne m'abuse. Et bien ça marchait parfaitement, grace au packaging d'Oracle

Merci pour cet exemple, qui va exactement dans mon sens.

quand on peut aider

[Maître Kenobi]

il n'y à donc que 2 noeuds Oracle et même si 'Officielement Oracle en supporte 64', la réalité est bien celle que je décris : 2 noeuds en pratique.

quelqu'un aurait-il un exemple de plus de 2 noeuds ?

[orafrance]

personnellement je n'en connais pas et comme je l'ai dit ça parait moyennement intéressant. En effet, le RAC ne sert quasiment qu'à la haute disponibilité puisqu'Oracle propose des mécanismes suffisant pour les perfs sans avoir à migrer en RAC. Du moins, c'est ce que j'ai observé

[orafrance]

J'ai relu ceci :

Leur archi repose sur un cluster d'une trentaine de machines SOLARIS qui gèrent en RAM et dans des files d'attente de messages, des transactions temps réel sur 8TO de datas.
Oracle n'est qu'un accéssoire vers lequel sont flushées à intervalles réguliers ces 8TO, et le SGBD ne sert qu'à des fins de consultations épisodiques pour régler des litiges.
Si Oracle tombe, le système continue de fonctionner de manière transparente. En revanche, si un des solaris tombe, le système est conçu pour que les 29 autres se répartissent la charge sans broncher et sans pertes d'infos.

Comment récupérer les données de la RAM du serveur qu'est tombé ? Si le serveur redémarre la RAM se vide

Ni Oracle, ni IBM, ni Microsoft ne savent proposer des clusters à plus de 4 machines

On est bien d'accord que c'est une erreur au moins pour Oracle ? Techniquement, c'est possible

[quote]Pour enfoncer le clou, un cluster de SGBDR aussi solide soit-il est toujours soumis aux I/O physiques et mêmes les baies de disques les plus performantes du type EMC montrent leur limites en forte charge.[quote]

Et la répartition de charge alors ??? tu peux aussi "clusteriser" les disques

Et je pourrais ajouter que les techno de clustering SGBDR limitent la distance physique entre deux noeuds à quelques centaines de mètres tout au plus en mode de réplication synchrone.
Aucune de ces limites n'existent avec du cache transactionnel distribué : le nombre de noeuds, leur distance sont illimités (toutes proportions gardées) et quant au I/O, ils ne sont plus disques mais RAM.

Comment ne pas mettre les serveurs les uns à coté des autres si on mutualise les données contenues dans les RAM ? Quel avantage par rapport aux baies de disques ? je ne comprends pas

[privatelab]

Bonjour,

on tourne un peu en rond....
je me suis déjà expliqué sur le titre provocateur.
Je n'ai pas d'autre prétention que de présenter des alternatives...

mais on peut continuer longtemps : si la provoc est un de mes traits de caractère, la ténacité en est un autre.

Concernant le temps de bascule pendant lequel les transactions sont suspendues :
si elles sont coordonnées par un serveur d'app J2EE, alors fonction du réglage du timeout de JTA, le container J2EE peut décider de rollbacker ces transactions.
Ensuite se pose la question de les rejouer dès que le site de secours prend le relais.
et cela devient compliqué, parceque si des transactions - tombées en timeout - sont rollbackées, il faut une intervention manuelle, généralement qqun qui connait le métier de l'appli pour décider de l'action à prendre.
Donc, en théorie, le temps d'indispo est de quelques minutes : en pratique ce temps est allongé par ce genre de décision 'humaine'.

et vous ne me répondez toujours pas sur comment un container J2EE gère correctement les codes TAF, condition indispensable pour un fail-over transparent...

ni non plus sur le fait que les drivers Oracle (le thin et l'OCI) ne sont pas JDBC compliant...


Cordialement.
Laurent.

[orafrance]

et vous ne me répondez toujours pas sur comment un container J2EE gère correctement les codes TAF, condition indispensable pour un fail-over transparent...

ni non plus sur le fait que les drivers Oracle (le thin et l'OCI) ne sont pas JDBC compliant...

Je ne connais pas la partie applicative donc je ne peut pas me prononcer

Mais si le problème est J2EE alors je réponds que c'est de l'interfaçage et qu'en aucun cas le base de données n'a une quelconque responsabilité là-dedans. En client/serveur ça marche très bien, si ce n'est pas le cas en J2EE je ne vois pas en quoi ce serait la faut du SGBD

Si les drivers Oracle ne sont pas JDBC compliant quel est l'impact parce que j'ai jamais entendu personne s'en plaindre : développeurs ou architectes J2EE

[privatelab]

Bonjour,

le clusters de Solaris à l'EASDAQ fonctionne car le contenu de la RAM est répliqué sur tous les noeuds du cluster; si un des serveurs tombe, peu importe, les autres ont les données en mémoire et lorsqu'il remonte, sa RAM se resynchronise avec les autres RAM du cluster.
Par ailleurs, la techno de clustering et de réplication de la RAM permet de s'affranchir des limites physiques liées au bases.
Les serveurs qui partagent leur RAM n'ont pas besoins d'être proches.
C'est vrai que c'est hors normes comme archi, mais elle a le mérite de fonctionner.
Ce lien http://www.webservices.org/index.php...iew/full/74791 présente une autre utilisation du logiciel Coherence de Tangosol.
Cet exemple est un peu en marge de notre discussion, mais il met en avant les capacités de cluster distribué en RAM et sur des WAN.

Cordialement,
Laurent.