Expiration et désactivation des abonnements
S’applique à : 
SQL Server Azure 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 dans KB4014798, le travail était nommé nettoyage de distribution.) L’abonnement doit être recréé et synchronisé.
Si un abonnement par envoi de données expire, il est totalement supprimé, mais ce n'est pas le cas pour les abonnements par extraction de données. 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, ce travail s'exécute chaque jour ; il supprime tous les abonnements par envoi de données qui ne se sont pas synchronisés au bout de deux fois la période de rétention de 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é.
28 jours après la dernière synchronisation, l'abonnement est supprimé par le travail de nettoyage de l'abonnement expiré . Si un abonnement par envoi de données expire, il est totalement supprimé, mais ce n'est pas le cas pour les abonnements par extraction de données. 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 en mémoire les points suivants lorsque vous définissez la période de rétention de publication pour les 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. Soyez prudent si vous spécifiez une longue période de rétention, car cela 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. Pour modifier cette valeur, réinitialisez l'Abonné afin d'é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.