À ne pas mettre avant la commande "BACKUP"

En voulant prendre une copie de la commande de création du "Controlfile" de la base de données dans un script RMAN, je me suis aperçu que la série de commandes n'était pas générée dans le fichier de trace.

Après quelques essais, je me suis rendu compte que si la commande "BACKUP..." suit directement la commande "ALTER DATABASE BACKUP CONTROLFILE...", le fichier de trace se créer sans contenir les commandes SQL.

Donc. j'ai tout simplement déplacé la commande SQL à la toute fin :

run
{
BACKUP DATABASE FILESPERSET 1 PLUS ARCHIVELOG;
CROSSCHECK BACKUP;
CROSSCHECK ARCHIVELOG ALL;
DELETE NOPROMPT OBSOLETE;
DELETE NOPROMPT EXPIRED BACKUP;
DELETE NOPROMPT EXPIRED ARCHIVELOG ALL;
SQL "ALTER DATABASE BACKUP CONTROLFILE TO TRACE";
}

Ceci a été observé en effectuant une sauvegarde d'une base de données Oracle 10G Express Edition (XE) sous Linux RHEL4 sans catalogue RMAN.

Recouvrement suite à une copie en mode "begin backup"

Pour répliquer rapidement un environnement complet, nous utilisons le logiciel "ShadowImage". Cette opération permet de créer une image complet d'un serveur pour ensuite diagnostiquer des problèmes majeurs survenu sur cet environnement.

L'environnement répliqué consiste à un serveur Sun Solaris 10 sur lequel réside une base de données 10gR2 Enterprise Edition.

Pour que la cpoie répliquée de la base de données soit fonctionnelle, nous mettons celle-ci en mode "begin backup" avant de démarrer le processus de copie. Malgré cela, une fois que le processus est terminé, nous rencontrons des problèmes avec la base de données copiée. Voici les problèmes rencontrées avec leurs solutions :

Recouvrement du tablespace SYSTEM
ERROR at line 1:
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1: '/uprodz2-obd001_u02/oradata/P059/system01.dbf'

Mettre la base de données en mode "mount" :

sqlplus / as sysdba
shutdown immediate
startup mount

2 scénarios possibles :

1. Recouvrement à partir d'un copie de sécurité des controlfiles

1.1 Récupérer des anciens CONTROLFILE qui furent générés par la commande :

alter database backup controlfile
to '/u01/home/dba/oracle/admin/ORCL/udump/control.2010-09-16-09:00.bkp';

prendre un copie du controlfile puis copier le backup controlfile aux 2 endroits

1.2 Recouvrer la base de données à l'aide des controlfiles récupérés

Recover database until time '2010-10-15 09:00:00' using backup controlfile;
OU
Recover database using backup controlfile until cancel;

Si nécessaire, ne pas hésiter à proposer les redofiles non archivés comme fichier d'archive afin de compléter le recouvrement

1.3 Ouvrir la base de données

alter database open resetlogs;

il est fortement conseillé de prendre une copie de sécurité de toute la base de données avant d'exécuter une ouverture de la base de données avec l'option "RESETLOGS".

2. Recouvrement à partir des controlfiles courants (actuels)

2.1 Recouvrer la base de données avec la commande suivante à partir des controlfiles actuels

Recover database until time '2010-10-15 09:00:00' using backup controlfile;

Si nécessaire, ne pas hésiter à proposer les redofiles non archivés comme fichier d'archive afin de compléter le recouvrement

2.2 Ouvrir la base de données

alter database open resetlogs;

il est fortement conseillé de prendre une copie de sécurité de toute la base de données avant d'exécuter une ouverture de la base de données avec l'option "RESETLOGS".


Corruption du tablespace UNDO

Lors du démarrage de la base de données, si celle-ci tarde beaucoup à démarrer ou que le démarrage renvoi une erreur ORA-600 avec l'argument [4194], c'est probablement occasionné par une corruption dans les segments du tablespace " undo ".

Avant de procéder tel qu'indiqué, assurez-vous que le fichier " alert_ORCL.log " contient bel et bien des lignes affichant le code d'erreur mentionné précédemment.

Compte tenu que le contenu du tablespace " undo " sert à conserver les transactions non sauvegardées (non commit), on peut détruire ces données sans danger. Voici les étapes pour recréer le tablespace " undo " :

sqlplus / as sysdba

Alter database open;

create undo tablespace undo2
datafile '/u05/oradata/ORCL/undo02.dbf' size 50 m
autoextend on;

alter system set undo_tablespace = undo2 ;

drop tablespace undo including contents and datafiles ;

create undo tablespace undo
datafile '/u05/oradata/ORCL/undo01.dbf' size 1000 m
autoextend on ;

alter system set undo_tablespace = undo ;

drop tablespace undo2 including contents and datafiles ;

Pour réaliser les commandes précédentes, il se peut que vous soyez dans l'obligation de désactiver la gestion automatique des segments " undo " :

sqlplus / as sysdba
startup mount
create pfile from spfile;

Modifier le paramètre suivant dans le fichier " initORCL.ora " :
undo_management = MANUAL

shutdown immediate
startup pfile=initORCL.ora

Une fois l'intervention terminée, n'oubliez pas de revenir en mode "spfile".


Il y a un autre cas, que l'un de mes collègues a rencontré. Il a eu à recréer les controlfiles pour ressusciter la base de données.

Voyage dans le... passé

La mise à niveau d'une base de données Oracle nous force à se questionner sur la possibilité d'un retour arrière. En effet, malgré que nous prenions toutes les précautions possibles et que
nous testions les applications, un problème important peut surgir et nous forcer à réaliser un retour arrière vers les versions de bases de données originales.

