Discussion :

[agerz70]

Bonjour,

J'ai 2 bases (SQL server 2008 R2) d'environ 2000km (base A et base B), je souhaiterais répliquer la base A (environ 200Go) vers la base B via internet (connexion peu sure) et les synchroniser ensuite. Les 2 bases doivent rester en lecture/écriture mais seule la base A sera répliquée sur B et les données de B ne se retrouveront jamais sur A.
Comment dois-je m'y prendre pour initier la réplication (impossible de transférer ou faire un instantanée via internet) je me déplace sur le site B et je peux donc transporter la base A ? Quelle(s) solution(s) serai(en)t la/les plus adaptée(s) pour répliquer mes bases et initier la réplication?
J'ai un peu de connaissances en réplication transactionnelle et alwaysOn mais je ne pense pas que ces 2 solutions soient adaptées de part l'instantannée de la première et la lecture seule de la 2eme base AlwaysOn ?

Merci d'avance pour votre aide !

[SQLpro]

Attention, le terme réplication est souvent mal compris. La réplication de données consiste à répliquer certaines données de certaines tables d'une base à l'autre pour des besoins fonctionnels
Est-ce bien cela que vous voulez faire ou bien avoir une base de données dupliquée afin de faire de la haute disponibilité ?

Bref, décrivez plus en avant votre besoin fonctionnel.

A +

[agerz70]

Merci de votre réponse rapide.

En fait je souhaite avoir des données à jour de ma base A sur ma base B (tout en gardant la base B en lecture écriture), ce qui correspond plutôt à de la réplication de données.
La fréquence de mise à jour des données peut être de plusieurs heures.
La haute disponibilité n'est pas ce que je recherche.
Fonctionnellement parlant, j'aurai 2 applications identiques sur les 2 sites que j'appellerai A1 et B2. L'application "mère" A1 requête sur la base A et l'application B2 sur la base B.
La base B doit avoir les données à jour de la base A (au moins 1 fois par jour) pour que les utilisateurs de l'application B2 est des données à jour.
La base B comme la base A doit être en lecture/écriture afin de permettre la mise à jour des tables systèmes de l'application.

J'espère m'être bien expliqué et exprimé sur ma problématique..... ?

Merci
@+

[SQLpro]

Cette réplication concerne-t-elle toutes les tables ou certaines ?

Si elle concerne toutes les tables, concerne t-elle toutes les lignes ou certaines ?

A +

[agerz70]

A ce niveau c'est un peu compliqué, car la mise à jour des tables systèmes de la base B peut avoir des conséquences sur l'application (en test en ce moment).
L'idée de départ est de mettre à jour toutes les tables (quitte à mettre "en stand by" l'application à laquelle personne n'accèdera la nuit).
Si l'impact de la mise à jour des tables systèmes est néfaste, nous devrons les exclure de la réplication....
Pour les lignes, exemple d'une table client (ou commande) dont n'importe quel client peut être mis à jour, donc toutes les lignes peuvent être impactées.

Je pensais au log shipping mais sans en avoir mis en place je ne sais pas si c'est la solution adaptée ?

Merci !

[SQLpro]

Au lieu de dire base A base B donnez nous votre besoin fonctionnel et en terme PRÉCIS, car là vous faite fausse route. Vous parlez de tout un tas de chose sans comprendre les enjueux :

• vous ne pouvez pas répliquer les tables système. Il n'y a aucun accès d'ailleurs aux tables système dans SQL Server
• Le Log Shipping sert exclusivement à faire de la haute dispo

A +

[agerz70]

Ok je comprends.
Pour être clair, l'application est un CRM qui doit être dupliqué sur un nouveau site à l'identique du site principal. L'application CRM sera installée sur le nouveau site pour un fonctionnement autonome.
Les données de la base du nouveau site devront être identique au site principal 1 à 2 fois par jour.
Quand je parle de tables systèmes se ne sont pas les tables des bases systèmes de SQL server mais celle de l'application, contenues dans la base de données CRM, utiles au fonctionnement de l'application.
Les tables de la base de données du site maitre ne recevront jamais de données du site distant.

Effectivement la haute disponibilité n'est pas l'objectif mais plutôt l'autonomie du nouveau site avec une réplication de données journalière.

En espérant avoir été plus clair.
Merci pour votre aide

[SQLpro]

Parlez alors de tables de référence et pas de tables système, ou encore de tables techniques ou d’administration...

2 possibilités :
si les donnes sont en petites quantités (quelques milliers de lignes au plus pour chaque table) => réplication snapshot
si les données sont en grande quantités => réplication transactionnelle
Vous pouvez marier les deux :
snapshot pour petite table
transactionnelle pour grosses tables.

A +

[agerz70]

Merci SQLpro, je vais alors approfondir ces options
Bonne journée