Le 21 mai 2015 une journée performance est organisée sur Lausanne.

Mon call for paper a été accepté: je vous parlerais des SQL Plan Directives – une nouvelle fonctionnalité 12c accessible aussi en Standard Edition!

Voici l’abstract:

SQL Plan Directives – la mémoire de l’optimizeur
L’optimiseur 12c peut évaluer la précision de son estimation, et se souvenir de la raison de la divergence.
C’est le début de l’intelligence artificielle pour le CBO: apprendre pour faire mieux dans le futur, même pour des requêtes différentes. Nous verrons l’utilisation de SQL Plan Directives sur des exemples pratiques, au delà de ce qui est documenté.

Il y aura aussi des présentations de Chris Antonigni, Lothar Flatz, Luca Canali et Zbigniew Baranowski

Donc à ne pas rater – réservez la date et venez nombreux !

Cette page est un index sur les cas de recovery que j’ai posté l’an dernier:

Création de la base 12c pour les cas de recovery
perte d’un datafile (non système)
perte d’un datafile SYSAUX
perte d’un datafile SYSTEM
perte d’un membre de redo log
perte de tous les redo log
perte d’un controlfile multiplexé
perte de tous les controlfiles
perte du spfile
perte de tous les fichiers (sauf FRA)
bloc corrompu

Vous voulez en savoir plus? Le workshop Oracle Backup & Recovery (3 jours)
de dbi services donne la théorie (RPO/RTO, tous les types de backups et recovery)
et vous aurez aussi l’occasion de pratiquer: scénarios de crash sur les bases du lab.

Dernière date de l’année: à Lausanne les 12,13,14 novembre.
Les supports sont en anglais mais le cours est en français. Renseignements/inscriptions:
http://www.dbi-services.com/index.php/products/dbi-insite-workshops/oracle-backup-and-recovery-workshop

ceci est la traduction de mon article sur le blog dbi-services

Attention: il ne s’agit ici que de jouer avec les mécanismes internes non documentés. A ne faire que sur une base de test prête à être jetée. Jouer avec ces mécanisme est le meilleur moyen de planter la base avec des ORA-600 et de corrompre le dictionnaire.

Sur une base multitenant (CDB) nous savons que chaque pluggable database est isolée afin d’être vue comme une seule base lorsqu’on est connecté à son service. Mais elles partagent des ressource communes puisque le but est de consolider plusieurs bases en une seule. Pas de problème pour la CPU, la mémoire, les journaux redo et undo: il ne sont gérés qu’au niveau CDB. Le multitenant n’a pas changé grand chose là dessus, à part qu’on stocke l’identificateur de conteneur dans différentes structures, par exemple dans les vecteurs de redo pour identifier les objets (object id peuvent être les mêmes entre plusieurs CDB). Au niveau des fichiers, pas de gros changements par rapport à ce qui avait été introduit avec les tablespaces transportables.

Mais ce qui a été un plus gros challenge pour les développeurs d’Oracle 12c, c’est surtout la manière d’implémenter le dictionnaire. Il a été séparé:

• Tout ce qui est interne au fonctionnement d’Oracle, les métadonnées du dictionnaire, les packages dbms_…, tout ce qui est stocké pour toute l’instance: tables de références, repository AWR, etc. C’est le but: consolider, ne pas répéter plusieurs fois ce qui est identique du moment qu’on est sur la même version d’Oracle
• Toutes les métadonnées qui concernent l’application: les tables et packages que vous avez créé. Celles-ci sont propres à chaque pluggable tablespace, et sont transportées, clonées avec les oprérations de plug/unplug

et finalement, comme le but principal d’Oracle étant de pouvoir faire dans une PDB tout ce qu’on peut faire sur base, il faut pouvoir foir au niveau PDB les informations stockées au niveau CDB.

