Dans le cadre de ma nouvelle mission, j’ai récemment été confronté à un problème avec la solution de sauvegarde ARCserve.

Après chaque opération sur certaines bases de données internes du logiciel, le moteur de BDD se mettait en erreur empêchant les opérations suivantes d’avoir lieu.Quelques recherches effectuées sur Internet montrent que le défaut viendrait d’une corruption de la base de données. Cette indication nous a été fournie par une * présente entre parenthèse à côté du JobID (ex. 14(*) ).

Le moteur VLDB étant assez sensible aux coupures intempestives et autres plantages qui peuvent survenir, je vous invite à être très prudent sur les machines faisant tourner ArcServ.

Pourquoi un moteur de base de données ? Pour y stocker les index des fichiers sauvegardés, dates de modifications, chemins de sauvegardes, …

Ce moteur VLDB fourni l’accès au bases suivantes :

  • asjob,
  • aslogerr,
  • asmedia,
  • asmsg,
  • asobject,
  • asrhost,
  • astape,
  • astpdrv,
  • astpsdat.

Une première solution, trouvée sur les forums anglophones suggère une réinitialisation complète de la BDD, et par conséquent la perte des sauvegardes précédentes, autant dire que j’étais quand même moyennement chaud.

Puis je suis tombé sur le blog des Cogitations Peckiennes, et plus particulièrement sur l’article : BrightStor ARCserve (11.5) : Problème du moteur de BDD qui s’arrête qui présente une solution permettant de tenter une réparation de la BDD sans perdre les données déjà présentes.

Le détail de la solution, est le suivant :

  1. Relancer les services ARCserve pour être sur qu’ils tournent tous correctement,
  2. Arrêter tout job qui pourrait tourner dans les prochaines heures (plus de 24h dans mon cas),
  3. Vérifier quelle(s) base(s) présente(nt) des erreurs,
  4. Corriger les erreurs,

Tout les utilitaires sont directement accèssibles en ligne de commande depuis le répertoire d’ARCserve, lancez donc un shell et placez vous dans le bon répertoire, et commencez par relancer les services :

Cstop.bat
Cstart.bat

Puis, ouvrez votre interface d’administration pour arrêter tout les jobs.

Ensuite, il vous suffit de vérifier quelles sont les bases qui présentent des erreurs, avec la commande :

dbcheck -a -L casdb;admin;secret [BDD]

N’essayez pas de remplacer le admin et le secret par les valeurs que vous auriez configurées ailleurs dans le logiciel, ce sont les valeurs admin/secret que vous devez mettre et rien d’autre.

Vous pouvez interrompre la vérification une fois que des erreurs ont été trouvées, vu que l’étape suivante lance de toute façon un dbcheck pour savoir quelles sont les entrées de la base qu’il doit corriger.

Une fois les bases corrompues isolées, nous allons pouvoir les corriger avec un petit :

dbfix -a -L casdb;admin;secret [BDD]

Une fois le dbfix fini, je vous conseille de faire un .bat avec toute les bases que vous avez identifié comme comportant des erreurs précédemment, de le lancer et de plus vous en occuper pendant au moins 4 ou 5 heures mini., on peut passer à la phase d’optimisation.

On commence donc par un élagage (exécutez simplement le job d’élagage via l’interface). Puis, les opérations de defragmentation de la base et de reconstruction d’index (à faire dans cet ordre, et pas l’inverse) que vous pourrez lancer via les commandes :

dbdefrag -a -L casdb;admin;secret [BDD]
keybuild -k -L casdb;admin;secret [BDD]

Encore une fois, je recommande l’usage d’un fichier de commande avec cette fois-ci l’intégralité des bases de la liste.

 

Voilà, ce petit tuto à résolu mon problème au boulot, j’espère qu’il en sera de même pour vous.

http://mail.google.com/support/bin/answer.py?answer=6590http://pecky.free.fr/blog/?p=795
Leave a comment

There are no comments yet.

Laisser un commentaire