Choix de transport d'intégration (Oracle + SQL Server)

Question

Nous avons plusieurs systèmes avec des bases de données Oracle (A) et SQL Server (B) en backend. Je dois consolider les données de ces systèmes dans la nouvelle base de données SQL Server.

Quelque chose comme ça:

(A) =>|---------------| 
     | some software | => SQL Server 
(B) =>|---------------| 

où certains logiciels est:

• transport (A et les systèmes B situés dans le réseau)

• traitement logique métier (sur mesure Code .NET)

En raison du premier point, j'ai besoin d'un logiciel de file d'attente ou quelque chose de similaire (comme MSMQ, Service Broker ou autre). D'un autre côté, je peux mettre en place un web-service au lieu de la queue. La question est la suivante: Quelle structure de file d'attente/de transport dois-je utiliser avec les bases de données Oracle et SQL Server?

Ce serait bien, si je peux envoyer des messages à MSMQ dans Oracle et SQL Server procédures stockées (puis-je?)

Ce serait bien, si je peux appeler un service Web dans Oracle et procédures stockées SQL Server (puis-je?)

ce serait bien, si je peux utiliser quelque chose de similaire dans les deux Oracle et SQL Server procédures stockées (quoi exactement?)

Quel logiciel dois-je préfère mon exigences?

UPD: certains TechSpec

Ce serait un processus de synchronisation régulière. Une fois par jour je pense.

La latence n'est pas critique (> 0,5-1 heure est ok).

Quantité de données: 1 à 50 Mo par synchronisation de chaque système.

Le cryptage est requis pendant le transfert.

Answer 1

Je suggère de créer un paquet SSIS qui transfère les nouvelles données du serveur A, B au nouveau serveur lorsqu'il est appelé. Vous lanceriez le package SSIS selon un calendrier, disons toutes les 30 minutes, à partir du nouveau serveur.

Si A et B sont tous les deux SQL Server, Service Broker prend tout son sens pour fournir une latence très faible. Mais avec l'un d'entre eux étant Oracle, et sans exigences en temps réel, il perd son attrait. En note, vous pouvez voir ici un exemple d'utilisation de Service Broker pour High volume real time contiguous ETL. Faire le transfert comme un paquet SSIS facilite la maintenance (vous pouvez modifier le paquet avec une relative facilité), il ne nécessite pas de changements invasifs dans le système existant, est assez performant et il y a une grande quantité de SSIS -how disponible en ligne.

Je vous conseille de ne pas utiliser MSMQ pour plusieurs raisons:

• lorsque la fiabilité des transactions est nécessaire, vous devrez impliquer toutes les opérations liées MSMQ dans des transactions distribuées (DTC entre le dequeue MSSMQ et l'insertion du serveur SQL/mise à jour sur le nouveau serveur) qui ralentira significativement le débit de traitement
• Vous aurez besoin de quelques lignes de code pour le marshaling/unmarshaling et le déchiquetage des messages de deltagram dans le système cible (je sais que le codage est amusant, mais SSIS est tout simplement meilleur dans ce genre d'emplois, et plus facile à maintenir)
• MSMQ limitation de 2 Go par file d'attente est assez faible dans le monde réel (remplit rapidement si votre trafic augmente et vous avez un temps d'arrêt d'entretien)

Le vrai problème que je serais inquiet au sujet est de savoir comment détecter les changements sur A et B: lorsque le travail SSIS arrive toutes les 30 minutes, comment sait-il quelles données sont nouvelles? Spécialement, comment il détecte les suppressions ...