Voix et communications unifiées : Cisco Unity

Réplication SQL Server pour le basculement Cisco Unity

18 octobre 2016 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


Introduction

Quand le Basculement est configuré, le Cisco Unity emploie la réplication de Microsoft SQL Server 2000 pour répliquer des données du serveur actif vers le serveur inactif. Si le Basculement se produit, la réplication des données s'assure que la configuration en cours et les données d'abonné est disponible sur le serveur secondaire et que, après la restauration, des modifications apportées sur le secondaire tandis qu'il était en activité sont répliqués de nouveau au primaire. La réplication est exécutée par les jobs de réplication de Serveur SQL, qui sont exécutés par le service SQLSERVERAGENT.

Quand la réplication de Serveur SQL se casse, des transactions de réplication sont enregistrées dans des tables de journal d'audit sur le serveur actif ainsi les données peuvent être répliquées vers le serveur inactif quand la réplication est restaurée. Si la réplication est cassée pendant une période étendue, les tables de journal d'audit peuvent devenir grandes. Ceci peut entraîner la dégradation de représentation, qui consécutivement peut entraîner la réponse pauvre de TUI et peut même faire produire le Basculement. D'ailleurs, la base de données de Cisco Unity sur le serveur inactif n'a pas la configuration la plus récente et les données d'abonné quand ce va bien au serveur actif.

Conditions préalables

Conditions requises

Assurez-vous que vous vous êtes terminé les conditions requises pour le Basculement de Cisco Unity avant que vous configuriez le Basculement de Cisco Unity.

Composants utilisés

Les informations dans ce document sont basées sur le Cisco Unity 4.0(3) 5.x traversant.

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Surveillez la réplication

Causes de panne de réplication SQL

La réplication peut échouer si le service SQLSERVERAGENT ne commence pas et/ou si les JOBs de réplication que le service exécute l'échouer pour démarrer. Ces pannes peuvent se produire quand les reprises de Serveur SQL (par exemple, quand le serveur de Cisco Unity est redémarré) en raison de la synchronisation émet, des correctifs, ou l'application des stratégies de Sécurité ou d'ordinateur.

Employez le journal d'événements pour surveiller le service SQLSERVERAGENT

Si le service SQLSERVERAGENT ne commence pas, un événement est ouvert une session le journal d'événements de système. Exemple :

Event Type:	Error
Event Source:	Service Control Manager
Event Category:	None
Event ID:		7001
Date:		5/4/2007
Time:		10:58:47 PM
User:		N/A
Computer:		<servername>
Description:
The SQLSERVERAGENT service depends on the MSSQLSERVER service 
which failed to start because of the following error: 
The account name is invalid or does not exist, or the password 
is invalid for the account name specified. 

En outre, le Cisco Unity détecte le problème et se connecte cet événement dans le journal d'événements d'application. Il est recommandé que vous créez des notifications d'email ou de pagineur basées sur cet événement utilisant n'importe quel service d'événement-surveillance. Par exemple, le service de contrôle d'événement de Cisco Unity.

Event Type:	Warning
Event Source:	CiscoUnity_NodeMgr
Event Category:	Run 
Event ID:		1006
Date:		1/1/2007
Time:		9:00:00 AM
User:		N/A
Computer:		<servername> 
Description:
The SQL Server Agent service is not running. It must be running 
in order for replication to take place. 

Employez le journal d'événements pour surveiller les travaux de réplication

Quand les jobs que le service SQLSERVERAGENT exécute échouer pour ne commencer, par défaut, aucun événement est ouverts une session le journal d'événements. Cisco recommande que vous :

Configurez le Serveur SQL pour se connecter un événement quand un travail de réplication ne commence pas

Procédez comme suit :

  1. Commencez le gestionnaire d'entreprise de Serveur SQL.

  2. Dans le volet gauche du gestionnaire d'entreprise, développez les Microsofts SQL Server > le groupe de Serveur SQL > (gens du pays) (Windows NT) > agent de Gestion > de Serveur SQL, et cliquez sur les travaux.

  3. Dans le volet de droite, cliquez avec le bouton droit le nom du travail et choisissez Properties > des notifications.

    Voyez que 1par de Tableau qu'une liste des travaux de réplication a commencé par le service SQLSERVERAGENT.

  4. Dans la boîte de dialogue Properties de <job>, allez aux notifications l'onglet.

  5. Cochez l'inscription dans la case de journal d'événements d'application Windows.

  6. Cliquez sur OK pour fermer la boîte de dialogue Properties de <job>.

  7. Répétez les étapes 3 à 6 pour le reste des travaux pour lesquels vous voulez se connecter des événements.

