Gestion du routage
Service Broker utilise des itinéraires pour déterminer le lieu de remise des messages. Cette section développe les points à prendre en considération lorsque vous gérez le routage.
Gestion d'AutoCreatedLocal
Chaque base de données utilisateur qui englobe msdb contient par défaut l'itinéraire AutoCreatedLocal. Cet itinéraire, qui correspond à tous les noms de services et instances de broker, spécifie que le message doit être remis dans l'instance active. Le niveau de priorité de AutoCreatedLocal est inférieur à celui des itinéraires indiquant explicitement le nom du service ou l'instance du broker.
Dans la mesure où AutoCreatedLocal existe par défaut dans msdb, Service Broker tente de remettre tous les messages provenant de l'extérieur de l'instance dans l'instance active. Dans de nombreux cas, l'administrateur de base de données restreint l'accès aux services situés à l'extérieur de l'instance en supprimant AutoCreatedLocal dans msdb. Cet administrateur crée ensuite un itinéraire pour chaque service qui communique avec une instance distante.
Gestion de l'expiration des itinéraires
La plupart du temps, un itinéraire n'a pas besoin de délai d'expiration. Il demeure actif tant que l'objet de l'itinéraire existe. Si l'adresse de destination pour l'itinéraire change, l'administrateur peut soit modifier l'itinéraire pour mettre à jour l'adresse soit supprimer l'itinéraire.
Une application qui utilise le routage dynamique peut, en revanche, utiliser l'expiration des itinéraires pour s'assurer que les informations de routage sont toujours à jour. Service Broker ne supprime pas les itinéraires expirés de la base de données. Une application qui utilise des délais d'expiration avec les itinéraires doit également créer un travail de l'Agent SQL Server pour supprimer périodiquement les objets des itinéraires arrivés à échéance.
Voir aussi
Concepts
Itinéraires
Routage Service Broker