Monday, February 27, 2017

Exchange 2016 (11) : maintenance des bases de données

English summary: with Exchange 2010 SP1, the ISINTEG tool was replaced with the New-MailboxRepairRequest PowerShell cmdlet (ISINTEG should no longer be used). However, the related Get-MailboxRepairRequest (useful for observing the progression of the task) was not functional in Exchange 2010. We had to wait for later versions of Exchange, notably 2013 and 2016. Using an Exchange 2016 test environment, I take a new look at the *-MailboxRepairRequest cmdlets and review the status of another Exchange maintenance tool: ESEUTIL. In particular, I concentrate on the M* options (MH, MK, ML).

***

J'ai abordé le sujet de la maintenance des bases de données pour Exchange 2010 dans un texte du 22 novembre 2015 (en anglais) :

Exchange 2010 - ESEUTIL - ISINTEG - New-MailboxRepairRequest

A ma connaissance, rien de substantiel n'a changé depuis mais je voulais tout de même revoir ces concepts, maintenant que j'ai accès à un serveur Exchange 2016 (CU3).

Avec Exchange 2010, nous pouvions exécuter la commande New-MailboxRepairRequest (avec divers paramètres) mais nous ne pouvions pas observer le progrès de l'opération avec la commande Get-MailboxRepairRequest.

Get-MailboxRepairRequest