Tableau 1 — Les travaux de réplication commencés par le service SQLSERVERAGENT

Le travail de réplication Description Catégorie
Réinitialisez les abonnements ayant des pannes de validation de données. Réinitialise tous les abonnements qui ont des pannes de validation de données. Réponse REPL-vigilante
Vérification d'agents de réplication Détecte les agents de réplication qui ne se connectent pas l'historique activement. REPL-vérification
SVRNAME-UnityDb-UnityDbPublication-SVRNAME-3 Distribution d'UnityDb REPL-distribution
La distribution nettoient : UnityDistributionDb Removes a répliqué des transactions de la base de données de distribution. Nettoyage de REPL-distribution
L'historique d'agent nettoient : UnityDistributionDb Enlève l'historique d'agent de réplication de la base de données de distribution. Nettoyage de REPL-historique
SVRNAME-UnityDb-3 UnityDb LogReader REPL-LogReader
[SVRNAME].9 Des files de lecture pour Queued mettant à jour des abonnements. REPL-QueueReader
SVRNAME-UnityDb-UnityDbPublication-3 Instantané d'UnityDb REPL-instantané
L'abonnement expiré nettoient Détecte et retire des abonnements expirés des bases de données éditées. Nettoyage de REPL-abonnement

Gestionnaire d'entreprise de Serveur SQL d'utilisation pour surveiller les travaux de réplication SQLSERVERAGENT

Gestionnaire d'entreprise d'utilisation pour déterminer si les travaux de réplication réussissent

Procédez comme suit :

  1. Sur le serveur primaire, gestionnaire d'entreprise de Serveur SQL de début.

  2. Dans le volet gauche du gestionnaire d'entreprise, développez les Microsofts SQL Server > le groupe de Serveur SQL > (gens du pays) (Windows NT) > agent de Gestion > de Serveur SQL et cliquez sur les travaux.

  3. Dans le volet de droite, chaque travail a une icône qui indique son succès ou échec. N'importe quel travail avec une icône de rouge-point a manqué. Pour tous travaux qui échouent, si la valeur de la colonne d'état est :

    • Exécuter — L'icône de rouge-documentation n'a pas été mise à jour avec l'état final. Attendez jusqu'à ce que l'icône ait été mise à jour.

    • Pour toute autre valeur, clic droit sur le nom de JOB, et anamnèse professionnelle de vue de clic afin d'afficher la raison pour laquelle le travail a manqué.

Déterminez si en attendant la réplication des transactions sont traitées

Pendant une panne de réplication, les transactions de réplication peuvent s'accumuler jusqu'à ce qu'il y ait plus que peut être traité tandis que le système traite un volume d'appels normal. (La plupart d'exemple classique de ceci est un délai d'attente ODBC où la tentative primaire et secondaire de serveurs de Cisco Unity de se connecter à une des autres.) Après la panne, quand vous permettez les travaux de réplication de s'exécuter pendant un temps relativement lent (tel que la nuit finie ou au-dessus d'une fin de semaine), les travaux de réplication peuvent souvent clair l'arriéré des transactions unreplicated. Cependant, s'il y a beaucoup de transactions unreplicated, les tentatives par le Serveur SQL de répliquer les données peuvent avoir comme conséquence un délai d'attente. Si la réplication fonctionne mais le nombre de transactions unreplicated n'a pas chuté sensiblement vers la fin d'une fin de semaine, vous pourriez devoir désactiver et puis réactiver la réplication. Voyez le débronchement et réactivez la section de réplication de ce pour en savoir plus de document.

