Mise à jour de bases de données distantes, de manière incrémentale

[Glouferu]

Bonjour,

On vient de me refiler une patate chaude, avec laquelle je ne suis pas d'accord mais qui a malheureusement été validée en CODIR...

Le besoin :

• Mettre à jour les bases de données SQL de 7 PC portable
• Les PC sont déconnectés du réseau 98% du temps
• La synchronisation sera réalisée à travers le VPN
• La mise à jour des données doit être incrémentale pour que la mise à jour ne dure pas trop longtemps (les pauvres )

Je pense avoir 3 options :

1. Mettre en place une réplication : Quel type serait le plus interessant ?
2. Mettre en place un script SQL à base de RESTORE LOG ?
3. Mettre en place un flux à l'aide d'un E.TL. ?

Maintenant, même si je réussi à synchroniser les données, j'ai peur que la maintenance soit vraiment impossible (changement de structure, maintenance, pas la main sur le pc ... etc).

Avez-vous des idées ? Quelle serait la meilleurs solutions ? Avez-vous déjà rencontré ce genre de problématique ?

Par avance,
un GRAND Merci !

[serge0934]

j'ai eu ce pb il y a 3 ans pour une banque privée dont les commerciaux avaient un portable et se déplaçaient chez les "gros clients".

j'ai essayé la réplication en pull (à la demande) => ko
des backup restore compressé => trop long

j'ai fini par faire un petit soft qui transmets des scripts transac sous forme texte par ftp quand le commercial se connecte, ceux ci sont ensuite exécuté sur le PC du commercial.

pour générer ces fichiers, j'ai mis sur toutes les tables des triggers en insert/update/delete.

c'est fastidieux mais c'est top en souplesse, rapidité, tout ce que tu veux

[Jinroh77]

Maintenant, plutôt que les triggers, tu peux utiliser le CDC sur ta base maitre.

[Glouferu]

Envoyé par serge0934

pour générer ces fichiers, j'ai mis sur toutes les tables des triggers en insert/update/delete.

c'est fastidieux mais c'est top en souplesse, rapidité, tout ce que tu veux

Envoyé par Jinroh77

Maintenant, plutôt que les triggers, tu peux utiliser le CDC sur ta base maitre.

J'avais commencé plus ou moins la même chose en gérant des Insert / Update / Delete à l'aide d'un composant Map_Opration avec mon ETL SAP Dataservices.

Le problème c'est qu'on m'a annoncé que la structure risque de changer régulièrement
Du coup j'ai pas forcément envie de changer le SQL à la main à chaque fois

[serge0934]

quand je disais toutes les tables, c'est TOUTES, y compris syscolumns, sysobjects, sysindexes....

[serge0934]

en plus pour éviter de te rettaper "à la main" des triggers, il faut faire une requête qui te les génère ex:

Code :

1
2
3
4
5
6
7
8
9
10
11
 
SELECT 'insert into table ('+
case
when xtype=52 then champ1
when xtype=56 then champ1
when xtype=58 then champ1
when xtype=167 then '''+champ1+'''
....
FROM sysobjects
JOIN syscolumns
JOIN systypes...

[SQLpro]

Envoyé par serge0934

en plus pour éviter de te rettaper "à la main" des triggers, il faut faire une requête qui te les génère ex:

Code :

Les tables que vous citez sont en version 2000; En version 2005 et supérieurs elles en contiennent pas les bonnes données et de plus la mise à jour des tables systèmes dans les version 2005 et 2008 n'est plus supportées.

La solution consiste à faire au moins deux flux de réplication :

• une transactionnelle de serveur central aux poste pour les structures et les éventuelles données de référence
• une snapshot ou transactionnelle des données des postes nomades vers le serveur central.

Tout dépend des besoins fonctionnels.

A +

[serge0934]

Les tables que vous citez sont en version 2000

euh... cela fait deux ans que j'ai des procs qui tournent 2008R2 avec sysobjects, syscolumns,etc...
ce n'est peut être plus supporté officiellement, mais cela fonctionne toujours

