Discussion :

[sim3val]

Bonjour,

Je cherche à améliorer une solution de "réplication maison" en place depuis quelques années, et je préfère demander un avis aux pros.

Notre fournisseur principal utilise une base de données SQL-Server (on va l'appeler BASE) et j'ai accès à ce serveur en lecture (ainsi qu'en écriture, mais je ne me permet pas de faire des modifs structurelles).
Appelons ce serveur SQL

Il y a quelques années, j'avais greffé une solution de reporting/analyse de données en faisant une lecture des certaines données pour faire des ETLs (1 fois par période de 24h durant la nuit) dont le résultat était stocké dans une autre base de données (DWH) sur un autre serveur (DWH).

Afin de ne pas pénaliser l'accès à la base source, j'ai très vite préféré, chaque nuit, avant les ETLs, récupérer une copie des données sources dont j'avais besoin (certaines tables seulement).
Globalement, chaque nuit, je remet à zéro la base "recopiée" la veille sur DWH, puis réalimente l'ensemble des tables depuis la base source sur SQL, et cela à partir une simple requête du style (INSERT INTO DWH.BASE.Table_xyz SELECT * FROM SQL.BASE.Table_xyz) pour chacune des tables Table_xyz.

En parallèle de cela, un prestataire (hors de mon LAN, accessible par FTP via un simple accès internet) a eu besoin de mettre en place une autre solution de reporting/analyse de données.
J'avais donc mis en place sur le serveur source SQL, un système d'export de données via fichiers CSV (1 fichier par table, 2-3 tables seulement).
Afin de ne pas pénaliser l'exploitation de mon serveur source (et l'accès internet qui a aussi une utilité prioritaire durant la journée) qui n'est que durant la journée, les exports se déclenchaient uniquement la nuit.

Je souhaite faire évoluer un peu les choses afin d'avoir moins de tâches nocturnes et répartir le travail tout au long de la journée.
Le but n'est, par contre, pas d'avoir une solution HA avec réplication temps-réel, je me satisferais d'avoir un retard de plusieurs minutes sur la partie répliquée, voire même de ne commencer la réplication qu'en milieu d'après-midi, même si la production a commencé le matin.

Après une première analyse du sujet, je comptais mettre en place un système de réplication transactionnelle depuis le serveur SRV-SQL vers le serveur SRV-DWH.
Pas faisable, car l'ensemble des tables de la base source ne contiennent aucune clé primaire (pas la peine de me critiquer, je ne gère pas cette base et je n'ai jamais réussi à faire comprendre à l'éditeur l'intérêt des clés primaires :-( )

Autre solution envisagée dernièrement, mettre en place un système de "réplication" via LogShipping entre mes 2 serveurs SRV-SQL et SRV-DWH.
Et "envoyer" en plus par FTP, chaque nouveau fichier de log vers le serveur du prestataire, afin qu'il regénère lui aussi la base.
Problème, si j'ai bien compris, je ne pourrais pas sélectionner que certaines tables, car les logs contiendront les données de toutes les tables de la base.
Cela ne convient pas car il est impératif que le partenaire n'ait pas accès aux données de certaines tables.

Donc quelles pourraient les solutions à envisager ?
A noter que mon serveur répliqué DWH pourrait se contenter des mêmes tables que celles nécessaires au partenaire externe.
De plus, le prestataire préfèrerait récupérer des fichiers LogShipping, afin d'avoir une homogénéité avec d'autres fournisseurs de données comme moi.

Donc :
- Réplication complète de la Base depuis SQL vers DWH à l'aide de LogShipping, puis de ce serveur DWH, mise en place d'un simple export partiel comme actuellement, via fichiers CSV envoyés par FTP ?
- Réplication partielle de la Base depuis SQL vers DWH à l'aide de scripts SQL, puis mise en place de LogShipping vers le prestataire ?
- La solution de réplication "Snapshot" (qui, si j'ai bien compris, permet de sélectionner seulement certaines tables) pourrait-elle être mise en place vue que la base source ne dispose d'aucune clé primaire ?
- Autre idée/suggestion ...

Merci par avance

[sim3val]

Pour faire avancer ma problématique, selon vous, quel ouvrage pourrait m'aider le plus :
http://www.editions-eyrolles.com/Liv...ql-server-2014
ou
http://www.editions-eni.fr/livres/sq...9e9fd805c.html

Les (co)auteurs, peuvent aussi donner leur avis, mais je pense déjà le connaitre ;-)

Et sinon, quelqu'un a-t-il déjà acheté une ou plusieurs des formations vidéos chez video2brain :
https://www.video2brain.com/fr/sql-server

Merci par avance

[SQLpro]

C'est dommage... Vous avez décrit ce que vous faites, pas ce que vous voulez !
Si votre but est d'alimenter un datawarehouse, alors vous pouvez le faire en différentiel (ne prendre en compte que les évolutions des données ayant eu lieu dans un laps de temps - par exemple 24h) à l'aide de CHANGE TRACKING (version Standard) ou CDC (CHANGE DATA CAPTURE) version Enterprise.
Le log shipping est destiné à faire de la haute disponibilité, pas une réplication des données. Pour répliquer des données il y a 4 modes différents : transationnel, peer to peer, snapshot et fusion. Dans votre cas, le mode transactionnel semble le plus adapté.

Mais décrivez nous ce que vous voulez obtenir et non les solutions que vous avez tenté !

Enfin pour le livre, je me garderais bien de m'envoyer des fleurs sur notre ouvrage qui compte 1262 pages. Je dirais simplement que ENI est connu pour faire de la formation et que la plupart de ses bouquins ne sont autre que des resucées de supports de cours...

A +

[sim3val]

Merci pour cette réflexion.

J'aurais pu être plus explicite effectivement sur le souhait qui est :
- Laisser mon serveur "principal" pour l'usage initial/officiel pour lequel il est prévu (applications métiers, pas forcément toutes bien optimisées, et BDD pas forcément bien conçue (aucune clé primaire, peu d'index, ...))
- "Recopier" cette base sur un autre serveur qui lui pourra être sollicité pour des opérations annexes, dont la criticité est moindre, mais l'usage peut être plus important et plus fréquent (alimentation DWH via ETL, interrogations en lecture ou nouveaux exports partiels vers des prestataires externes)
- Et donc améliorer cette phase de recopie, qui actuellement se fait une seule fois par jour, pour que cette recopie puisse se faire de manière plus régulière (genre, toutes les x minutes)

