Procédure de dépannage des problèmes de réplication locale en continu
S’applique à : Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Dernière rubrique modifiée : 2007-10-10
Cette rubrique explique comment dépanner des problèmes que vous pouvez rencontrer lors de l'exécution de Microsoft Exchange Server 2007 dans un environnement de LCR. Les procédures de cette rubrique abordent les problèmes suivants :
La cmdlet Get-StorageGroupCopyStatus signale que la base de données est en échec et qu'elle n'est pas amorcée.
La cmdlet Get-StorageGroupCopyStatus signale que la base de données est en échec. La valeur FailedMessage fournit des informations spécifiques sur la source de l'échec.
Des alertes, des compteurs de performance ou la cmdlet Get-StorageGroupCopyStatus indiquent que les files d'attente de copie ou de relecture sont sauvegardées pour une copie de groupe de stockage.
La cmdlet Get-StorageGroupCopyStatus signale une heure de péremption pour la valeur LastInspectedLogTime.
L'amorçage échoue.
La cmdlet Restore-StorageGroupCopy sur les rapports de LCR signale qu'Exx.log n'est pas disponible.
Lorsque des problèmes autres que ceux répertoriés ci-dessus se présentent, consultez le journal des événements pour déterminer la cause et le déroulement potentiel de l'action à exécuter pour procéder à la récupération. Une fois l'heure de la défaillance identifiée, d'autres journaux des événements peuvent vous aider à mieux comprendre le problème. Pour plus d'informations sur les outils de dépannage des problèmes de LCR, consultez la rubrique Outils de dépannage des problèmes avec les déploiements à disponibilité élevée.
Avant de commencer
Pour exécuter ces procédures, vous devez utiliser un compte auquel ont été délégués le rôle Administrateur de serveur Exchange et le groupe Administrateurs local pour le serveur cible. Pour plus d'informations sur les autorisations, la délégation de rôles et les droits requis pour administrer Exchange 2007, consultez la rubrique Considérations relatives aux autorisations.
Procédure
La cmdlet Get-StorageGroupCopyStatus signale que la base de données est en échec et qu'elle n'est pas amorcée.
Causes possibles Il y a un problème de configuration ou la copie de réplication n'a pas de base de données de base valide. Le problème pourrait également être dû à la non activation du groupe de stockage sur l'ordinateur local.
Résolution Effectuez les opérations suivantes :
Vérifiez que le stockage pour la copie est correctement configuré et opérationnel. Si vous trouvez une erreur, vous pouvez déclencher un nouveau contrôle de la copie en suspendant, puis en reprenant le groupe de stockage.
Vérifiez que les chemins de la copie de LCR sont correctement configurés. Vous pouvez le faire en utilisant la cmdlet Get-StorageGroup dans l'environnement de ligne de commande Exchange Management Shell. Pour plus d'informations sur l'utilisation de la cmdlet Get-StorageGroup pour afficher les informations de configuration, consultez la rubrique Affichage des paramètres de configuration de réplication locale en continu.
La cmdlet Update-StorageGroupCopy permet d'amorcer la copie du groupe de stockage.
La cmdlet Get-StorageGroupCopyStatus signale que la base de données est en échec et la valeur FailedMessage fournit des informations spécifiques sur la source de l'échec.
Causes possibles Un grand nombre de causes potentielles peuvent avoir pour effet qu'une copie passive soit identifiée comme en échec. La valeur FailedMessage identifie spécifiquement le problème détecté.
Résolution Vous pouvez exécuter la cmdlet Get-StorageGroupCopyStatus pour obtenir la valeur FailedMessage complète. Cette chaîne identifie le problème spécifique détecté. Si la condition signalée est un journal endommagé ou manquant, tentez de trouver un journal non endommagé avec le numéro de génération approprié. Si le journal correct est introuvable, utilisez la cmdlet Update-StorageGroupCopy pour effectuer un réamorçage. Si le message implique que les journaux sur la source ne sont pas disponibles, supprimez le partage sur le répertoire des journaux de la source et redémarrez le service de réplication Microsoft Exchange sur cet ordinateur. Analysez les informations fournies par la valeur FailedMessage et résolvez la condition identifiée.
Des alertes, des compteurs de performance ou la cmdlet Get-StorageGroupCopyStatus indiquent que les files d'attente de copie ou de relecture se développent pour une copie passive.
Causes possibles Un retard de copie ou de relecture de journal peut indiquer soit un problème, soit une condition transitoire dans un processus de récupération. Une condition transitoire se produit quand une copie passive vient d'être reprise après avoir été suspendue pendant une période prolongée. Si la condition n'est pas transitoire, le problème pourrait être dû à l'une des causes suivantes :
Il existe un problème de configuration.
L'activité de réplication est suspendue.
Le service de réplication de Microsoft Exchange est arrêté.
Le stockage est en échec ou hors connexion.
Résolution Déterminez s'il y a un problème réel ou s'il s'agit d'une condition transitoire en procédant comme suit :
Vérifiez que le service de réplication de Microsoft Exchange est en cours d'exécution. Pour ce faire, utilisez le composant logiciel enfichable Services. Si le service est arrêté, vous devez le démarrer.
Exécutez la cmdlet Get-StorageGroupCopyStatus de l'environnement de ligne de commande Exchange Management Shell avec la commande fl, puis déterminez si la copie passive est suspendue. Si elle est suspendue, vérifiez que les fichiers de la copie passive sont présents, puis reprenez la copie passive à l'aide de la cmdlet Resume-StorageGroupCopy.
Exécutez la cmdlet Get-StorageGroupCopyStatus de l'environnement de ligne de commande Exchange Management Shell avec l'option fl et déterminez si la copie est saine. Si l'état de la copie est en échec, consultez la liste des champs d'état pour déterminer l'action corrective nécessaire.
Observez les compteurs de performance de réplication pendant quelques minutes pour déterminer si l'opération est en cours. Plus particulièrement, observez le numéro de génération de relecture et le numéro de génération d'inspection. Si la longueur de la file d'attente de copie continue à augmenter alors que la longueur de la file d'attente de relecture est faible ou décroissante, il y a peut-être un problème de partage de fichiers réseau sur la copie active ou de serveur actif proprement dit. Utilisez le GUID du groupe de stockage pour vérifier qu'un partage de fichiers réseau est défini pour le répertoire des journaux de la copie du groupe de stockage active. Vous pouvez identifier le GUID du groupe de stockage à l'aide de la cmdlet Get-StorageGroupCopyStatus avec l'option fl dans l'environnement de ligne de commande Exchange Management Shell.
Get-StorageGroupCopyStatus signale une heure de péremption pour LastInspectedLogTime.
Causes possibles Il y a trois causes possibles à ce problème :
La base de données de la copie active est démontée.
La copie active est montée mais elle ne change pas à une vitesse significative. C'est pourquoi, les journaux ne sont pas produits par la copie active.
Le service de réplication de Microsoft Exchange n'est pas en cours d'exécution.
Résolution Déterminez laquelle des trois causes est rencontrée. Pour ce faire, procédez comme suit :
Déterminez si la base de données est démontée en utilisant la console de gestion Exchange ou en exécutant la cmdlet Get-StorageGroupStatus dans l'environnement de ligne de commande Exchange Management Shell. Si elle est démontée, elle doit être montée et une séquence de génération de fichiers journaux doit être créée avant que la valeur de LastInspectedLogTime ne change.
Vérifiez que le service de réplication de Microsoft Exchange est en cours d'exécution. S'il est arrêté, vous devez le démarrer.
Après avoir vérifié que la base de données est montée, vérifiez si elle génère des journaux. Consultez le répertoire des journaux de la base de données active et identifiez le fichier journal dont le numéro de génération est le plus élevé. Vérifiez l'horodatage de ce journal. Il doit correspondre à la valeur de LastInspectedLogTime.
Échec de l'amorçage
Causes possibles Une sauvegarde est en cours sur la copie active ou il y a un problème de communication.
Résolution Vérifiez qu'une sauvegarde du groupe de stockage ou de la base de données affecté n'est pas en cours.
La cmdlet Restore-StorageGroupCopy signale qu'Exx.log n'était pas disponible.
Causes possibles La cmdlet Restore-StorageGroupCopy invite à déterminer si elle doit continuer avec un fichier Exx.log manquant.
Résolution Si vous vous attendez à ce que l'activation produise une base de données qui n'a pas perdu de données, répondez Non à l'invite. Si le fichier Exx.log n'est pas disponible au moment de l'opération de la cmdlet Restore-StorageGroupCopy, la récupération est incomplète. Si vous répondez Non, vous devez résoudre les problèmes empêchant l'accès aux journaux de production. Une fois ces problèmes corrigés, vous pouvez exécuter de nouveau la cmdlet Restore-StorageGroupCopy.
Pour plus d'informations
Pour plus d'informations sur les cmdlets de l'environnement de ligne de commande Exchange Management Shell décrites dans cette rubrique, consultez les rubriques suivantes :