Voici d'autres remarques...
  • ISINTEG n'est plus une option valable depuis Exchange 2010 SP1. L'outil se trouve toujours dans le dossier \bin mais il n'a pas été mis à jour pour les bases de données Exchange 2013 et 2016. Il serait donc extrêmement risqué d'insister à utiliser cet utilitaire dépassé. De plus, il fallait démonter les bases de données avant d'exécuter cette commande, ce qui n'est pas le cas pour New-MailboxRepairRequest.
  • ESEUTIL avec les paramètres /P ou /R - Ces options ont pour objectif de réparer ou de recupérer (repair or recover) des base de données. Le risque de pertes de données est réel. Il est recommandé de ne pas utiliser ces commandes sans consulter d'abord l'assistance technique de Microsoft.
  • ESEUTIL avec le paramètre /D - Il s'agit d'une défragmentation "hors ligne" de la base de données en question. Les boîtes aux lettres ne seront pas accessibles pendant la défragmentation et celle-ci pourrait prendre beaucoup de temps selon la taille de la base de données. Par ailleurs, elle nécessite un espace libre égal à la taille de la base de données à défragmenter (et encore 10%). Au total, cette opération est de plus en plus déconseillée. Si notre environnement Exchange met en oeuvre des DAG (Database Availability Groups), il ne faut pas défragmenter les bases de données du tout. En effet, les membres du DAG reconnaissent les copies de la base de données à un numéro appelé "rand". Il faut que ce numéro soit le même pour chacune des copies d'une base de données. Or, la défragmentation crée une nouvelle base de données (avec le même nom) et déplace les boîtes aux lettres vers cette nouvelle base de données. Mais si le nom reste le même, le "rand" change et cela perturbe le fonctionnement du DAG.
  • ESEUTIL avec le paramètre /G - ce mode nous permet de vérifier si une base de données contient des incohérences. Cette vérification se fait en lecture seule et ne représente aucun risque pour la base de données. Par contre, il faut la démonter.
  • ESEUTIL avec le paramètre M (et une autre lettre : MH, ML, MK

- MH - pour voir les informations d'en-tête d'une base de données.
- ML - pour voir les informations d'en-tête d'un fichier de transaction
- MK - pour voir les informations d'en-tête d'un fichier de "checksum".

Je n'ai pas abordé cet aspect dans mon texte précédent sur ESEUTIL (voir le lien ci-dessus) et je veux me racheter ici.

Comme pour les autres commandes ESEUTIL, nous devons au préalable démonter la base de données à analyser. De plus, nous devons indiquer le chemin vers le fichier .edb ou naviguer jusqu'au fichier .edb à analyser.

Note : la base de données consiste en un fichier .edb.

Allons voir cela de plus près avec le commande ESEUTIL /MH.

Voici la base de données que nous allons analyser - MBXDB-01 :



Mais c'est à la ligne de commande que nous devons travailler.

J'ouvre donc l'invite (cmd) et après avoir navigué jusqu'à l'emplacement de la base de données, j'exécute la commande suivante :

eseutil /mh mbxdb01.edb



Qu'est-ce qui ne va pas ?

Dans la capture d'écran de l'EAC plus haut, vous avez sans doute observé que l'état de la base de données MBXDB-01 est "monté". Vous vous souvenez peut-être qu'il faut démonter les base de données avant de les manipuler avec les commandes ESEUTIL. Je vais donc démonter MBXDB-01 :

Dismount-Database MBXDB-01



Essayons la première commande à nouveau :


Nous avons mentionné un numéro qu'on appelle "rand" et qui permet aux partenaires de réplication d'identifier les bases de données qui participent à un DAG.

Ce numéro est visible dans la capture d'écran (désigné par un des points rouges).

Un autre paramètre utile à retenir est l'état de la base de données ou plutôt "state" puisqu'on garde les noms anglais.

Nous devons en tenir compte si nous effectuons une restauration de données vers un emplacement différent de l'original. Dans ce cas, l'état est normalement "Dirty Shutdown", ce qui signifie que des fichiers du journal de transaction manquent. Il faudrait alors restaurer les fichiers manquants et exécuter la commande suivante (en se fondant sur l'exemple présent) :

eseutil /r E00 /d E:\MBXDB-01 /l F:\Logs_MBXDB-01
  • Le paramètre /r signifie "recover"
  • E00 est le préfixe des fichiers de transaction. Dans le cas d'une autre base de données, il pourrait être autre chose comme E01 ou E02. Il faut regarder les fichiers du journal de transaction pour le savoir.
  • Le paramètre /d indique le chemin vers la base de données à réparer.
  • Le paramètre /l indique le chemin vers les fichiers du journal de transaction. C'est ici qu'il faut mettre les fichiers restaurés.

Et voici un exemple des paramètres ML et MK respectivement (sans autre commentaire) :




***

Et maintenant, je veux revoir les commandes New-MailboxRepairRequest et Get-MailboxRepairRequest. A la différence des commandes ESEUTIL, ces commandes n'exigent pas que la base de données soit démontée. Je vais donc remonter la base de données MBXDB-01 et exécuter quelques commandes...

Mount-Database MBXDB-01

La commande New-MailboxRepairRequest est capable de détecter et de corriger quatre types de corruption dans une boîte aux lettres spécifique ou dans toute la base de données.

Voici les quatre paramètres :

- SearchFolder
- AggregateCounts
- ProvisionedFolder
- FolderView

Si nous voulons seulement détecter des éléments endommagés, nous pouvons ajouter le paramètre -DetectOnly.

Essayons quelques exemples...

Pour commencer, analysons toute la base de données MBXDB-01 avec le paramètre -DetectOnly. J'exécute la commande de la manière suivante :

New-MailboxRepairRequest -Database MBXDB-01 -CorruptionType SearchFolder,AggregateCounts,ProvisionedFolder,FolderView -DetectOnly



J'observe le progrès de l'opération avec la commande suivante (il faut copier et coller le GUID d'où l'intérêt de la commande format-list ou "fl") :



Les valeurs possibles sont:
  • Queued
  • Running
  • Succeeded
  • Failed

A mon premier essai, l'opération semblait se coincer à l'état "Queued". Il est possible d'arrêter l'opération avec cette commande (et de recommencer) :

Get-NewMailboxRepairRequest [GUID] | Remove-NewMailboxRepairRequest

Il paraît que le démontage de la base de données arrête l'opération aussi mais cela rendrait les BAL inaccessibles.

Get-NewMailboxRepairRequest - Queued

Même pour une base de données d'essai, pratiquement vide, l'opération a mis 12 minutes pour s'achever.

Quoi qu'il en soit, l'opération termine avec succès :



Je remarque qu'Exchange analyse chaque boîte aux lettres pour chacun des types de corruption, ce qui crée de nombreuses entrées dans l'Observateur d'événements. Par exemple :



A ce sujet, il convient de préciser que, selon la documentation, l'interaction avec la boîte aux lettres risque bien de perturber l'accès pour l'utilisateur. En revanche, la base de données reste montée et seul l'accès à la BAL en cours d'analyse risque d'être perturbé. Dans l'ensemble donc, la disponibilité est tout de même meilleure qu'avec ISINTEG.

Comment savoir si des erreurs ont été détectées ? Ce n'est pas clair. Je dois supposer que la détection d'erreurs donnerait lieu à un avertissement dans l'Observateur d'événements. De plus, Get-MailboxRepairRequest contient un paramètre "Corruptions" où des erreurs seraient peut-être affichées. 

S'il y a des erreurs à réparer, nous pouvons exécuter la commande à nouveau mais sans le paramètre -DetectOnly :

New-MailboxRepairRequest -Database MBXDB-01 -CorruptionType SearchFolder,AggregateCounts,ProvisionedFolder,FolderView



Encore une fois, nous pouvons observer le progrès de l'opération avec la commande Get-MailboxRepairRequest (et limiter la sortie avec "fl jobstatus") :



Nous pouvons cibler des boîtes aux lettres spécifiques, toujours avec les même "tâches" et les mêmes options (avec ou sans le paramètre -DetectOnly).

Par exemple, nous pouvons vérifier la boîte aux lettres de Karen Roberts avec les quatre tâches et l'option -DetectOnly :

New-MailboxRepairRequest -Mailbox Karen.Roberts -CorruptionType SearchFolder,AggregateCounts,ProvisionedFolder,FolderView -DetectOnly



Si nous voulons nous concentrer sur un type spécifique de (possible) corruption, nous mettons seulement ce type-là après le paramètre -CorruptionType (avec ou sans -DetectOnly selon nos objectifs) :

New-MailboxRepairRequest -Mailbox Karen.Roberts -CorruptionType SearchFolder


No comments:

Post a Comment