Bonjour,
Comment peut-on réaliser la consolidation des 7 BDD en une seule?
Cela se fait (saisie) manuellement ou par un outil de développement?
et si c'est oui, (par un outil de développement) alors comment le faire avec VB.Net?
Bonjour,
Comment peut-on réaliser la consolidation des 7 BDD en une seule?
Cela se fait (saisie) manuellement ou par un outil de développement?
et si c'est oui, (par un outil de développement) alors comment le faire avec VB.Net?
En utilisant au choix :
- la réplication (transactionnelle par exemple)
- service broker
ces deux mécanismes étant full SQL il n'y a pas de .net à écrire.
A +
Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
* * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *
J'ai une petite idée en ce qui suit ... mais ts d'abord veuillez m'expliquer un peu plus ...
L'idée 1: On peu utiliser 7 scripts SQL de 7 bases (SQL Serveur 2005), concevoir un script pour notre nouvelle base a consolider, l'idée est la mais je n'arrive pas a l'appliquer ... !!!
L'idée 2: Faire un script intermédiaire entre les 7 bases et la nouvelle base.
aussi l'idée n'est pas claire a 100%.
L'idée 3: Travailler avec l'outil Intégration Services de SQL Server.
l'idée n'est pas claire a 100%.
Merci encore ...
Bonjour,
Dans votre cas comme le dit SQLPro la réplication peut être une solution à votre problème en utilisant une topologie abonné centrale (votre base consolidé) ,plusieurs publicateurs (les 7 bases de données) et une réplication transactionnelle par exemple .
La documentation msdn fournit pas mal d'exemples concernant la réplication
++
Bonjour,
J'ai la même problématique que bluerequin, cad consolider 2 BDs en une pour un serveur de reporting, et j'ai pensé à la réplication transactionnelle pour résoudre ce cas.
Mais (il y a toujours un mais), mon niveau en architecture de réplication n'est pas suffisant pour répondre aux questions que je me pose, alors je suis preneur de toutes les infos/conseils que vous auriez.
Dans le cas où un abonné central C est branché sur 2 publications identiques mais où seuls les publishers sont différents (A et B pour l'exemple), comment peut-on initialiser les 2 réplications sachant que les DB sur A et B peuvent déjà contenir déjà des données ? J'ai du mal à visualiser une initialisation par backup ou par snapshot de 2 réplications sur une même base de données.
Même question pour la validation de données de réplication.
Merci pour votre aide
Bonsoir,
Si vous avez une topologie abonné centrale avec 2 publicateurs distincts avec réplication transactionnelle, vous devez avoir pour vos tables concernés une clé primaire unique.
Quoit qu'il en soit, dans le cadre de la 1ère initialisation, vous créez votre 1ère publication avec une phase d'initialisation (création d'un snapshot). La 2ème publication, quant à elle, doit se faire sans cette 1ère phase. Vous n'aurez donc que l'agent de lecture du journal et l'agent de distribution qui seront concernés par le processus d'alimentation des tables concernés par vos publications et abonnement.
++
Partager