Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

SQLPASS : Jour 1, DBA390S, Transactional Replication : Beyond the basics

Pour commencer quelques bases sur la réplication:

Dans une topologie de réplication il y a l'éditeur (publisher) qui est le fournisseur des données à répliquer. Le Distributeur (distributor) qui peut être distant qui a un rôle de pivot dans la cas de la réplication stransactionnel. Souvant l'éditeur et le distributeur sont la même machine, mais on peut les séparer si cas de charge importante. Il peut y avoir plusieurs abonnées (subscribers).

En termes de topologies avancés il est possible d'avoir un abonné à 2 publications provenant de 2 éditeurs.

On a aussi la possibilité d'avoir du re-publishing, c'est-à-dire la possibilité de re-publier des données dans une autre publication depuis un abonné existant. Intéressant pour limiter le nombre d'abonné par éditeur et par publication, mais attention à l'augmentation du temps de latence.

La première étape d'initialisation d'une réplication transactionnelle. L'agent de Snapshot (instantané) génère une copie des données via BCP et génère aussi la structure de la table. Une fois cela fait les données sont passées à l'Agent de Distribution qui crée le schéma et y insère les données.

Une fois l'initialisation faite, le Log Reader Agent prend le relais, il lit le contenu du journal de transaction et stocke les commandes à envoyer aux abonnées dans la base de données de distribution. L'agent de distribution ensuite applique les commandes vers les abonnés. Ce sont bien 2 agents séparé, la base de distribution prend le rôle de tampon. On trouve aussi les agents de Cleanup chargé de vider les metadonnées.

Le mode récupération de la base de données publié peut être FULL, BULK ou SIMPLE.

Il est possible de répliquer les données (et leurs données) et ainsi que la majeure partie des schémas des objets. Avec une exception les vues indexées dont on peut aussi répliquer les données et non pas seulement le schéma. Depuis SQL Server 2005 il est aussi possible de répliquer les commandes DDL c'est-à-dire les créations d'objets en base de données.

Attention lors de la génération du snapshot à l'option d'action si la table existe déjà à destination. Dans la majeure partie des cas il est recommandé de changer cette option. Pour un éditeur central on pourra indiquer de ne pas toucher à l'objet s'il existe déjà.

Quelques optimisations liés à l'option "Statement delivery" :

  • Possibilité d'utiliser une commande appelé par SCAL, il utilise un bitmask et il ne mettra à jour que les colonnes qui ont uniquement changés.
  • Il peut être intéressant en cas de DELETE de mettre « Don't replicate DELETE » pour faire en sorte que la table sur l'abonné conserve les données.
  • Côté INSERT il est possible de réaliser l'opération avec ou sans la liste de colonnes, en vu d'optimiser l'opération si toutes les colonnes ou non sont passées.

Pour l'exécution des procédures stockées il est possible d'avoir une optimisation intéressante. Au lieu de répliquer les modifications réalisées par la procédure stockées il est possible de répliquer l'exécution des procédures stockées. Le gain se révèle très intéressant si la mise à jour porte sur un grand nombre de données.

« Replicate Schema Changes » peut être changé sans impact sur la réplication, elle ne sera pas invalidé, ce qui permet de réaliser des changements temporaire avec cette option sur Off.

Il est possible de définir un abonnement comme étant Pull (l'agent est sur l'abonné) ou Push l'agent est sur le distributeur. Au niveau de l'initialisation il est possible de créer la réplication à partir d'une sauvegarde en changeant l'option @sync_type.

Dans le Replication Monitor il est possible de définir des alertes en vue d'envoyer des emails sur des critères de performance. Il est conseillé de créer une alerte pour les cas d'échec de l'agent ou en cas de retry. Pour les cas de temps de latence, c'est possible mais attention celle-ci peut grandement varier en fonction des périodes de charges et des commandes exécutés sur les serveurs. Dans la même outil il est possible d'utiliser des Tracer Tokens qui permettent de tester le temps de latence entre l'éditeur et le distributeur, mais aussi entre le distributeur et les abonnées. On pourra automatiser ces TracersToken (qui ne modifient pas les données) et l'historique est conservé sur le distributeur.

Quelques astuces au niveau des Agent Profile

  • Changement du paramètre bcp thread pour limiter la charge au niveau des imports/exports de données liés au Snapshot
  • Ajout de l'option skipped errors pour ignorer un certain nombre d'erreur, pour par exemple dépanner la réplication en évitant de bloquer sur une violation de clef étrangère
  • Ajout des infos de log avec Output, on indique alors un fichier, attention à la taille que peut prendre ce dernier
  • Exécution continue de l'agent avec l'option Continous, dans ce cas bien régler le PollingInterval réglé par défaut sur 10 seconde
  • Le parameter SubscriptionStream (suivi du nombre de stream) permet d'améliorer considérablement les temps de chargement en multipliant le nombre de thread et de chargement

Bonne session…

Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
Publié mercredi 10 novembre 2010 19:19 par christian

Commentaires

Pas de commentaires
Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- Merci par Blog de Jérémy Jeanson le 10-01-2019, 20:47

- Office 365: Script PowerShell pour auditer l’usage des Office Groups de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 11:02

- Office 365: Script PowerShell pour auditer l’usage de Microsoft Teams de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 10:39

- Office 365: Script PowerShell pour auditer l’usage de OneDrive for Business de votre tenant par Blog Technique de Romelard Fabrice le 04-25-2019, 15:13

- Office 365: Script PowerShell pour auditer l’usage de SharePoint Online de votre tenant par Blog Technique de Romelard Fabrice le 02-27-2019, 13:39

- Office 365: Script PowerShell pour auditer l’usage d’Exchange Online de votre tenant par Blog Technique de Romelard Fabrice le 02-25-2019, 15:07

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Stream Portal par Blog Technique de Romelard Fabrice le 02-21-2019, 17:56

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Video Portal par Blog Technique de Romelard Fabrice le 02-18-2019, 18:56

- Office 365: Script PowerShell pour extraire les Audit Log basés sur des filtres fournis par Blog Technique de Romelard Fabrice le 01-28-2019, 16:13

- SharePoint Online: Script PowerShell pour désactiver l’Option IRM des sites SPO non autorisés par Blog Technique de Romelard Fabrice le 12-14-2018, 13:01