Utilisez les commandes OSQL dans cette section de déterminer si le nombre de transactions unreplicated est exceptionnellement grand après une panne et si les transactions les plus anciennes sont traitées. (Pour un système avec un grand nombre d'abonnés de Cisco Unity et beaucoup d'activité, les transactions qui s'étendent dans les centaines peuvent être communes. Les transactions qui s'étendent dans les milliers sont sujet d'inquiétude.)

attention Attention : Si le nombre de transactions unreplicated est très grand, les commandes OSQL pourraient prendre un longtemps de se terminer et mettre le chargement supplémentaire considérable sur le serveur.

Terminez-vous ces étapes afin d'afficher un liste dans un certain ordre des dates sur les enregistrements en attente de réplication, que vous pouvez employer pour déterminer combien vieux la transaction la plus ancienne est :

  1. Sur le serveur secondaire, choisissez le Start > Run.

  2. Exécutez le cmd.

  3. À l'invite de commande, exécutez cette commande afin de commencer OSQL et questionner la base de données d'Unitydb :

    Remarque: Cette commande est enveloppée à une deuxième ligne due aux raisons spatiales.

    OSQL -E -d Unitydb -Q "SELECT distinct insertdate 
    FROM MSreplication_queue ORDER BY insertdate"
    

Remarque: Les Commutateurs OSQL distinguent les majuscules et minuscules (par exemple, - E).

Terminez-vous ces étapes afin d'obtenir un comptage total des enregistrements en suspens de réplication. Vous pouvez exécuter ces enregistrements quotidiennement pour déterminer si le nombre de transactions unreplicated est s'élevant ou craintif :

  1. Sur le serveur secondaire, choisissez le Start > Run.

  2. Exécutez le cmd.

  3. À l'invite de commande, exécutez cette commande afin de commencer OSQL et questionner la base de données d'Unitydb :

    OSQL -E -d Unitydb -Q "SELECT count(*) FROM MSreplication_queue"
    

    Remarque: Les Commutateurs OSQL distinguent les majuscules et minuscules (par exemple, - E).

Terminez-vous ces étapes afin de déterminer si des données du serveur primaire sont répliquées vers le serveur secondaire :

  1. Sur le serveur primaire, choisissez le Start > Run.

  2. Exécutez le cmd.

  3. À l'invite de commande, exécutez cette commande afin de commencer OSQL et questionner la base de données d'UnityDistributionDb :

    Remarque: Cette commande est enveloppée à une deuxième ligne due aux raisons spatiales.

    OSQL -E -d UnityDistributionDb -Q "SELECT SUM(UndelivCmdsInDistDB) 
    FROM MSdistribution_status"
    

Les travaux de réplication de reprise

Habituellement, si le service SQLSERVERAGENT ou celui des travaux de réplication ne commence pas, il est dû à une question de synchronisation pendant le startup. Vous pouvez généralement restaurer la réplication quand vous démarrez tous les JOBs qui n'ont pas commencée.

Les travaux de réplication de début qui n'ont pas commencé

Procédez comme suit :

  1. Commencez le gestionnaire d'entreprise de Serveur SQL.

  2. Dans le volet gauche du gestionnaire d'entreprise, développez les Microsofts SQL Server > le groupe de Serveur SQL > (gens du pays) (Windows NT) > agent de Gestion > de Serveur SQL et cliquez sur les travaux.

  3. Cliquez avec le bouton droit le travail qui n'a pas démarré et n'a pas cliqué sur le JOB de début.

  4. Si la valeur de la colonne d'état ne change pas à exécuter, passez en revue l'anamnèse professionnelle. Cliquez avec le bouton droit le travail, et cliquez sur l'anamnèse professionnelle de vue. Quand la cause de la panne est corrigée, répétez l'étape 3 afin de démarrer le JOB.

Désactivez et réactivez la réplication

Si le nombre de transactions unreplicated est si grand que les travaux de réplication chronomètrent à plusieurs reprises, et si ceci empêche la réplication de réduire de manière significative le nombre d'enregistrements unreplicated, vous devez désactiver et puis réactiver la réplication. Remplissez ces trois procédures afin d'accomplir ceci :

  1. Basculement automatique de débronchement, et fichier d'arrêt et réplication SQL

  2. Configurez le Basculement sur le serveur primaire

  3. Configurez le Basculement sur le serveur secondaire

attention Attention : Si vous désactivez et réactivez la réplication, les transactions unreplicated (le cas échéant) sur les serveurs primaires et secondaires sont supprimées, et la base de données de Cisco Unity sur le serveur primaire est répliquée vers le serveur secondaire. S'il y a des modifications unreplicated sur le serveur secondaire, ces modifications sont perdues.

Basculement automatique de débronchement, et fichier d'arrêt et réplication SQL

Procédez comme suit :

  1. Si le serveur primaire est en activité, passez à l'étape 5.

    Si le serveur primaire n'est pas en activité, sur le serveur secondaire choisissez le début > les programmes > le moniteur de Cisco Unity > de Basculement.

  2. Restauration de clic.

  3. Cliquez sur OK pour confirmer que vous voulez échouer de nouveau au serveur primaire.

  4. Fermez le moniteur de Basculement.

  5. Sur le serveur primaire, sur le menu de démarrage de Windows, choisissez les programmes > le moniteur de Cisco Unity > de Basculement.

  6. Cliquez sur Advanced.

  7. Cochez la case automatique de Basculement et de restauration de débronchement.

  8. Cliquez sur OK et fermez le moniteur de Basculement.

  9. Sur le serveur primaire, sur le menu de démarrage de Windows, choisissez le Programs > Administrative Tools > Services.

  10. Dans le volet de droite, double clic AvCsNodeMgr.

  11. Sur l'onglet Général, arrêt de clic.

  12. Dans la liste de démarrage de type, le clic a désactivé.

  13. Cliquez sur OK.

  14. Fermez la fenêtre de services.

    attention Attention : Puisque le service de gestionnaire de noeud est désactivé, la réplication de fichier arrête. La réplication est réactivée quand l'exécution normale de Basculement reprend.

  15. Sur le serveur secondaire, sur le menu de démarrage de Windows, choisissez le Programs > Administrative Tools > Services.

  16. Dans le volet de droite, double clic AvCsNodeMgr.

  17. Sur l'onglet Général, arrêt de clic.

  18. Dans la liste de démarrage de type, le clic a désactivé.

  19. Cliquez sur OK.

  20. Fermez la fenêtre de services.

  21. Sur le serveur primaire, sur le menu de démarrage de Windows, choisissez les programmes > la Microsoft SQL Server > le gestionnaire d'entreprise.

  22. Dans le volet gauche de la fenêtre de racine de console, parcourez au noeud de réplication pour le serveur primaire. Typiquement, le noeud est trois niveaux sous le noeud de Microsofts SQL Server.

  23. Cliquez avec le bouton droit le noeud de réplication, et cliquez sur l'édition de débronchement. L'assistant d'édition et de distribution du débronchement apparaît.

  24. Sur l'écran de bienvenue, cliquez sur Next.

  25. À la page de édition de débronchement, cliquez sur oui, puis cliquez sur Next.

  26. Sur la baisse de confirmer des publications paginez, cliquez sur Next.

  27. À la page se terminante, cliquez sur Finish.

  28. Quand le processus est complet, cliquez sur OK.

  29. Fermez la fenêtre de racine de console.

  30. Quittez le gestionnaire d'entreprise.

Configurez le Basculement sur le serveur primaire

Procédez comme suit :

  1. Dans l'Explorateur Windows, parcourez au répertoire de CommServer.

  2. Double-cliquer FailoverConfig.exe pour commencer l'assistant de Basculement de Cisco Unity de configurer.

  3. Sur l'écran de bienvenue, cliquez sur Next.

  4. À la page de rôle de serveur de spécifier, cliquez sur le serveur primaire, et cliquez sur Next.

  5. Sur l'entrer le nom de votre page de serveur, clic parcourent, sélectionnent le nom du serveur secondaire, et cliquent sur OK. L'adresse IP pour le serveur secondaire est complétée automatiquement.

  6. Cliquez sur Next (Suivant).

  7. À la page des informations du compte de Basculement d'entrer, le clic parcourent, et double-cliquer le nom du compte de services de mémoire de message. C'est le compte ce les logins de service de Basculement As.

    Le compte que vous sélectionnez doit avoir le droit d'agir en tant qu'élément du système d'exploitation et d'ouvrir une session comme service, et doit être un membre du groupe d'administrateurs locaux.

    attention Attention : Vous devez spécifier le même compte sur les serveurs primaires et secondaires.

  8. Dans le domaine de mot de passe, entrez le mot de passe pour le compte que le service de Basculement ouvre une session comme, et cliquez sur Next.

  9. Sur le commencer configurant votre page de serveur, cliquez sur Configure. L'assistant vérifie des configurations et configure le Basculement sur le serveur primaire.

    Si l'assistant ne termine pas la configuration avec succès, un message d'erreur explique pourquoi l'assistant a manqué. Quittez l'assistant, corrigez le problème, et cliquez sur Configure de nouveau.

  10. À la page se terminante, cliquez sur Finish.

Configurez le Basculement sur le serveur secondaire

Procédez comme suit :

  1. Sur la barre des tâches Windows, double-cliquer l'horloge système. La boîte de dialogue Properties de date/heure apparaît.

  2. Placez l'heure à la mêmes heure et minute qu'affichée sur le serveur primaire, et cliquez sur OK.

  3. Dans l'Explorateur Windows, parcourez au répertoire de CommServer.

  4. Double-cliquer FailoverConfig.exe pour commencer l'assistant de Basculement de Cisco Unity de configurer.

  5. Sur l'écran de bienvenue, cliquez sur Next.

  6. À la page de rôle de serveur de spécifier, cliquez sur le serveur secondaire, et cliquez sur Next.

  7. Sur l'entrer le nom de votre page de serveur, clic parcourent, sélectionnent le nom du serveur primaire, et cliquent sur OK. L'adresse IP pour le serveur primaire est complétée automatiquement.

  8. Cliquez sur Next (Suivant).

  9. À la page des informations du compte de Basculement d'entrer, le clic parcourent, et double-cliquer le nom du compte de services de mémoire de message. C'est le compte ce les logins de service de Basculement As.

    Le compte que vous sélectionnez doit avoir le droit d'agir en tant qu'élément du système d'exploitation et d'ouvrir une session comme service, et doit être un membre du groupe d'administrateurs locaux.

    attention Attention : Vous devez spécifier le même compte sur les serveurs primaires et secondaires.

  10. Dans le domaine de mot de passe, entrez le mot de passe pour le compte que le service de Basculement ouvre une session comme et cliquez sur Next.

  11. Sur le commencer configurant votre page de serveur, cliquez sur Configure. L'assistant vérifie des configurations et configure le Basculement sur le serveur secondaire.

    Si l'assistant ne termine pas la configuration avec succès, un message d'erreur explique pourquoi l'assistant a manqué. Quittez l'assistant, corrigez le problème, et cliquez sur Configure de nouveau.

  12. À la page se terminante, cliquez sur Finish.

Question de Basculement d'Unity

Problème : Recevez les erreurs de réplication SQL toutes les 10-15 minutes

En cas le visualiseur, ce message d'erreur est reçu :

Event Type:	Warning
Event Source:	CiscoUnity_NodeMgr
Event Category:	Run 
Event ID:	1014
Date:		6/25/2010
Time:		12:32:37 PM
User:		N/A
Computer:	AXLDUM01
Description:
Error getting status of SQL Server replication between the primary and 
secondary machines. Unable to get status of SQL Server subscription to 
publication UnityDbPublication for AXLDUM02. Error = 0x80045510.  This may 
be a temporary condition. If not, recreate the subscription and the 
publication snapshot to restore replication.

Solution

Exécutez ces étapes pour résoudre ce problème :

  1. Dans le menu de démarrage de Windows du serveur primaire, allez aux programmes > à la Microsoft SQL Server > au gestionnaire d'entreprise.

  2. Dans le volet gauche, développez les Microsofts SQL Server > le groupe de Serveur SQL.

  3. Dans le volet gauche, sous le groupe de Serveur SQL, <Servername> de clic.

  4. Dans le menu Tools de gestionnaire d'entreprise de Serveur SQL, la réplication > le débronchement de clic éditant et distribution.

  5. Dans l'accueil à la fenêtre d'assistant d'édition et de distribution du débronchement, cliquez sur Next.

  6. Dans la boîte de dialogue de édition de débronchement, cliquez sur oui, désactivez l'édition sur le <Servername>, et cliquez sur Next. Puis, exécutez les étapes qui apparaissent sur l'écran afin de désactiver l'édition sur le serveur primaire.

  7. Réexécutez l'assistant de configuration de Basculement de Cisco Unity sur le serveur primaire.

    Remarque: Soyez sûr d'employer le compte correct de Cisco Unity (l'Unity installent) pour exécuter le FCW.

  8. Allez aux programmes > à l'utilitaire réseau de Microsoft SQL Server > de client sur le serveur primaire.

  9. Sous l'onglet Général, confirmez que les protocoles activés par commande est de TCP/IP et de canaux désignés comme affiché ici :

    http://www.cisco.com/c/dam/en/us/support/docs/unified-communications/unity/91961-sql-svr-rep-cu-failover-01.gif

  10. Sous l'onglet de pseudonyme, cliquez sur Add, placez le nom d'ordinateur du serveur secondaire d'Unity dans le serveur alias, et cliquez sur OK.

    http://www.cisco.com/c/dam/en/us/support/docs/unified-communications/unity/91961-sql-svr-rep-cu-failover-02.gif

    http://www.cisco.com/c/dam/en/us/support/docs/unified-communications/unity/91961-sql-svr-rep-cu-failover-03.gif

  11. De même, exécutez les étapes de 8 à 10 pour le serveur secondaire. Ici sur le serveur secondaire sous l'onglet de pseudonyme, cliquez sur Add et placez le nom du serveur primaire d'Unity comme serveur alias, et cliquez sur OK.

  12. Réexécutez l'assistant de configuration de Basculement de Cisco Unity sur le serveur secondaire.

