Aucun message portant le libellé _ALLOW_RESETLOGS_CORRUPTION. Afficher tous les messages
Aucun message portant le libellé _ALLOW_RESETLOGS_CORRUPTION. Afficher tous les messages

jeudi 17 mars 2011

Recouvrement suite à la perte des journaux courants (redolog)

Si vous devez relever une base de données dont le journaux courants (current redolog file) ont été perdus à cause d'une suppression de fichiers, d'une défaillance matériel, etc. et que vous n'avez pas de sauvegarde (backup) et bien, voici les étapes qu'il faut réaliser pour ramener la base de données en mode "open" :

Vue que les redo log courants ne sont plus disponibles alors, indiquer à la base de données que vous autoriser l'ouverture même s'il y a de la corruption

Alter system set "_allow_resetlogs_corruption" = TRUE scope=spfile;

Redémarrer la base de données en mode "mount"

shutdown immediate
Startup mount;

Lancer le recouvrement de la base de données, appliquer tout ce que vous pouvez et s'il le faut terminer avec "CANCEL"

recover database using backup controlfile until cancel;

Ouvrir la base de données en réinitialisant les journaux

alter database open resetlogs;

Regarder le statut des journaux et effectuer autant de "switch" pour que le redolog courant devienne l'un de ceux qui existe. S'il le faut, veuillez en créer avant de procéder.

ALTER SYSTEM SWITCH LOGFILE;

Réinitialiser le paramètre permettant l'ouverture de la base de données même s'il y a de la corruption

Alter system set "_allow_resetlogs_corruption" = FALSE scope=spfile;

Redémarrer la base de données en mode "normal"

shutdown immediate;
startup;

Et pour terminer, très important, effectuer un export complet de vos données puis créer une nouvelle base de données et importer ces données.
Publié par à 1 commentaire:
Libellés : , , , ,

mercredi 22 septembre 2010

OOW 2010 - Jour 3

Trop souvent les entreprises négligent complètement la prise de copie de sécurité et, ceux qui en prennent, négligent les essais de recouvrement. Pourquoi les gens aiment tant jouer avec le risque ? Personnellement, ça me renverse! Jamais je ne pourrais avoir la conscience tranquille tant et aussi longtemps que je n'aurais pas effectué des copies de sécurité et réaliser des scénarios de recouvrement. Ceci devrait être la ou l'une des premières règles qu'un DBA devrait suivre. D'autant plus, pouvez-vous bien me dire pourquoi qu'il y a tant d'entreprises qui n'utilisent pas RMAN ? Cet utilitaire a fait ses preuves depuis plusieurs années et aucun autre utilitaire ne peut être aussi fiable que lui.

Je vous parle de sauvegarde et de recouvrement car aujourd'hui, j'ai eu l'opportunité d'assister à des conférences au sujet de " Recovery Manager ". Le premier conférencier nous à présenter une multitude de scénarios de recouvrement. Certains dont je classifierais de classique et d'autres plutôt tordus qui ne sont pas supporté par Oracle. Ces derniers sont plutôt pratiques quand nous n'avons vraiment pas le choix et qu'il faut ressusciter une base de données. Voici ce qui peut être utile pour effectuer un recouvrement incomplet et forcer l'ouverture de la base de données :
  • _ALLOW_RESETLOGS_CORRUPTION=TRUE
  • _CORRUPTED_ROLLBACK_SEGMENTS=(RBS1,RBS2,..)
  • UNDO_MANAGEMENT=MANUAL
  • EVENT = "10015 TRACE NAME ADJUST_SCN LEVEL 1"

Quand il n'y a vraiment plus de possibilité alors vous pouvez vous en remettre au support d'Oracle puis utiliser " Data Unloader (DUL) ". Cet utilitaire permet de lire les données directement dans les fichiers de données sans passer par le noyau d'Oracle.

Autres points d'intérêt abordés lors des conférences :

  • Il est possible de recréer un fichier de paramètre (pfile) à partir de la mémoire. Il suffit d'exécuter la commande " CREATE PFILE " et spécifier à la toute fin " FROM MEMORY ".
  • DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER() retourne le SCN en cours de la base de données.
  • Il est possible de restaurer un fichier de données lors de la perte de celui-ci et que vous n'avez pas de sauvegarde de ce fichier. Si le fichier de données est inscrit dans le fichier de contrôle, la commande RESTORE créée le fichier de données dans l'emplacement d'origine et la commande RECOVER applique les journaux nécessaires pour le fichier de données.
  • Si vous soupçonnez une corruption de blocs de données, DBVERIFY est un utilitaire qui effectue une vérification de l'intégrité de la structure des données physiques sur une base de données.
  • La commande BLOCKRECOVER peut restaurer et récupérer des blocs individuels au sein d'un fichier de données. Cette procédure est utile quand seulement un petit nombre de blocs sont corrompus.
  • Le package DBMS_BACKUP_RESTORE est utilisé comme une interface PL/SQL en ligne de commande pour le remplacement des commandes natives RMAN.

Oracle ORION
Oracle ORION est un outil pour vérifier les performances de type I/O pour les systèmes de stockage qui sont destinés à être utilisés pour les bases de données Oracle. Les résultats obtenus sont utiles pour comprendre les capacités de performance d'un système de stockage, soit pour découvrir les causes qui pourraient influer sur le rendement d'une base de données Oracle. ORION est un outil autonome, on n'a pas à créer et d'exécuter une base de données Oracle pour l'utiliser.


Pour le plaisirs, je vous invite à regarder les vidéos suivants sur youtube.com :
Publié par à Aucun commentaire:
Libellés : , , , , , , , , , , , , ,
S'abonner à : Messages (Atom)