Gérer le routage

S’applique à :SQL ServerAzure SQL Managed Instance

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.

Gérer AutoCreatedLocal

Par défaut, chaque base de données utilisateur, y compris msdb, contient 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. AutoCreatedLocal a un niveau de priorité inférieur à celui des itinéraires indiquant explicitement le nom du service ou l’instance du broker.

Étant donné que AutoCreatedLocal existe msdb par défaut, Service Broker tente de remettre tous les messages en dehors de l’instance au sein de l’instance actuelle. Dans de nombreux cas, l’administrateur de base de données limite l’accès aux services en dehors de l’instance en supprimant AutoCreatedLocal in msdb. Cet administrateur crée ensuite un itinéraire pour chaque service qui communique avec une instance distante.

Gérer l’expiration de l’itinéraire

Dans la plupart des cas, un itinéraire n’a pas besoin d’expirer. 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.

Toutefois, une application qui utilise le routage dynamique peut utiliser l’expiration de l’itinéraire pour s’assurer que les informations de routage restent à 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 du service SQL Server Agent pour supprimer périodiquement les objets des itinéraires qui ont expiré.

Contenu connexe

• Itinéraires
• Routage du Service Broker