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 :

• Iron Man: Man. Machine. Hero. Oracle. Software. Hardware. Complete. (http://www.youtube.com/watch?v=L5cO2R-b39M)
• Exadata Iron Man display at Oracle Open World 2010 (http://www.youtube.com/watch?v=nzZs2SlJuGA)
  
• As we waited to enter Hall D for the Welcome Keynotes we were entertained by a display of the Iron Man / Oracle teaser trailers plus the actual suits from the movie. (http://www.youtube.com/watch?v=pBW5napyM80)
  
• Highlights from Oracle CEO Larry Ellison's welcome keynote at Oracle OpenWorld 2010 on Sunday September 19 (http://www.youtube.com/watch?v=tWB0fR-buJ4)
• OpenWorld's 2010 Welcome Keynote ended with Larry's announcement. Leaving Hall D (http://www.youtube.com/watch?v=mYEmjp3Bpdc)

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.