Déchargement de traitement par lots

Exemple Adventure Works Cycles

Adventure Works Cycles est une société de fabrication fictive utilisée pour illustrer des scénarios et des concepts de base de données. Pour plus d'informations, consultez Exemples de bases de données AdventureWorks.

Adventure Works Cycles utilise un traitement par lots pour contrôler la fraude par carte de crédit sur leur site Web. Les données collectées à partir des transactions sur le site Web sont répliquées à partir du serveur MicrosoftSQL Server utilisé sur le site Web vers un serveur SQL Server séparé utilisé pour plusieurs applications Adventure Works Cycles. Des recherches de modèles de fraude par carte de crédit sont effectuées sur les données du serveur de traitement par lots. Bien que la détection de fraude ne produise qu'une faible quantité de données (mise à jour de données dans un petit nombre de colonnes si un compte montre une activité suspecte), les vérifications nécessitent des calculs intensifs et des ressources importantes du serveur. Une fois le traitement par lots exécuté, une faible quantité de données est renvoyée sur le serveur OLTP pour le site Web, indiquant les comptes pouvant montrer des signes de fraude.

Conditions communes requises pour ce scénario

Les applications de traitement par lots ont généralement les conditions requises suivantes, qu'une solution de réplication appropriée doit résoudre :

• Le système doit maintenir la cohérence transactionnelle.

• Le système doit avoir une faible latence : les mises à jour sur le serveur de traitement en ligne doivent atteindre rapidement le serveur de traitement par lots.

• Le système doit disposer d'un débit élevé : il doit pouvoir gérer la réplication d'un grand nombre de transactions.

• Le traitement de la réplication ne doit nécessiter qu'une charge minimale sur le serveur de traitement en ligne.

• Les modifications de données peuvent circuler dans les deux sens : les résultats du traitement par lots peut être propagé en retour sur le serveur de traitement en ligne.

• Les données requises sur le serveur de traitement par lots peut être un sous-ensemble des données disponibles sur le serveur de traitement en ligne.

Type de réplication à utiliser pour ce scénario

SQL Server utilise une métaphore de l'industrie de la publication pour décrire les composants du système de réplication. Les composants comprennent le serveur de publication, les abonnés, les publications et articles, et les abonnements.

• Dans le diagramme ci-dessus, le serveur de traitement en ligne est le serveur de publication. Toute ou partie des données du serveur de traitement en ligne est ajoutée à la publication, chaque table de données étant un article (les articles peuvent également être des objets de base de données, comme des procédures stockées). Le serveur de traitement par lots est un abonné à la publication et reçoit un schéma et des données comme abonnement.

• Si les résultats sont propagés en retour sur le serveur de traitement en ligne, le serveur de traitement par lots est également un serveur de publication (généralement avec la même publication que celle du serveur de traitement en ligne) et le serveur de traitement en ligne s'abonne à la publication.

Pour plus d'informations sur les composants du système, consultez Présentation du modèle de publication de réplication.

SQL Server offre différents types de réplication pour différents besoins d'application : la réplication de capture instantanée, la réplication transactionnelle et la réplication de fusion. Ce scénario est mieux implémenté avec la réplication transactionnelle, davantage conçue pour gérer les besoins décrits dans la section précédente. Pour plus d'informations sur la réplication transactionnelle, consultez Présentation de la réplication transactionnelle et Fonctionnement de la réplication transactionnelle.

Par défaut, la réplication transactionnelle aborde les conditions requises principales de ce scénario :

• Homogénéité des transactions

• Faible latence

• Débit élevé

• Charge minimale

Les options dont il faut tenir compte pour ce scénario sont le filtrage, la réplication transactionnelle d'égal à égal et la réplication transactionnelle bidirectionnelle :

• La réplication transactionnelle vous permet de filtrer les lignes et les colonnes, permettant ainsi au serveur de traitement par lots de ne recevoir que les données nécessaires à votre application. Pour plus d'informations, consultez Filtrage des données publiées.

• La réplication transactionnelle vous permet de propager les modifications dans plusieurs directions à l'aide de la réplication d'égal à égal ou de l'option bidirectionnelle. Pour plus d'informations, consultez Réplication transactionnelle d'égal à égal et Réplication transactionnelle bidirectionnelle.

Étapes d'implémentation de ce scénario

Pour implémenter ce scénario, vous devez d'abord créer une publication et des abonnements, puis initialiser chaque abonnement. Cliquez sur les liens ci-dessous pour plus d'informations sur chaque étape :

• SQL Server Management Studio: Procédure : configurer la réplication transactionnelle d'égal à égal (SQL Server Management Studio)

• Programmation de la réplication Transact-SQL : Procédure : configurer la réplication transactionnelle d'égal à égal (programmation Transact-SQL de la programmation)

• Réplication transactionnelle bidirectionnelle

Une fois que l'abonnement est initialisé et que les données circulent entre le serveur de publication et les abonnés, vous devrez peut-être consulter les rubriques suivantes afin d'obtenir des informations sur les tâches communes d'administration et d'analyse :

• Surveillance (réplication)

• Stratégies de sauvegarde et de restauration de la réplication transactionnelle et de capture instantanée

• Dépannage (réplication)

• Suppression de la réplication

Voir aussi

Autres ressources