Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
S’applique à :
SQL ServerAzure SQL Managed Instance
Les abonnements peuvent expirer ou être désactivés s'ils ne sont pas synchronisés durant une certaine période de rétention. L'action qui se produit dépend du type de réplication et de période de rétention qui est dépassée.
Pour définir des périodes de rétention, consultez Définir la période d’expiration des abonnements, Définir la période de rétention de distribution pour les publications transactionnelles (SQL Server Management Studio) et Configurer la publication et la distribution.
Réplication transactionnelle
La réplication transactionnelle utilise la période de conservation de distribution maximale (le paramètre @max_distretention de sp_adddistributiondb (Transact-SQL)) et la période de conservation de publication (le paramètre @retention de sp_addpublication (Transact-SQL)) :
Si un abonnement n’est pas synchronisé durant la période de rétention maximale (par défaut, 72 heures) et si aucune des modifications intervenues dans la base de données de distribution n’a été remise à l’abonné, l’abonnement sera marqué comme désactivé par le travail de nettoyage d’abonnement expiré qui s’exécute sur le serveur de distribution. L'abonnement doit être réinitialisé.
Si un abonnement n'est pas synchronisé durant la période de rétention de publication (par défaut, 336 heures), l'abonnement expire et est supprimé par le travail de nettoyage de l'abonnement expiré qui s'exécute sur le serveur de publication. (Avant le correctif apporté par KB4014798, la tâche s’appelait nettoyage de distribution.) L’abonnement doit être recréé et synchronisé.
Si un abonnement push arrive à expiration, il est entièrement supprimé, mais ce n’est pas le cas des abonnements pull. Vous devez nettoyer les abonnements par extraction de données au niveau de l'Abonné. Pour plus d’informations, voir Delete a Pull Subscription.
Réplication de fusion
La réplication de fusion utilise la période de conservation de publication (paramètres @retention et @retention_period_unit de sp_addmergepublication (Transact-SQL)). Lorsqu'un abonnement expire il doit être réinitialisé, parce que les métadonnées de l'abonnement sont supprimées. Les abonnements qui ne sont pas réinitialisés sont supprimés par le travail de nettoyage de l'abonnement expiré sur le serveur de publication. Par défaut, cette tâche s'exécute quotidiennement; elle supprime tous les abonnements de publication push qui ne se sont pas synchronisés pendant une durée égale au double de la période de rétention de la publication. Par exemple :
Si une publication a une période de rétention de 14 jours, un abonnement peut expirer s'il ne s'est pas synchronisé au bout de 14 jours.
Si le serveur de publication exécute SQL Server 2005 (9.x) ou version ultérieure et que l’agent de l’abonnement provient de SQL Server 2005 (9.x) ou version ultérieure, un abonnement n’arrive à expiration que si des modifications de données se sont produites dans la partition de cet abonnement. Supposons par exemple qu'un Abonné ne reçoive de données clients que pour ses clients allemands. Si la période de rétention est définie à 14 jours, l'abonnement n'expire le quatorzième jour que s'il y a eu des modifications dans les données des clients allemands durant les 14 jours écoulés.
Entre 14 et 27 jours après la dernière synchronisation, l'abonnement peut être réinitialisé.
Au bout de 28 jours après la dernière synchronisation, l’abonnement est supprimé par la tâche de nettoyage des abonnements expirés. Si un abonnement push expire, il est complètement supprimé, mais ce n’est pas le cas des abonnements pull. Vous devez nettoyer les abonnements par extraction de données au niveau de l'Abonné. Pour plus d’informations, voir Delete a Pull Subscription.
Points à prendre en compte pour définir la période de rétention de publication pour les publications de fusion
Gardez à l’esprit les points suivants lorsque vous définissez la période de rétention des publications de fusion :
La période de rétention pour les publications de fusion offre un délai de grâce de 24 heures pour tenir compte des Abonnés situés dans différents fuseaux horaires. Si, par exemple, vous définissez une période de rétention d'un jour, la période de rétention réelle est de 48 heures.
Le nettoyage des métadonnées des réplications de fusion dépend de la période de rétention de publication :
La réplication ne peut pas nettoyer les métadonnées dans les bases de données de publication et d'abonnement tant que la période de rétention n'est pas achevée. Utilisez la prudence lors de la spécification d’une valeur élevée pour la période de rétention, car elle peut affecter négativement les performances de réplication. Vous avez intérêt à spécifier une valeur faible si vous êtes certain que tous les Abonnés procéderont régulièrement à la synchronisation dans ce délai.
Il est possible de spécifier que les abonnements n’expirent jamais (valeur 0 pour
@retention), mais cela est fortement déconseillé, car les métadonnées ne pourront pas être nettoyées.
La période de rétention pour tout serveur de republication doit être égale ou inférieure à la période de rétention définie sur le serveur de publication d'origine. Veillez à utiliser les mêmes valeurs de conservation des publications pour tous les serveurs de publication et leurs partenaires de synchronisation respectifs. L’utilisation de valeurs différentes peut produire une non-convergence. Si vous devez modifier la valeur de rétention de la publication, réinitialisez l'Abonné pour éviter la non-convergence des données.
Après un nettoyage, si la période de conservation des publications est augmentée et qu’un abonnement essaie de fusionner avec le serveur de publication (qui a déjà supprimé les métadonnées), l’abonnement n’expire pas en raison de l’augmentation de la valeur de rétention. Cependant, le serveur de publication ne dispose pas d'une quantité suffisante de métadonnées pour télécharger les modifications apportées à l'Abonné, ce qui génère une non-convergence.