Pour la phase de "recopie", soit :
1) une recopie intégrale de l'ensemble des tables de la base source, et c'est ensuite depuis la base secondaire, que je filtre les tables à exporter vers les prestataires externes
2) une recopie partielle de seulement les tables que j'exporterais finalement vers les prestataires externes (mais cette hypothèse risque de bloquer ultérieurement si divers prestataires doivent avoir accès à certaines tables et pas à d'autres (et inversement))

J'ai noté l'avis sur les bouquins. Dommage que Eyrolles ne propose pas les 1ères pages en lecture (surtout le sommaire), ça permettrait de mieux se rendre compte de l'intégralité (et la longueur) des divers sujets traités ;-)
Je vais me documenter un peu sur CHANGE TRACKING (sujet qui, j'imagine, est abordé dans le bouquin !).

P.S. : Pour l'instant j'utilise SQL Server 2008 R2 Standard

[SQLpro]

Je vais me documenter un peu sur CHANGE TRACKING (sujet qui, j'imagine, est abordé dans le bouquin !).

Non, change tracking n'est pas documenté dans le livre.... Il aurait fallu un tome 2

Pour votre problème, vu la version que vous avez et l'édition aussi, la meilleure solution est de faire un mirroring sur l'autre serveur ce qui vous donnera une haute dispo.
À partir de ce miroir, vous pouvez faire des sauvegardes et des restaurations par exemple toutes les heures.
Si vous étiez en version Enterprise, vous pourriez faire des snapshot réguliers côté miroir.
Enfin avec AlwaysOn (à partir de 2012), les bases mirrorées sont lisible.

A +

[sim3val]

Merci.
Je vais chercher dans ces directions.
Et lire (ou au moins parcourir) au passage quelques centaines de pages du bouquin ;-)

[elsuket]

Non, change tracking n'est pas documenté dans le livre.... Il aurait fallu un tome 2

Si si, le livre présente Change Tracking et Change Data Capture dans le chapitre 20, à partir de la page 1061. Bonne lecture !

@++

[sim3val]

Aie, conflit déclenché entre certains des co-auteurs.

Je vous laisse régler ce litige de manière pacifique, pour ma part je poursuis la lecture de l'ouvrage et m'arrêterais plus attentivement sur le chapitre 20 ;-)

[SQLpro]

Milles excuses !!!!! Comme je suis en déplacement, je n'avais pas le livre sous les yeux !

A +