Tout ça semble un peu magique par rapport à ce qu’on connait d’Oracle qui n’a jamais fait cette séparation. Par exemple depuis le début d’Oracle on a dans la table SYS.TAB$ les informations de nos tables, ainsi que les informations des tables du dictionnaire – incluant les métadonnées de la table SYS.TAB$ elle-même. La documentation ne va pas très loin sur la manière dont ça a été implémenté. Heureusement on a quelques scripts dans ?/rdbms/admin qui donnes des idées là dessus. ils utilisent une syntaxe un peu particulière, non documentée, et qui n’est disponible que lorsque les scripts internes mettent le paramètre non documenté « _ORACLE_SCRIPT »=true.

Maintenant, ce sont des trucs de geek qui arrivent. Rien à voir avec ce qu^’on fait en production. Nous allons créer nos propres liens objet et métadonnée. Ce qui est fait dans la suite est fait dans une session avec « _ORACLE_SCRIPT »=true. On va voir des nouveaux éléments de syntaxe: cdb$view(), sharing=metadata, sharing=object, common_data

Container data objects

D’abord nous allons voir comment au niveau CDB la racine CDB$ROOT peut voir les informations des autres conteneurs (PDB)

Je suis au niveau CDB:

SQL> alter session set container=cdb$root;
Session altered.

SQL> show con_name
CON_NAME
------------------------------
CDB$ROOT

SQL> show con_id
CON_ID
------------------------------
1

et je créé une table normale:

SQL> create table DEMO_REG_TABLE sharing=none as select 111 dummy from dual;
Table created.

SQL> select * from DEMO_REG_TABLE;
     DUMMY
----------
       111

Puis je fais exactement la même chose dans la PDB:

SQL> alter session set container=pdb1;
Session altered.

SQL> show con_name
CON_NAME
------------------------------
PDB1

SQL> show con_id
CON_ID
------------------------------
3

SQL> create table DEMO_REG_TABLE sharing=none as select 999 dummy from dual;
Table created.

SQL> select * from DEMO_REG_TABLE;
     DUMMY
----------
       999

et de retour dans la racine, j’utilse la fonction de table CDB$VIEW pour voir ce que j’ai dans chacune de mes PDB:

SQL> select * from  cdb$view(DEMO_REG_TABLE) where con_id in (1,3);
     DUMMY     CON_ID
---------- ----------
       999          3
       111          1

C’est comme ça que les ‘container objects’ sont définis: ils utilisent la fonction CDB$VIEW pour exécuter une requête sur chaque PDB, consolider le résultat et rajouter l’identifiant de PDB: CON_ID pour montrer d’où viennent les lignes.

Vous voulez savoir comment c’est implémenté? Il semble que ce soit le mécanisme de parallel query qui soit utilisé. Voici la preuve:

SQL> select * from  cdb$view(DEMO_REG_TABLE);
select * from  cdb$view(DEMO_REG_TABLE)
*
ERROR at line 1:
ORA-12801: error signaled in parallel query server P002
ORA-00942: table or view does not exist

Lorsque la table n’est pas trouvée (j’ai volontairement créé une table sur quelques conteneurs seulement) c’est un process parallel query qui renvoit l’erreur.

Metadata links

Maintenant, je vais créer une fonction PL/SQ dans la racine et dans une PDB, mais je n’ai pas envie de dupliquer le code dans les deux tablespaces SYSTEM. Je vais utiliser SHARING=METADATA pour créer un metadata link.

SQL> alter session set container=cdb$root;
Session altered.

SQL> show con_name
CON_NAME
------------------------------
CDB$ROOT

SQL> show con_id

CON_ID
------------------------------
1

SQL> create function DEMO_MDL_FUNCTION sharing=metadata
  2  return varchar2 as dummy varchar2(100); begin select max(dummy) into dummy from DEMO_REG_TABLE; return dummy; end;
  3  /
Function created.

SQL> select DEMO_MDL_FUNCTION from dual;
DEMO_MDL_FUNCTION
------------------------------
111

SQL> alter session set container=pdb1;
Session altered.

SQL> show con_name
CON_NAME
------------------------------
PDB1

SQL> show con_id
CON_ID
------------------------------
3

SQL> create function DEMO_MDL_FUNCTION sharing=metadata
  2  return varchar2 as dummy varchar2(100); begin select max(dummy) into dummy from DEMO_REG_TABLE; return dummy; end;
  3  /