Le retour arrière n'est jamais l'idéal sauf qu'il vaut mieux prévoir une méthode afin de minimiser les impacts et les problèmes. C'est à ce moment que la fonctionnalité "FLASHBACK DATABASE" attire mon attention.

Flashback Database permet de ramener la base de données entière à un état dans le passé. Elle utilise des journaux (Flashback log) et, quand elle est activée, ces journaux sont créés à l'emplacement nommé « flash recovery area ». Oracle s'occupe de créer, détruire et redimensionner les journaux automatiquement. À l'occasion, il faut vérifier l'espace qui est disponible pour le flashback area.

Pour utiliser le « flashback database », le « flash recovery area » doit être mis en place.

Voici quelques prés requis :

ACTIVATION DES FONCTIONNALITÉS
Pour utiliser la fonctionnalité « FLASHBACK DATABASE », Le mode d'archive et la fonctionnalité « flashback database » doit être activé sur la base de données.

Voici comment vérifier l'état des fonctionnalités :

SELECT flashback_on, log_mode
FROM v$database;

Vérifier la valeur des paramètres lies à la fonctionnalité « flashback
database » :

col name format A30 wrap
col value format A20 wrap
SELECT inst.instance_name, parm.name, parm.value
FROM gv$parameter parm, gv$instance inst
WHERE parm.inst_id = inst.inst_id
and (name LIKE '%flashback%'or name LIKE '%recovery%')
order by 1,2;

Initialiser les paramètres pour le « Flashback » :

ALTER SYSTEM SET DB_FLASHBACK_RETENTION_TARGET = 1440;
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST = '+FRAGRP01' SCOPE= BOTH;
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE = 2G SCOPE=BOTH;

Fermer l'instance :

Si c'est une instance faisant partie d'un cluster (RAC), veuillez fermer
toutes les instances en suivant l'exemple ci-dessous :

srvctl stop database -d BD

Autrement, fermer l'instance comme suit:

shutdown immediate

Démarrer l'instance en mode « mount »

startup mount exclusive;

Activer le mode ARCHIVE (si nécessaire)

Alter database archivelog;

Activer la fonctionnalité « FLASHBACK DATABASE »

Alter database flashback on;

CRÉATION DU POINT DE RESTAURATION
Un point de restauration doit être marqué dans le temps pour être en mesure de le référer dans l'éventualité où nous en aurions besoin. Ce point de restauration doit être créé avant la migration de la base de données.

Voici comment procéder pour créer le point de restauration :

Fermer l'instance :

shutdown immediate

Démarrer l'instance en mode « mount » :

startup mount exclusive;

Créer le point de restauration :

CREATE RESTORE POINT avant_upgrade GUARANTEE FLASHBACK DATABASE;

Vérifier l'existence de point de restauration créé précédemment :

SELECT NAME, SCN, TIME,
DATABASE_INCARNATION# DI,
GUARANTEE_FLASHBACK_DATABASE,
STORAGE_SIZE FROM V$RESTORE_POINT
WHERE GUARANTEE_FLASHBACK_DATABASE='YES';

Vérifier l'état actuel des composantes de la base de données :

select comp_name, status, version from dba_registry;

Fermer l'instance :

shutdown immediate

À partir de ce point, la migration peut débuter.

PARTICULARITÉS
Il ne faut pas modifier la valeur du paramètre « COMPATIBLE ». Autrement, le mécanisme de retour arrière peut ne pas fonctionner adéquatement. Le changement de valeur va identifier tous les fichiers de la base de données comme étant des fichiers de la nouvelle version et, vous
observerez une erreur semblable lors du démarrage de l'instance :

ORA-00201: control file version 10.2.0.4.0 incompatible with ORACLE version
10.2.0.3.0
ORA-00202: control file: '+FRAGRP01/orcl/controlfile/current.263.660837815'

RESTAURATION
Si vous devez ramener votre base de données à l'état où elle était avant la migration, il vous suffit de suivre ces étapes :

Fermer l'instance:

shutdown immediate

Démarrer l'instance en mode « mount » :

startup mount

Restaurer la base de données au point de restauration :

Flashback database to restore point avant_upgrade;

Fermer l'instance :

shutdown immediate

N'oubliez pas de réinitialiser toutes les variables d'environnement incluant ceux des autres noeuds si vous êtes sur un environnement RAC.

Après avoir réinitialisé les variables d'environnements, il faut :

Démarrer l'instance:

startup mount

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

Alter database open resetlogs;

Vérifier l'état actuel des composantes de la base de données :

select comp_name, status, version from dba_registry;

N'oubliez pas de reprendre une copie de sauvegarde de la base de données.

DÉSACTIVATION DE LA FONCTIONNALITÉ
Pour désactiver la fonctionnalité « FLASHBACK DATABASE », voici les étapes à
suivre :

Voici comment le vérifier :

SELECT flashback_on FROM v$database;

Fermer l'instance :
Si c'est une instance faisant partie d'un cluster (RAC), veuillez fermer toutes les instances en suivant l'exemple ci-dessous :

srvctl stop database -d BD

Autrement, fermer l'instance comme suit:

shutdown immediate

Démarrer l'instance en mode « mount » :

startup mount exclusive;

Désactiver la fonctionnalité « FLASHBACK DATABASE » :

Alter database flashback off;

Cette solution de retour en arrière s'applique seulement dans le cas où la migration ne s'effectue pas correctement. Toutes les transactions suivant la migration, incluant celles provenant des applications maisons, seront perdues si un retour en arrière est effectué.