Modification qui rend compte pour posséder les travaux de réplication

Par défaut, le domaine windows rend compte pour posséder les travaux de réplication. Ceci ajoute une certaine complexité en introduisant des dépendances sur l'authentification de Windows et sur la transmission de réseau. Le Serveur SQL a deux comptes intégrés qui ne sont pas des comptes de domaine windows et sont seuls au Serveur SQL. Afin de ramener des dépendances, propriété de modification des travaux de réplication à un de ces comptes de Serveur SQL :

  • Le compte SA est le compte administratif de Serveur SQL intégré. Ce compte a un haut niveau de l'accès.

  • Le compte de distributor_admin est créé quand la réplication est configurée. Ce compte a un niveau plus bas de l'accès que le compte SA.

Changez le compte qui possède les travaux de réplication

Procédez comme suit :

  1. Commencez le gestionnaire d'entreprise de Serveur SQL.

  2. Dans le volet gauche du gestionnaire d'entreprise, développez les Microsofts SQL Server > le groupe de Serveur SQL > (gens du pays) (Windows NT) > agent de Gestion > de Serveur SQL, et cliquez sur les travaux.

  3. Pour la première réplication le travail l'a répertorié dans le tableau 1, clique avec le bouton droit sur le travail, et clique sur Properties.

  4. Sur l'onglet Général, dans la liste de propriétaire, clic le nom du compte que vous voulez pour posséder le travail. Cisco recommande que vous choisissiez le compte de distributor_admin.

  5. Cliquez sur OK pour fermer la boîte de dialogue Properties de <job>.

  6. Répétez les étapes 3 à 5 pour le reste des travaux dans le tableau 1.

  7. Redémarrez tous les travaux de réplication :

    1. Pour le premier travail de réplication répertorié dans le tableau 1, cliquez avec le bouton droit le travail et cliquez sur le travail d'arrêt.

    2. Cliquez avec le bouton droit le travail et cliquez sur le travail de début.

    3. Répétez les étapes a et b pour le reste des travaux dans le tableau 1.