Function created.

SQL> select DEMO_MDL_FUNCTION from dual;
DEMO_MDL_FUNCTION
------------------------------
999

Je peux donc voir le code dans SYS.SOURCE$ de la racine:

SQL> alter session set container=cdb$root;
Session altered.

SQL> select * from source$ where obj# in (select obj# from obj$ where name like 'DEMO%');

      OBJ#       LINE SOURCE
---------- ---------- ------------------------------
     95789          1 function DEMO_MDL_FUNCTION

Mais rien dans ma PDB:

 
SQL> alter session set container=pdb1;
Session altered.

SQL> select * from source$ where obj# in (select obj# from obj$ where name like 'DEMO%');

no rows selected

Object links

Ceci était pour ne stocker les métadonnées qu’à un seul endroit, dans la racine, en ayant seulement un lien dessus dans les PDB. On peut aussi faire la même chose pour des données qu’on ne veut stocker que dans la racine, en utilisant SHARING=METADATA pour créer la table et SHARING=OBJECT pour créer une vue dessus

SQL> alter session set container=cdb$root;
Session altered.

SQL> show con_name
CON_NAME
------------------------------
CDB$ROOT

SQL> show con_id
CON_ID
------------------------------
1

SQL> create table DEMO_MDL_TABLE sharing=metadata as select 111 dummy from dual;
Table created.

SQL> alter session set container=pdb1;
Session altered.

SQL> show con_name
CON_NAME
------------------------------
PDB1

SQL> show con_id

CON_ID
------------------------------
3

SQL> create table DEMO_MDL_TABLE sharing=metadata as select 999 dummy  from dual;
Table created.

 
SQL> alter session set container=cdb$root;
Session altered.

SQL> select * from  cdb$view(DEMO_MDL_TABLE) where con_id in (1,3);

     DUMMY     CON_ID
---------- ----------
       999          3
       111          1

SQL> alter session set container=cdb$root;
Session altered.

SQL> show con_name
CON_NAME
------------------------------
CDB$ROOT

SQL> show con_id
CON_ID
------------------------------
1

SQL> create view DEMO_OBL_VIEW sharing=object as select * from DEMO_MDL_TABLE;
View created.

SQL> select * from DEMO_OBL_VIEW;
     DUMMY
----------
       111

 
SQL> alter session set container=pdb1;
Session altered.

SQL> show con_name
CON_NAME
------------------------------
PDB1

SQL> show con_id
CON_ID
------------------------------
3

SQL> create view DEMO_OBL_VIEW sharing=object as select * from DEMO_MDL_TABLE;
View created.

SQL> select * from DEMO_OBL_VIEW;
     DUMMY
----------
       111

La vue montre les données stockées dans CDB$ROOT en suivant le ‘object link’ au lieu de lire la table du container courant.

On ne peut pas insérer directement dans un ‘object link':

SQL> insert into DEMO_OBL_VIEW select 9999 dummy from dual;
insert into DEMO_OBL_VIEW select 9999 dummy from dual
            *
ERROR at line 1:
ORA-02030: can only select from fixed tables/views

et on a une idée de l’implémentation en regardant le plan d’exécution:

---------------------------------------------
| Id  | Operation        | Name             |
---------------------------------------------
|   0 | SELECT STATEMENT |                  |
|   1 |  FIXED TABLE FULL| X$OBLNK$aed0818c |
---------------------------------------------

C’est une table X$ qui va faire le lien

Common data views

finalement, comment une PDB peut voir les données de la racine? Nous avons vu au dessus que la fonction que j’ai créé ci-dessus est stockée dans le SYS.SOURCE$ de la racine seulement. Par contre on peut la voir à partir du DBA_SOURCE de la PDB

SQL> alter session set container=cdb$root;
Session altered.

SQL> show con_name
CON_NAME
------------------------------
CDB$ROOT

SQL> show con_id
CON_ID
------------------------------
1

SQL> create or replace view DEMO_INT_VIEW common_data (dummy,sharing) as select dummy,case when dummy='222' then 0 else 1 end from DEMO_MDL_TABLE;
View created.

