Version imprimable
Bonjour à tous,
Je souhaiterai connaître le moyen le plus approprié et le plus sûr, selon vous, pour effectuer quotidiennement des mises à jour depuis une base Oracle (actuellement en version 8.1.7) vers une future base SQL Server qui sera installée sur un serveur distant.
En outre, je devrai aussi rapatrier des mises à jour effectuées sur la base distante.
Volumétrie estimée : 500 ordres DML (Select, Insert, Update et Delete) par jour
Merci d'avance.
L'idéal serait de faire la chose avec SSIS de SQL Server 2005
Si c'est oracle qui doit piloter, les Transparents Gateways semble appropriées
Citation:
Envoyé par http://download-east.oracle.com/docs/cd/B19306_01/server.102/b14220/integrat.htm#i16394
Pour des raisons de sécurité, c'est effectivement la base Oracle (base maître) qui pilotera les mises à jour.
La solution Transparent Gateways me paraît très intéressante. Elle mérite d'être "creusée"... Merci.
Ceci dit, la citation fait référence à un guide administrateur Oracle 10g, sauriez-vous si cette solution peut exploitée en 8.1.7 ou si je dois migrer ma base en 10g ?
Avez -vous commencé par chercher dans la doc 8i ? ;)
Pensez bien ! Sinon, je ne serai pas là à vous faire perdre votre temps !!! Le problème, c'est que non seulement je n'ai pas les compétences d'un DBA comme vous, mais en plus je n'ai pas la moindre Doc en 8i.
En revanche, j'ai fait mes recherches sur le net, à partir de votre citation : J'ai d'abord trouvé une matrice de certification qui n'évoquait que les versions 9iv2 et 10g. D'où mon doute... D'où ma question...
Non satisfait, par la suite, j'ai ciblé un peu plus mes recherches sur la version 8i et j'ai effectivement entendu parlé d'Heterogeneous Gateways depuis la version 8.0. Mais à chaque fois : j'entends disserter de Transparent Gateways sur trois lignes et de Generic Gateways (la version ODBC, dont le réputation s'est construite sur sa lourdeur et sa lenteur) sur trois pages. Je me permets donc (par expérience) d'émettre quelques doutes quant à la mise en oeuvre réelle d'un tel protocole entre une base Oracle 8.1.7 et une base SQL Server 2000, voire 2005 :? :pleure: .
Ceci dit, il va bien falloir que je migre un jour ou l'autre... Mais c'est d'abord un problème de coup de license (qui explique aussi le choix de la base distante). D'autant que cela impliqiue ensuite une migration de tout l'applicatif client/serveur exploitant cette base. Donc on repousse, on repousse encore et encore...
Dans ma signature, il y a un lien vers http://tahiti.oracle.com qui présente les doc 8i, 9i et 10g ! ;)
mais effectivement, en 8i, je crains qu'il ne faille passer par l'ODBC...
Bonjour,
Je m'excuse de revenir à la charge, mais je reste toujours à la recherche de LA meilleure solution technique idéale, à moindre coût !!!
Dans mon 1er message, j'avais évoqué la solution SQL Server, parce qu'elle me paraissait la moins pire, mais peut-être que je me trompe...
Voilà donc le tableau complet : l'objectif est de monter un extranet (techno orientée OpenSource : Java, Apache, Tomcat). Pour des raisons de sécurités (évoquées plus haut), plutôt que d'attaquer directement la base centrale Oracle, on préfère assigner une base dédiée à l'extranet (amélioration des performances et à faible coût de license, car jugé prohibitif concernant Oracle). La réplication des mises à jour entre ces 2 bases s'effectuera par un batch de synchro à l'initiative de la base centrale, durant la nuit (canal ouvert juste durant cette synchro). Et comme on n'est jamais trop prudent, l'IHM devra en outre attaquer sa propre base dédiée au moyen de procédures stockées qui se chargeront des contrôles d'intégrité des données.
Donc, dans un premier temps, j'avais exclu MySQL (because procédures stockées pas encore très bien implémentées) et j'avais opté pour la deuxième plus utilisée : SQL server. J'admets cependant que SQL Server s'associe mieux à une techno Dot.Net (native), bien que non rédibitoire concernant J2EE... Ceci dit, il est tout à fait possible à ce stade que le choix puisse se porter sur une autre base de données compatible !!! Tout ce qu'on lui demande c'est :
- d'avoir de bonnes performances avec des tables contenant plusieurs dizaines de milliers d'enregistrements,
- de bien gérer les procédures stockées,
- de pouvoir être prise en main à distance par un PL/SQL Oracle 8.1.7 avec d'excellents temps de réponse.
Voyez, je ne suis pas exigeant !!!
Auriez-vous un avis ou une expérience fructueuse dans ce domaine ?
Je suis conscient que tout cela sort un peu du forum Oracle. Comme tout ce qui touche à la communication en environnements hétérogènes, il est bien difficile de se positionner sur un forum ciblé... Et dans la cas présent, c'est Oracle qui pilote !
Donc, merci d'avance aux experts en tous genres ;)
LA meilleure solution pour transférer de manière maîtrisée et régulière des données entre 2 sources non homogènes est l'ETL selon moi.
C'est un logiciel qui possède des connecteurs natifs sur de nombreux formats de données (BDD Oracle, BDD SQLServeur, BDD DB2, Fichiers plats texte, Fichiers Excel, etc.) et qui offre (la plupart du temps) des possibilités de conversions natives. De plus ils offrent une administration et un contrôle de ce qui est programmé et de ce qui a été exécuté centralisé et plus "visuel" que ce qu'on peut faire avec la plupart des solutions offertes par les SGBD.
Il en existe des gratuits (Talend par exemple).
la meilleure solution c'est peut-être de s'adresser aux membres SQL Server non ? ;)
J'ai toujours entendu dire qu'un ETL servait à extraire les données dans différentes bases, de les transformer et enfin de les charger dans un entrepôt de données. Ce qui, dans ce cas, ne correspond pas vraiment à mon besoin (je me trompe ?).
Est-ce bien la solution appropriée pour faire de la réplication aller et retour sur 2 bases hétérogènes, qui plus est, modélisées différemment ?
Cher Fred,
Je suis réellement surpris de ta réponse. Justement, en tant que "Responsable SGBDR" (donc fédérateur entre les différents forums SGBDR), je m'attendais justement à un peu plus de synergie de ta part. A moins que tu ais une piste particulière vers laquelle tu souhaites m'orienter ???
Entre 2 bases modélisées différemment, c'est sûrement une technologie très adaptée. Elle est la seule (avec les scripts tapé à la main et batchés) qui te permet de gérer des transformations très complexes entre tes 2 bases (ce qui peut arriver si elles sont modélisées differement).Citation:
Envoyé par fbo33
Par contre ,avec un ETL, les modifications apportées sur ta base répliquées ne serait rappatriées que de temps en temps, et pas de manière instantanées, ce qui peut poser des problèmes de cohérence. Mais comme à la problématique :
tu ajoutes :Citation:
Envoyé par fbo33
Je te dirais que pour moi, l'ETL est une bonne solution. Un seul point négatif : le temps qu'il va te falloir pour trouver le bon, le monter, apprendre à t'en servir, etc.Citation:
Envoyé par fbo33
Et alors ? :koi: La synergie consiste également à renvoyer les membres vers un forum plus adapté. Dans les problèmatiques de migration d'un BdD à une autre, l'intelligence du process est en principe dans la cible. Ici, les outils seront donc probablement proposé par SQL Server.Citation:
Envoyé par fbo33
M'enfin... si tu veux le traiter dans Oracle absolument c'est comme tu veux... je ne suis qu'un petit responsable SGBD finalement :mouarf:
c'est bien à quoi je voulais répondre. Maintenant, je ne suis pas certain du tout que "pousser" les données soit le plus approprié... si vous souhaiter continuer dans cette voie alors très bien... mais ne compter pas trouver "LA" solution :?Citation:
Envoyé par fbo33
Citation:
Envoyé par Fred_D
Je suis entièrement d'accord avec Fred, dans la logique de la réplication c'est beaucoup plus simple quand c'est la cible qui demande les données. Par exemple dans la réplication Maitre-Esclave d'oracle, c'est l'esclave qui a l'initiative, le maitre n'est que consulté (on lui demande éventuellement de tenir des journaux à jour pour faire du DELTA mais c'est tout).
C'est encore plus vrai dans une logique de systèmes hétérogènes car il est bien plus facile et normalisé de consulter des données que de les modifier, donc sur le principe, il sera plus facile pour un outils SQL-Server de lire de l'Oracle que pour un outils oracle de d'écrire du SQL-Server.
Une autre raison est purement commerciale, un éditeur vous facilitera toujours la vie pour rapatrier des données d'un système extérieur vers le sien, et pas l'inverse (enfin il le fera peut etre mais pas de gaité de coeur...), il sont pas masochistes! :P
Exemple: Oracle fourni tout un tas d'outil pour migrer les autres bases de données vers son noyau: Migration-Workbench pour sybase, mysql, sql-server etc... par contre ça m'étonnerais qu'il fournisse un jour le moyen de transformer une base oracle en autre chose! :mouarf:
Moi aussi je suis tout à fait d'accord avec Fred, sur ce dernier sujet !!! (je suis d'ailleurs désolé que cela ait pu le froisser autant...) :yaisse2:
Mais, encore une fois, la question n'est pas là... :nono:
1) je dois répondre à des contraintes qui me sont imposées : C'est le maître (base Oracle) qui doit piloter la synchronisation entre les deux bases (et il ne s'agit pas ni de réplication ni de migration),
2) pour rappel, l'interface doit effectuer des mises à jour dans les deux sens, donc si Oracle n'est effectivement pas habilité à "pousser" les données vers SQL Server, je vois mal en quoi SQL Server le serait plus ! Implémenter deux interfaces ? Comment les synchroniser ? Comment gérer les conflits ?
3) n'ayant pas d'actions chez Microsoft, je suis prêt à étudier toute autre solution que SQL Server, du moment qu'elle soit fiable. A ce sujet, une solution Open Source aura ma préférence (pour de simples raisons de coût de license).
Encore merci à tous ceux qui apportent de l'eau à ce moulin...
1. un programme client avec les 2 connecteurs pour les 2 OS, c'est la croix et la bannière dès que l'on souhaite gérer les restaurations (incomplètes) de l'une ou de l'autre base. En plus, c'est lourd en terme de trafic réseau et à maintenir
2. Les sources de données hétérogènes ne vous conviennent donc pas ?
Il y a une nuance entre "pousser les donnée" et "piloter", tu peux tres bien imaginer une solution ou le maitre déclenche une action sur l'esclave, action de récupération de données... Je ne suis pas expert SQL-Server mais il doit etre possible de lier une table oracle via odbc non ?Citation:
Envoyé par fbo33
On a justement le même soucis et comme je l'ai dit dans ma réponse, je pense que SSIS est très bien adapté à ce type de flux de données. Un ETL est la solution. Reste à le maîtriser et à le paramétrer.
Pour ma part, je suis sur un projet qui doit faire communiquer notre base Oracle qui est la base maître avec une base SQL Server. Cette dernière fonctionnant avec un progiciel de production. Jusqu'à maintenant, on récupérait les données sous forme de fichier plat formaté et un programme Java/PL les intégrait dans la base. Nous avions la solution d'utiliser des outils très cher mais vu que Microsoft propose un ETL avec SQL Server et sans surcoût, je pense qu'il faut essayer ce produit. Pour ma part, j'en suis relativement satisfait bien que la prise en main au début n'est pas si simple. On peut aussi faire du temps réel et de la synchronisation dans les deux sens.
Je tiens particulièrement à remercier les personnes qui ont apporté des réponses constructives à mon problème (nuke_y et flonardi pour ne pas les citer)... A mon avis, après un certain nombre de recherches, la solution serait bien un ETL... J'en ai testé plusieurs (gratuits) et je pense avoir trouvé (mais je n'en suis pas encore complètement sûr) une solution viable à mon problème. Laissez moi juste un peu de temps pour vérifier tout cela et vous en faire les retours...
A+
PS: J'adore ce forum, c'est vraiment un site d'utilité publique... mais, à la lecture d'un grand nombre de messages, il serait bien que certains (et non des moindres) arrêtent les gargarismes car ça va finir par vous porter tort...
1) Malgré ton savoir, pour un Dieu tu ne te prendras,
2) Quelques soient tes connaissances, d'un internaute tu ne te moqueras,
3) Elastiques à l'infini, tes chaussettes ne seront pas...