La solution consiste à faire au moins deux flux de réplication :

une transactionnelle de serveur central aux poste pour les structures et les éventuelles données de référence
une snapshot ou transactionnelle des données des postes nomades vers le serveur central.

je suis ariègeois, essayez de faire passer une snapshot d'une base de même 2go
au travers d'une adsl qui fait par grande chance du 512ko

je suis d'accord si les PC peuvent se connecter a un réseau rapide

mon grand père disait toujours "il vaut un bon vélo qu'une mauvaise mobylette; essaye de faire 20km (en ariège avec les montagnes) avec une mobylette sans essence..."

[SQLpro]

Envoyé par serge0934

euh... cela fait deux ans que j'ai des procs qui tournent 2008R2 avec sysobjects, syscolumns,etc...
ce n'est peut être plus supporté officiellement, mais cela fonctionne toujours

Il suffira de mettre en place un type DATE, TIME ou DATETIME2, un index filtré ou un partitionnement pour que les données soient fausses. Vous ne verrez rien, mais certaines données ne seront pas répliquées...

je suis ariègeois, essayez de faire passer une snapshot d'une base de même 2go
au travers d'une adsl qui fait par grande chance du 512ko

je suis d'accord si les PC peuvent se connecter a un réseau rapide

mon grand père disait toujours "il vaut un bon vélo qu'une mauvaise mobylette; essaye de faire 20km (en ariège avec les montagnes) avec une mobylette sans essence..."

On ne réplique pas toute une base... C'est insensé !

On réplique des articles, qui sont un croisements de colonnes et de lignes.

je crois que vous avez un problème de conception !

De plus on peut compresser un snapshot.

A +

[serge0934]

SQL Pro, je suis d'accord, mais dans la pratique, le cas tordu existe toujours et c'est toujours sur un big boss que cela tombe; je m'explique:

dans mon cas, on avait une replication par abonnement en pull. un jour, le directeur commercial, qui ne s'était pas connecté depuis 6 mois, a voulu aller chez l'un des plus gros client et la réplication n'a pas fonctionnée car la ligne (réseau) n'était pas suffisante, et un abonnement récupère tout ou rien car c'est une transaction globale.

Dans le petit soft que l'on a mis en place par la suite, il faut peut_être le "lancer" plusieurs fois pour qu'il récupère tout, mais à la fin on est sur d'avoir tout.

[Glouferu]

Envoyé par serge0934

SQL Pro, je suis d'accord, mais dans la pratique, le cas tordu existe toujours et c'est toujours sur un big boss que cela tombe; je m'explique:

dans mon cas, on avait une replication par abonnement en pull. un jour, le directeur commercial, qui ne s'était pas connecté depuis 6 mois, a voulu aller chez l'un des plus gros client et la réplication n'a pas fonctionnée car la ligne (réseau) n'était pas suffisante, et un abonnement récupère tout ou rien car c'est une transaction globale.

Dans le petit soft que l'on a mis en place par la suite, il faut peut_être le "lancer" plusieurs fois pour qu'il récupère tout, mais à la fin on est sur d'avoir tout.

C'est justement parce que les personnes qui doivent récupérer les données à distances sont des divas que je suis d'autant plus méfiant et contre lla réalisation de ce projet ...
J'ai peur que ça me revienne très fort dans la gueule quand ça ne fonctionnera pas !

Envoyé par SQLpro

La solution consiste à faire au moins deux flux de réplication :

• une transactionnelle de serveur central aux poste pour les structures et les éventuelles données de référence
• une snapshot ou transactionnelle des données des postes nomades vers le serveur central.

Tout dépend des besoins fonctionnels.

Je peux essayer de mettre en place une réplication de données transactionnelle pour la structure et les data.

Je ne souhaite pas récupérer leur données, donc une seule transaction devrait fonctionner. Maintenant, la connexion montante n'est pas exceptionnelle ! Elle est d'autant plus bridé que les données transistent par le VPN.

Je pense qu'au mieux, je vais avoir du 30 kilo/sec.