SQL> select * from DEMO_INT_VIEW;

     DUMMY    SHARING
---------- ----------
       111          1
       222          0

J’ai créé une ‘common data view’ en rajoutant une colonne ‘sharing’ pour montrer d’où viennent les lignes.

SQL> alter session set container=pdb1;
Session altered.

SQL> show con_name
CON_NAME
------------------------------
PDB1

SQL> show con_id
CON_ID
------------------------------
3

SQL> create or replace view DEMO_INT_VIEW common_data (dummy,sharing) as select dummy,case when dummy='222' then 0 else 1 end from DEMO_MDL_TABLE;
View created.

SQL> select * from DEMO_INT_VIEW;
     DUMMY    SHARING ORIGIN_CON_ID
---------- ---------- -------------
       999          1             3
       111          1             1

SQL> set autotrace on
SQL> select * from DEMO_INT_VIEW;

     DUMMY    SHARING ORIGIN_CON_ID
---------- ---------- -------------
       111          1             1
       999          1             3

Execution Plan
----------------------------------------------------------
Plan hash value: 3158883863

--------------------------------------------------------------------------------------------
|Id  | Operation               | Name            |Pstart|Pstop |   TQ  |IN-OUT| PQ Distrib |
--------------------------------------------------------------------------------------------
|  0 | SELECT STATEMENT        |                 |      |      |       |      |            |
|  1 |  PX COORDINATOR         |                 |      |      |       |      |            |
|  2 |   PX SEND QC (RANDOM)   | :TQ10000        |      |      | Q1,00 | P->S | QC (RAND)  |
|  3 |    PX PARTITION LIST ALL|                 |    1 |    2 | Q1,00 | PCWC |            |
|  4 |     FIXED TABLE FULL    | X$COMVW$e40eb386|      |      | Q1,00 | PCWP |            |
--------------------------------------------------------------------------------------------

On voit que les données de chaque conteneur est retourné comme une partition.

La version détaillée est en anglais sur mon blog à dbi services.
Ici un résumé, laissez un commentaire pour plus de détail en français est nécessaire.

Vous avez une requête qui prend trop de temps et vous voulez de l’aide pour analyser le plan d’exécution ? Alors, vous devez fournir le plan avec toute les infos pertinentes, et correctement formatées. Pas de plan sans la partie prédicat. Pas d’estimation de cardinalité sans les valeurs réelles. Pas de copie d’écran: soit un plan venant de dbms_xplan.display_cursor, soit, si vous avez Tuning Pack, un plan SQL Monitor.

Sans Tuning Pack

Paramétrage de la session:

Puis l’exécution de la requête, en se mettant dans le bon schema et en assignant des valeurs aux bind variables:

Et enfin, la sortie du plan en ficher texte:

Avec Tuning Pack

Paramétrage de la session:

Puis l’exécution de la requête, avec le hint MONITOR:

Et enfin, la sortie du plan en ficher html:

La version détaillée est en anglais sur mon blog à dbi services.
Ici un résumé, laissez un commentaire ici pour plus de détail en français.

On peut voir les verrous posés avec V$LOCK mais certaines verrous ne durent pas longtemps.
Si on veut connaitre exactement les verrous posés par une commande SQL (pour vérifier si une opération est réellement online par exemple) on peut utiliser l’event 10704.

On l’active avec:

et le désactive avec

Sur le dump généré, je récupère les lignes qui m’intéressent avec un grep -E sur:

Il faut aussi avoir les object_id en hexadécimal:

Exemples:

On a l’acquisition d’un verrou (ici en mode 4 qui est Share):

La conversion du verrou vers un autre mode:

La libération du verrou:

C’est avec cet évent que j’étudie le comportement des verrous de version en version, par exemple ici

La version détaillée est en anglais sur mon blog à dbi services.
Ici un résumé, laissez un commentaire ici pour plus de détail en français.

Lorsqu’on génère une clé primaire à partir d’une sequence, le problème est que toutes les insertions concurrentes vont toucher au même bloc d’index. Puisque les valeurs venant de la sequence s’incrémentent elles vont toutes à la fin de l’index.

