2. Importation et exportation de donnée

 

L’importation, l’exportation et la réplication sont des procédés très importants qui permettent de charger dans notre serveur des données en provenance d’une source extérieur. Cela permet alors de faire fonctionner un système d’information constitué de plusieurs serveurs et de sources hétérogènes.

2.1.      DTS

DTS est un acronyme pour Data Transformation Service. C’est le procédé le plus utilisé sous SQL server pour importer ou exporter des données avec d’autre serveur SQL ou des sources variées.

 

Mais dans DTS il y a aussi le mot transformation, cela veut dire que DTS ne se contente pas seulement d’importer les données, il peut également y effectuer des traitements. Ceci et particulièrement utile lorsque le système avec lequel on veut dialoguer utilise des types de données différent.

 

SQL server dispose d’un assistant DTS très bien fait, nous allons voir ensemble son fonctionnement.

 

-         Première étape :

En faisant un clic droit sur une base puis en sélectionnant toutes les tâche on aperçoit l’option importer des données et exporter des données

-         Deuxième étape :

Nous allons maintenant procéder à la sélection de la source et de la destination

Voici la source

 

Un menu similaire permet ensuite de choisir la destination

 

 

Une fois la source et la destination choisies il faut sélectionner les données.

Plusieurs choix s’offrent à nous.

Si les deux plateformes sont des SQL server il est possible de copier tous les objets entre les bases de données.

On peut également choisir les données à transférer en les sélectionnant au moyen d’une requête SQL ou T-SQL.

Mais dans la plus part des cas on se contentera de copier une ou plusieurs tables entre les bases.

 

Voici l’écran de sélection :

 

 

On choisit les tables source et leur destination, si la table destination n’existe pas elle est ensuite crée automatiquement.

D’avantage d’options sont accessibles depuis l’onglet transformer, cela permet par exemple de configurer les types des colonnes lorsque l’on importe depuis un fichier texte.

 

Une fois tous les choix effectués on peut procéder une exécution immédiate, ou enregistrer le tout dans un lot que l’on pourra exécuter plus tard. Stockez le dans les métadonnées,  cela offre plus de souplesse.

2.2.      BCP

L’utilitaire BCP (Bulk Copy Program) permet de créer des fichiers d’export pour une importation en mode BULK INSERT.

Ce système est beaucoup moins convivial et surtout moins souple que DTS.

Je conseil l’utilisation de DTS préférentiellement à BCP.

2.3.      Réplication

 

Dans le cadre d’application complexe et particulièrement exigeante il peu être nécessaire de disposer de plusieurs serveurs disposant du même jeu de donnée.

Couplé à un système de répartition de charge cela augmente la disponibilité ainsi que les performance globale du système.

Afin d’assurer la cohésion entre les données des différents serveurs le logiciel dispose d’un système très complexe de réplication.

A.   Architecture du système

 

Une architecture de réplication SQL server se compose de 3 types d’entités différentes.

        

-         Publisher : Le publisher est la machine qui dispose des données de références, il garde une trace des changements effectués sur les bases publiée afin que la réplication s’effectue correctement. Il ne peut y avoir qu’un seul Publisher par article publié.

-         Distributor : le distributor contient la base de donnée de distribution. Il stocke les métas donnés (les données qui décrivent les données) ainsi que l’historique de la réplication. Il y a un distributor par publisher.

-         Subscriber : se sont les abonnés, ils recevront les donnés du publisher, mais rien n’empêche un subscriber d’être publisher pour une autre machine.

B.   Les différents types de réplication

-         Snapshot : Il s’agit du type de réplication le plus simple. Un instantané de la base est calculé de manière périodique puis transmis aux abonnées. Ce type de réplication n’impose qu’une charge minimale de travail aux différents acteurs. En effet le publisher n’est pas obligé de monitorer en permanence les changements effectué sur les donnés. D’un autre coté les abonnée ne dispose que des donnés issue du dernier snapshot, et donc pas toujours les plus récentes.

-         Réplication transactionnelle : lors d’un réplication transactionnelle les changement effectués sur les données de références sont immédiatement propagés aux abonnées, la charge de travail et supérieur à celle d’une réplication de type snapshot, surtout si la base très souvent modifiée. Par contre les abonnés disposent toujours des données les plus actuelles possibles.

-         Réplication fusion : c’est intermédiaire entre la réplication transactionnelle et la réplication snapshot. Le publisher conserve une trace des données de réplication, mais celles-ci ne sont pas envoyées immédiatement, mais pas batch successifs. C’est donc un bon compromis.

C.   Mise en œuvre de la réplication

 

Dans un premier temps nous allons configurer le service de publication sur notre serveur. Ce service n’est pas activé par défaut.

ATTENTION : avant de démarrer la configuration de la réplication il faut que l’agent SQL server soit en fonctionnement.

Nous allons faire un clic droit sur l’onglet réplication, et configurer le service.

 

 

 

Un assistant très bien fait va nous guider tout au long du processus.

 

 

Notre machine sera à la fois publisher et distributeur, c’est d’ailleurs très souvent le cas dans les petites et moyennes architectures.

Une nouvelle base sera crée pour stocker les données de distribution.

 

 

L’assistant vous demande ensuite quel sera le partage réseau utiliser pour stocker les fichier de captures instantanées. ATTENTION ! Les autres serveurs doivent impérativement disposer des permissions pour accéder à ce dossier. Il s’agit de la cause principale d’erreur lors d’une réplication. Les droits du serveur sont ceux du compte utilisé pour lancer le service MSSQL. L’idéal est d’utiliser le compte administrateur du domaine.

 

Choisissez ensuite les options par défaut, et nous en avons fini avec la configuration du service.

Remarquez un nouvel onglet : Moniteur de Réplication.

 

 

Nous allons maintenant publier une base

Un clic droit sur publication, puis nouvelle publication va appeler l’assistant publication.

 

 

 

 

 

Nous pouvons maintenant choisir la base que nous allons publier. 

 

 

Nous choisissons maintenant le type de réplication.

 

 

Puis les types d’abonnés.

 

 

A partir de cet écran nous choisissons les donnés que nous allons publier.

Attention, seules les tables disposant d’une clé primaire peuvent êtres publiées dans le cadre d’une réplication transactionnelle.

Les tables ayant des colonnes de type IDENTITY (compteur) doivent également faire l’objet d’une configuration particulière, l’assistant vous guidera dans ce cas.

 

 

 

 

Il ne nous reste plus qu’à donner un nom à notre publication.

Choisissez ensuite les options par défaut et validez.

Voila ! Notre base est publiée.

 

Il ne nous reste plus qu’à nous abonner.

Un clic droit sur réplication/abonnement appelle un nouvel assistant.

 

 

 

Nous pouvons maintenant sélectionner la base à laquelle nous allons nous abonner.

 

 

Puis la base de destination. Nous pouvons créer une nouvelle base à cet effet.

 

 

 

Ensuite nous spécifions si la base dispose déjà de la structure de donnée ou si nous devons l’initialiser.

 

Nous spécifions ensuite la planification de notre réplication.

 

L’état de la réplication est ensuite accessible depuis le moniteur de réplication.