D'autres améliorations pour la surveillance de réplication

Une question en suspens avec les travaux de réplication de Serveur SQL de surveillance est que quelques travaux commencent seulement une fois, quand le Serveur SQL et le service SQLSERVERAGENT sont commencés. En conséquence, si les travaux échouent, ils entraînent seulement un événement à sont enregistré. (D'autres travaux de réplication commencent, arrêt « vont dormir, » et puis redémarrer. Ces travaux se connectent une erreur chaque fois que ils ne commencent pas.)

Surveillez continuellement le statut des travaux qui commencent seulement une fois, le Cisco Unity machinant le groupe ajoute la surveillance des travaux de réplication à la surveillance existante du service SQLSERVERAGENT, comme décrit plus tôt dans ce document. Cette amélioration est dépistée avec l'ID de bogue Cisco CSCsi50517 (clients enregistrés seulement).

SQLSERVERAGENT : 208 : '''' De vérification d'agents de réplication de '''' de travail planifié de Serveur SQL

En cas le visualiseur, ce messge d'erreur est reçu :

SQLSERVERAGENT: 208: SQL Server Scheduled Job ''''Replication agents checkup''''
(0x8666D34A10837246B4030EA4E93E50BC) - Status: Failed - Invoked on: 2009-08-19 
03:30:01 - Message: The job failed. The owner () of job Replication agents 
checkup does not have server access.

Procédez comme suit pour résoudre ce problème :

  1. Ouvrez le paramètre d'entreprise SQL et vérifiez les travaux qui échouent.

  2. Ouvrez Properties et le vérifiez que le propriétaire est distributor_admin seulement.

  3. Redémarrez les travaux.


Informations connexes


Document ID: 91961