Il est souvent conseillé d’utiliser un index REVERSE pour disperser ces valeurs. Mais ce n’est pas bon non plus car elles seront trop dispersées. Les inserts vont toucher à tous les blocs de l’index et dès qu’il y aura un peu de volume ça ne logera plus en buffer cache.

L’autre conseil est alors de partitioner l’index par HASH. Effectivement, on distribue les inserts sur quelques blocs. Mais en RAC on va voir passer ces blocs d’un noeud à l’autre, et on aura à nouveau des contentions.

Ce qu’il faut, c’est distribuer les inserts non pas en fonction des valeurs générées, mais en fonction de la session. Le but est qu’une session touche au même bloc d’index pour ses inserts, mais qu’une autre session touche à un autre bloc, surtout si elle est sur un autre noeud du RAC. La solution est donc de préfixer le numéro qui vient de la sequence avec un ora_hash() ou un mod() du session_id. Et mettre devant le numéro d’instance si on est en RAC.
La clé sera un peu plus longue, mais c’est toujours mieux qu’un reverse index qui va faire grossir tout l’index. Les numéros ne seront plus consécutifs, mais de toute façon ça n’a jamais été le cas. Une sequence sert à fournir un nombre unique pour une clé générée, pas è numéroter dans l’ordre.

En 12c il y a une option de la sequence qui permet de faire le préfixage automatiquement en donnant simplement le nombre de partition. Mais ce n’est pas documenté… donc à ne pas utiliser. J’espère le voir sur une prochaine version.

La demo est ici.

La version détaillée est en anglais sur mon blog à dbi services.
Ici un résumé, laissez un commentaire ici pour plus de détail en français.

Il arrive parfois que l’instance soit bloquée et qu’il faille faire un shutdown abort puis redémarrer.
Mais si on ne fait rien, on ne pourra pas analyser la root cause du problème.

Pour avoir les infos sur la situation de blocage (hanganalyze) et les infos complètes du système à ce moment là (systemstate), afin de pouvoir analyser et/ou ouvrir un SR, il faut penser à générer les dumps correspondants:

Si la situation est telle qu’on n’arrive même pas à se connecter sysdba, il est possible d’essayer la connection -prelim et de s’attacher à une session existante (le process DIAG par exemple):

Si par contre on peut se connecter et faire des requêtes, la vue V$WAIT_CHAINS donne les infos sur les sessions bloquées.
Un exemple où une session a posé plusieurs verrous puis attend sur un dbms_lock.sleep (‘PL/SQL lock timer’), bloquant des session qui attendent de poser leur verrou (enq: TM – contention)

On voit toute la chaîne des session bloquées, avec la racine. Et même lorsque qu’il ne s’agit pas d’une session utilisateur active.

English version on dbi services blog

Avez-vous déjà vérifié si la FRA gère bien votre DELETION POLICY ? C’est important de ne pas supprimer de archived logs nécessaire même si on a besoin de place. Et c’est important aussi de ne pas se retrouver avec une FRA pleine. La vue v$recovery_area_usage montre le pourcentage de l’espace qui est récupérable, mais aucune vue ne donne la liste, ou au moins les dates des archivelogs correspondant.

J’ai eu besoin d’aller dans le détail pour analyser pourquoi les archived logs de la standby n’étaient pas supprimés. C’est un bug en 11.2 qui fait que même avec CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY une standby en MOUNT ne rafraîchit pas le flag des archived logs récupérables.
Tout le détail est ici.

Voici la requête (issue de la définition interne de la vue v$recovery_area_usage ) qui permet de voir lesquels sont récupérables en fonction du nombre de backups et du fait qu’ils ont été appliqués sur les standby:

column deleted format a7 
column reclaimable format a11 
set linesize 120 
select applied,deleted,backup_count 
 ,decode(rectype,11,'YES','NO') reclaimable,count(*) 
 ,to_char(min(completion_time),'dd-mon hh24:mi') first_time 
 ,to_char(max(completion_time),'dd-mon hh24:mi') last_time 
 ,min(sequence#) first_seq,max(sequence#) last_seq 
from v$archived_log left outer join sys.x$kccagf using(recid) 
where is_recovery_dest_file='YES' 
group by applied,deleted,backup_count,decode(rectype,11,'YES','NO') order by min(sequence#) 
/

Un exemple du résultat sur la Primaire, en CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY BACKED UP 1 TIMES TO DISK:

APPLIED   DELETED BACKUP_COUNT RECLAIMABLE COUNT(*) FIRST_TIME   LAST_TIME    FIRST_SEQ LAST_SEQ 
--------- ------- ------------ ----------- -------- ------------ ------------ --------- -------- 
NO        YES                1 NO               277 15-jan 17:56 19-jan 09:49      5936     6212 
NO        NO                 1 YES              339 19-jan 10:09 22-jan 21:07      6213     6516 
NO        NO                 0 NO                33 22-jan 21:27 23-jan 07:57      6517     6549

Les redo logs archivés avant le 19-jan 09:49 ont été supprimés. Ceux qui ont été backupés sont toujours là mais supprimables. Les autres doivent rester jusqu’à leur backup.

Et un exemple sur la Standby en CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY:

APPLIED   DELETED BACKUP_COUNT RECLAIMABLE COUNT(*) FIRST_TIME   LAST_TIME    FIRST_SEQ LAST_SEQ 
--------- ------- ------------ ----------- -------- ------------ ------------ --------- -------- 
YES       YES                0 NO               746 07-jan 13:27 17-jan 11:17      5320     6065 
YES       NO                 0 YES              477 17-jan 11:37 23-jan 05:37      6066     6542 
YES       NO                 0 NO                 8 23-jan 05:57 23-jan 08:14      6543     6550 
IN-MEMORY NO                 0 NO                 1 23-jan 08:15 23-jan 08:15      6551     6551

Normalement, seul le redo en cours d’application (je suis en SYNC) ne serait pas récupérable. A cause d’un bug le flag ‘récupérable’ n’a pas été mis à jour depuis le 23-jan 05:57, date où le job de backup refait un CONFIGURE ARCHIVELOG DELETION POLICY qui rafraîchit ce flag.

Voici les blocs qui stokent les données de OE.ORDERS:

RMAN> select file_id,block_id,blocks from dba_extents where owner='OE' and segment_name='ORDERS';
using target database control file instead of recovery catalog
   FILE_ID   BLOCK_ID     BLOCKS
---------- ---------- ----------
         2        968          8

8 blocs alloués à partir du bloc 968. Je vais corrompre le bloc 971 en lui mettant des données aléatoires avec la commande dd, et je vérivie avec dbv:

+ dd if=/dev/urandom count=1 bs=8k seek=971 of=/u/DEMO/DATA/DEMO100/example01.dbf conv=notrunc
1+0 records in
1+0 records out
8192 bytes (8.2 kB) copied, 0.00157981 s, 5.2 MB/s

+ dbv /u/DEMO/DATA/DEMO100/example01.dbf
DBVERIFY - Verification starting : FILE = /u/DEMO/DATA/DEMO100/example01.dbf
Page 971 is marked corrupt
Corrupt block relative dba: 0x028003cb (file 10, block 971)
Bad header found during dbv:
Data in bad block:
 type: 90 format: 3 rdba: 0xfd75bf2c
 last change scn: 0xd97e.9447efe5 seq: 0xc7 flg: 0x96
 spare1: 0x80 spare2: 0x4f spare3: 0x225f
 consistency value in tail: 0x767ce7f0
 check value in block header: 0xe831
 computed block checksum: 0x9a28

Le bloc est bien corrompu, d’où l’erreur suivante lors d’un select:

RMAN> alter system flush buffer_cache;
using target database control file instead of recovery catalog
Statement processed
RMAN> select /*+ FULL(ORDERS) */ count(*) from OE.ORDERS;
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of sql statement command at 11/17/2013 20:16:06
ORA-01578: ORACLE data block corrupted (file # 2, block # 971)
ORA-01110: data file 2: '/u/DEMO/DATA/DEMO100/example01.dbf'

On va d’abord tester Recovery Advisor:

RMAN> list failure;

RMAN> list failure;
using target database control file instead of recovery catalog
Database Role: PRIMARY

List of Database Failures
=========================

Failure ID Priority Status    Time Detected Summary
---------- -------- --------- ------------- -------
8098       HIGH     OPEN      17-NOV-13     Datafile 2: '/u/DEMO/DATA/DEMO100/example01.dbf' contains one or more corrupt blocks

RMAN> advise failure;

RMAN> advise failure;
Database Role: PRIMARY

List of Database Failures
=========================

Failure ID Priority Status    Time Detected Summary
---------- -------- --------- ------------- -------
8098       HIGH     OPEN      17-NOV-13     Datafile 2: '/u/DEMO/DATA/DEMO100/example01.dbf' contains one or more corrupt blocks

analyzing automatic repair options; this may take some time
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=378 device type=DISK
analyzing automatic repair options complete

Mandatory Manual Actions
========================
no manual actions available

Optional Manual Actions
=======================
no manual actions available

Automated Repair Options
========================
Option Repair Description
------ ------------------
1      Perform block media recovery of block 971 in file 2  
  Strategy: The repair includes complete media recovery with no data loss
  Repair script: /u/DEMO/diag/rdbms/demo100/DEMO100/hm/reco_3695178258.hm

mais Recovery Advisor ne propose que le restore/recover du datafile entier.

Je vérifie d’abord qu’il n’y a pas d’autres blocs corrompus:

RMAN> validate datafile 2;

RMAN> validate datafile 2;
Starting validate at 17-NOV-13
using channel ORA_DISK_1
channel ORA_DISK_1: starting validation of datafile
channel ORA_DISK_1: specifying datafile(s) for validation
input datafile file number=00002 name=/u/DEMO/DATA/DEMO100/example01.dbf
channel ORA_DISK_1: validation complete, elapsed time: 00:00:01
List of Datafiles
=================
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
2    FAILED 0              31954        45841           1913733   
  File Name: /u/DEMO/DATA/DEMO100/example01.dbf
  Block Type Blocks Failing Blocks Processed
  ---------- -------------- ----------------
  Data       0              4534            
  Index      0              1219            
  Other      1              8133            

validate found one or more corrupt blocks
See trace file /u/DEMO/diag/rdbms/demo100/DEMO100/trace/DEMO100_ora_14863.trc for details
Finished validate at 17-NOV-13

RMAN> select * from v$database_block_corruption;

RMAN> select * from v$database_block_corruption;
     FILE#     BLOCK#     BLOCKS CORRUPTION_CHANGE# CORRUPTIO     CON_ID
---------- ---------- ---------- ------------------ --------- ----------
         2        971          1                  0 CORRUPT            0

Un seul bloc, donc je préfère faire un BLOCKRECOVER:

RMAN> blockrecover datafile 2 block 971;

RMAN> blockrecover datafile 2 block 971;
Starting recover at 17-NOV-13
using channel ORA_DISK_1

channel ORA_DISK_1: restoring block(s)
channel ORA_DISK_1: specifying block(s) to restore from backup set
restoring blocks of datafile 00002
channel ORA_DISK_1: reading from backup piece /u/DEMO/backup/12op4mt1_1_1
channel ORA_DISK_1: piece handle=/u/DEMO/backup/12op4mt1_1_1 tag=TAG20131116T205457
channel ORA_DISK_1: restored block(s) from backup piece 1
channel ORA_DISK_1: block restore complete, elapsed time: 00:00:15

starting media recovery

archived log for thread 1 with sequence 2 is already on disk as file /u/DEMO/FRA/DEMO100/archivelog/2013_11_16/o1_mf_1_2_98hmq0s6_.arc
archived log for thread 1 with sequence 1 is already on disk as file /u/DEMO/FRA/DEMO100/archivelog/2013_11_16/o1_mf_1_1_98hmwbsf_.arc
archived log for thread 1 with sequence 2 is already on disk as file /u/DEMO/FRA/DEMO100/archivelog/2013_11_16/o1_mf_1_2_98hp41w7_.arc
archived log for thread 1 with sequence 3 is already on disk as file /u/DEMO/FRA/DEMO100/archivelog/2013_11_16/o1_mf_1_3_98hpgdt4_.arc
archived log for thread 1 with sequence 4 is already on disk as file /u/DEMO/FRA/DEMO100/archivelog/2013_11_16/o1_mf_1_4_98hpgd5z_.arc
archived log for thread 1 with sequence 5 is already on disk as file /u/DEMO/FRA/DEMO100/archivelog/2013_11_16/o1_mf_1_5_98hpgdh8_.arc
archived log for thread 1 with sequence 1 is already on disk as file /u/DEMO/FRA/DEMO100/archivelog/2013_11_16/o1_mf_1_1_98hr6zvl_.arc
archived log for thread 1 with sequence 2 is already on disk as file /u/DEMO/FRA/DEMO100/archivelog/2013_11_16/o1_mf_1_2_98hr701w_.arc
archived log for thread 1 with sequence 3 is already on disk as file /u/DEMO/FRA/DEMO100/archivelog/2013_11_16/o1_mf_1_3_98hr70cc_.arc
archived log for thread 1 with sequence 1 is already on disk as file /u/DEMO/FRA/DEMO100/archivelog/2013_11_16/o1_mf_1_1_98hrcjy5_.arc
archived log for thread 1 with sequence 2 is already on disk as file /u/DEMO/FRA/DEMO100/archivelog/2013_11_16/o1_mf_1_2_98hrck57_.arc
archived log for thread 1 with sequence 3 is already on disk as file /u/DEMO/FRA/DEMO100/archivelog/2013_11_16/o1_mf_1_3_98hrckdn_.arc
archived log for thread 1 with sequence 1 is already on disk as file /u/DEMO/FRA/DEMO100/archivelog/2013_11_16/o1_mf_1_1_98hrcrp5_.arc
archived log for thread 1 with sequence 2 is already on disk as file /u/DEMO/FRA/DEMO100/archivelog/2013_11_17/o1_mf_1_2_98kwmzy5_.arc
archived log for thread 1 with sequence 3 is already on disk as file /u/DEMO/FRA/DEMO100/archivelog/2013_11_17/o1_mf_1_3_98l3gos8_.arc
archived log for thread 1 with sequence 4 is already on disk as file /u/DEMO/FRA/DEMO100/archivelog/2013_11_17/o1_mf_1_4_98l3xxyc_.arc
archived log for thread 1 with sequence 5 is already on disk as file /u/DEMO/FRA/DEMO100/archivelog/2013_11_17/o1_mf_1_5_98l5hjrn_.arc
media recovery complete, elapsed time: 00:00:15
Finished recover at 17-NOV-13

C’est fait, on vérifie le datafile:

RMAN> validate datafile 2;

RMAN> validate datafile 2;
Starting validate at 17-NOV-13
using channel ORA_DISK_1
channel ORA_DISK_1: starting validation of datafile
channel ORA_DISK_1: specifying datafile(s) for validation
input datafile file number=00002 name=/u/DEMO/DATA/DEMO100/example01.dbf
channel ORA_DISK_1: validation complete, elapsed time: 00:00:01
List of Datafiles
=================
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
2    OK     0              31954        45841           1913733   
  File Name: /u/DEMO/DATA/DEMO100/example01.dbf
  Block Type Blocks Failing Blocks Processed
  ---------- -------------- ----------------
  Data       0              4535            
  Index      0              1219            
  Other      0              8132            

Finished validate at 17-NOV-13

Plus de corruption. On peut relancer la requête:

RMAN> select /*+ FULL(ORDERS) */ count(*) from OE.ORDERS;

RMAN> select /*+ FULL(ORDERS) */ count(*) from OE.ORDERS;
  COUNT(*)
----------
       105

La base est restée ouverte, le datafile est resté online.
C’est le dépannage le plus rapide, malheureusement il n’est pas proposé par Recovery Advisor.