Oracle 11g R2 et l'erreur ORA-48258 (AMS Corrupt page found, rebuild relation)

1- Introduction

La commande create database Oracle 11g est lancée manuellement avec SQL*Plus, puis les scripts catproc.sql et catalog.sql sont exécutés dans cette nouvelle base de données.

oracle@UBIX> sqlplus "/ as sysdba"

startup nomount pfile=/Software/oracle/Instances/UBIX/pfile/initUBIX.ora;

create database UBIX
    noarchivelog
    maxinstances 1
    maxlogfiles  32
    maxdatafiles  32
    maxlogmembers 4
    character set WE8PC850
    national character set AL16UTF16
    extent management local
    datafile
        '/ubix/oracle/UBIX/SYSTEM_01.dbf'    size   500M
    logfile
        group 1
        (
        '/ubix/oracle/UBIX/redo1_01.log',
        '/ubix/oracle/UBIX/redo1_02.log')   size 50M,
        group 2
        (
        '/ubix/oracle/UBIX/redo2_01.log',
        '/ubix/oracle/UBIX/redo2_02.log')   size 50M,
        group 3
        (
        '/ubix/oracle/UBIX/redo3_01.log',
        '/ubix/oracle/UBIX/redo3_02.log')   size 50M
        sysaux
        datafile '/ubix/oracle/UBIX/SYSAUX_01.dbf' size 500M
        undo tablespace UNDO
        datafile '/ubix/oracle/UBIX/UNDO_01.dbf' size 500M
        default temporary tablespace TEMP
        tempfile '/ubix/oracle/UBIX/TEMP_01.dbf' size 100M
        ;

oracle@UBIX> sqlplus "/ as sysdba"

@?/rdbms/admin/catalog.sql;
@?/rdbms/admin/catproc.sql;

Durant l'exécution de catproc.sql ou au redémarrage de l'instance, des erreurs ORA-48258 et ORA-00600 tombent avec des messsages de corruptions sur les pages AMS :

ORA-48258: AMS Corrupt Page Found - Rebuild Relation
ORA-00600: internal error code, arguments: [dbgripmg_2: infinite init action], [11], [ADR_CONTROL], [], [], [], [], [], [], [], [], []

Dans le cas d'un redémarrage, la base de données ne peut même pas être ouverte !

Instinctivement, la base de données est recréée en modifiant dans le fichier d'initialisation les paramètres de mémoire (memory_target etc...)... Rien n'y fait. La solution est bien plus simple : il suffit de regarder d'un peu plus près le contexte de la création de la base de données et de faire attention à quelques petits résidus éventuellement présents dans le répertoire défini par le paramètre Oracle diagnostic_dest.

2- Contexte de la création de la base de données

La base de données UBIX est créée sur une machine SunOS X86 64 bits pour y accueillir des tablespaces provenant d'une plateforme Sun SPARC 64 bits. Il s'agit d'une migration cross-plateforme d'une instance, les poids étant différents entre ces deux plateformes (little endian/big endian); pour plus d'informations sur les migrations cross plateformes avec les tablespaces transportables : Oracle 11g R2, migrations cross plateformes avec les tablespaces transportables »

Lors de la création de la base de données UBIX sur la machine cible SunOS Actinium, le paramètre d'initialisation Oracle diagnostic_dest (nouveauté 11g, Automatic Diagnostic Repository) est le même que celui de l'instance sur la machine source SPARC :

oracle@UBIX>  cat /Software/oracle/Instances/UBIX/pfile/initUBIX.ora | grep 'diagnostic_dest'

diagnostic_dest = "/Software/oracle/Instances/UBIX/bdump"

L'intégralité du répertoire diagnostic_dest est copié de la machine source vers la machine cible et ce détail a une importance capitale dans l'erreur ORA-48258 (AMS Corrupt Page Found - Rebuild Relation).

3- Le répertoire diagnostic_dest (ADR) et les méta-données

À partir de la version 11g, une refonte profonde a été apportée à propos de la localisation des répertoires des fichiers de log et de trace Oracle avec la nouveauté de l'ADR (Automatic Diagnostic Repository). Les paramètres d'initialisation background_dump_dest, core_dump_dest et user_dump_dest disparaissent avec la version 11g et sont remplacés par un paramètre unique : diagnostic_dest.

Le paramètre d'initialisation d'une instance Oracle diagnostic_dest définit la racine de l'arborescence de l'ADR (Automatic Diagnostic Repository) : $ADR_BASE.

Pour une instance Oracle, le paramètre diagnostic_dest génère la création automatique de l'arborescence ci-dessous : $ADR_BASE/diag/rdbms/<db_name>/<SID>

Le tableau ci-dessous donne les correspondances avec les anciens paramètres core_dump_dest, user_dump_dest et background_dump_dest :

Le répertoire $ADR_HOME/metadata est la cause des erreurs de corruption ORA-48258 rencontrées lors de la création de la base de données : ce répertoire contient des fichiers de meta données avec l'extension *.ams, fichiers qui sont créés pour leur majorité lors de la création de la base de données et si ils existent déjà, ils ne sont pas recréés.

oracle@UBIX> ls -ll /Software/oracle/Instances/UBIX/bdump/diag/rdbms/ubix/UBIX/metadata

...
-rw-r-----   1 oracle   dba        65536 Oct 18 12:38 PROBLEM.ams
-rw-r-----   1 oracle   dba        65536 Oct 18 12:38 INCCKEY.ams
-rw-r-----   1 oracle   dba        65536 Oct 18 12:38 INCIDENT_FILE.ams
 ...

Ces fichiers *.ams sont au format binaire et donc dépendants de la plateforme sur laquelle ils sont créés : les fichiers de meta données *.ams provenant d'une plateforme SPARC (big endian, poids fort), ils apparaissent en conséquence corrompus sur la plateforme SunOS X86 (little endian, poids faible).

Pour éradiquer cette erreur, supprimer tous les fichiers *.ams dans le répertoire $ADR_HOME/metadata qui proviendraient d'une plateforme avec un poids différent et relancer la création de la base de données.

Si la recréation de la base de données s'avère fastidieuse (tablespace utilisateurs déjà créés etc...), une autre astuce existe : redémarrer l'instance en modifiant le paramètre diagnostic_dest et en le définissant vers un nouveau répertoire

oracle@UBIX> cat /Software/oracle/Instances/UBIX/pfile/initUBIX.ora | grep 'diagnostic_dest'

diagnostic_dest = "/Software/oracle/Instances"

La modification du paramètre diagnostic_dest élimine l'erreur ORA-48258 car une nouvelle arborescence $ADR_BASE (/Software/oracle/Instances/diag/rdbms/ubix/UBIX) est intégralement recréée, y compris les fichiers de meta donneés *.ams : il suffit alors d'écraser les fichiers *.ams du répertoire metadata par ceux créés dans cette nouvelle arborescence.

Rebasculer ensuite l'instance vers l'arborescence originelle diagnostic_dest.

Annexe