Migration manuelle d’une instance Oracle 9.2 vers Oracle 10.2.x

Introduction

Cet article présente la migration manuelle d’une instance Oracle de la version 9.2.0.7 32bits vers la version 10.2.0.4 64bits. La plateforme est un environnement Unix Solaris 10, le composant Jserver n’est pas installé sur l’instance, la réplication et le RAC (Real Application Cluster) ne sont pas mis en œuvre. De même il n’y a pas de base de données en mode standby ou de tablespaces en mode Read Only ou Offline.

L’instance à migrer s’appelle DBAT1ORA et elle est normalisée. La distribution 9.2.0.7 32 bits est installée dans le répertoire /Software/oracle/app/product/9.2.0.7. Dans ce même répertoire un lien 9.2.0 pointe sur le répertoire 9.2.0.7 pour gérer le cas où plusieurs versions 9i sont nécessaires pour plusieurs instances sur la même machine, le lien 9.2.0 correspondant à la distribution 9i majoritairement utilisée par les instances.

oracle[DBAT1ORA] > cd /Software/oracle/app/product
oracle[DBAT1ORA] > ls -lrt


drwxr-xr-x  60 oracle   dba         1024 Apr  4  2007 9.2.0.7
lrwxrwxrwx   1 oracle   dba            8 Jun 22  2007 9.2.0 -> 9.2.0.7

(voir l’article Normalisation d’une instance Oracle en mode archivelog sous Solaris pour plus de détails sur la norme appliquée).

La distribution 10.2.0.4 64 bits est installée dans le répertoire /Software/oracle/app/product/10.2.0.4.

L’instance 9i DBAT1ORA est sauvegardée avant l’opération de migration.

Vérification des pré-requis OS (mémoire partagée et sémaphores)

Avant le début des opérations, les pré-requis Solaris sur la mémoire partagée et les sémaphores sont vérifiés.

Beaucoup de paramètres systèmes pour la mémoire partagée et les sémaphores ont désormais des valeurs par défaut qui ont été augmentées avec Solaris 10 ou bien sont devenus obsolètes. D’une façon générale, les valeurs par défaut des paramètres systèmes Solaris étant supérieures aux préconisations Oracle, seule la mémoire partagée maximale doit être généralement définie pour le compte oracle.

Le tableau ci-dessous récapitule les paramètres Solaris modifiés ou devenus obsolètes entre la version 9 et la version 10 de Solaris. Les valeurs par défaut pour Solaris 10 sont données pour comparaison avec les préconisations des valeurs minimales Oracle.

Solaris 9 `/etc/system`	Préco Oracle	Solaris 10 `/etc/project`	Valeur par défaut
`noexec_user_stack`	`1`	Obsolète
`semsys:seminfo_semmni`	`100`	`project.max-sem-ids`	`128`
`semsys:seminfo_semmns`	`1024`	Obsolète
`semsys:seminfo_semmsl`	`256`	`project.max-sem-nsems`	`512`
`semsys:seminfo_semvmx`	`32767`	Obsolète
`shmsys:shminfo_shmmax`	`4294967295`	`project.max-shm-memory`	`2 Gb`
`shmsys:shminfo_shmmin`	`1`	Obsolète
`shmsys:shminfo_shmmni`	`100`	`project.max-shm-ids`	`128`
`shmsys:shminfo_shmseg`	`10`	Obsolète

Le tableau montre clairement que seule la mémoire partagée doit être définie pour Oracle avec Solaris 10.

Si le compte oracle est associé au projet user.oracle avec le nouveau contrôleur de ressources Solaris 10, une mémoire partagée maximale de 3 Gb (max-sh-memory, max value of shared memory segment) est définie pour le projet user.oracle avec la commande projmod :

shell> projmod -sK "project.max-shm-memory=(priv,3G,deny)" user.oracle

Elle peut être également définie avec le binaire prctl

shell> prctl -n project.max-shm-memory -v 3gb -r -i project user.oracle

Le fichier /etc/project contient les entrées ci-dessous :

/etc/project

system:0::::
user.root:1::::
noproject:2::::
default:3::::
group.staff:10::::
user.oracle:100::oracle::project.max-shm-memory=(priv,8589934592,deny)

Pour tous les autres paramètres systèmes (max-sem-ids, etc.), juste vérifier que les valeurs par défaut de la machine Solaris 10 sont supérieures aux préconisations Oracle avec la commande prctl pour le projet user.oracle.

Exemple pour le paramètre max-sem-ids recommandé à 100 par oracle

shell> prctl -n project.max-sem-ids -i project user.oracle

project: 100: user.oracle
NAME    PRIVILEGE       VALUE    FLAG   ACTION                       RECIPIENT
project.max-sem-ids
        privileged        128       -   deny                                 -
        system          16.8M     max   deny                                 -

Si ce n’est pas le cas, la valeur est modifiée également pour le projet user.oracle avec le binaire prctl.

Exemple :

prctl -n project.max-sem-ids -v 100 -r -i project user.oracle

L’outil d’information pre-migration (utlu102i.sql)

Contrairement aux migrations d’Oracle 8i vers 9i où les vérifications pré-migration étaient consignées dans les documentations de migration vers Oracle 9i, avec Oracle 10g un script de pré-analyse de migration est fourni.

Ce script de pré-migration fournit tous les éléments nécessaires : paramètres devenus obsolètes avec Oracle 10g, valeurs minimales de certains paramètres d’initialisation de l’instance Oracle à augmenter, tailles minimales des tablespaces systèmes à créer ou augmenter.

Dans le cas d’Oracle 10g, un nouveau tablespace système SYSAUX fait son apparition, le script utlu102i.sql va donner la taille minimale de ce tablespace système à créer.

Exécution du script utlu102i.sql

Le script d’analyse utlu102i.sql est disponible dans la distribution 10g dans le répertoire $ORACLE_HOME/rdbms/admin. Dans ce cas pratique, le répertoire est /Software/oracle/app/product/10.2.0.4/rdbms/admin/

Pour lancer la pré-analyse copier ce fichier utlu102i.sql dans un répertoire (/tmp) par exemple et exécuter ce dernier dans une sessions SQL*Plus en environnement Oracle 9i :

oracle[DBAT1ORA]> cd /tmp
oracle[DBAT1ORA]> cp /Software/oracle/app/product/10.2.0.4/rdbms/admin/utlu102i.sql .
oracle[DBAT1ORA]> sqlplus "/ as sysdba"

spool pre_upgrade.log;
@utlu102i.sql;
spool off;
exit

Résultat du script utlu102i.sql et opérations pre-migration

Voici le résultat du script utlu102i.sql en sortie pour l’instance DBAT1ORA 9i à migrer ;

/tmp/pre_upgrade.log

Oracle Database 10.2 Upgrade Information Utility    08-12-2009 13:23:57
 .
**********************************************************************
Database:
**********************************************************************
--> name:       SOPT9
--> version:    9.2.0.7.0
--> compatible: 9.2.0
--> blocksize:  8192
 .
**********************************************************************
Logfiles: [make adjustments in the current environment]
**********************************************************************
**********************************************************************
--> The existing log files are adequate. No changes are required.
 .
**********************************************************************
Tablespaces: [make adjustments in the current environment]
**********************************************************************
WARNING: --> SYSTEM tablespace is not large enough for the upgrade.
 .... currently allocated size: 200 MB
 .... minimum required size: 240 MB
 .... increase current size by: 40 MB
 .... tablespace is NOT AUTOEXTEND ENABLED.
--> TEMP tablespace is adequate for the upgrade.
 .... minimum required size: 58 MB
--> UNDO tablespace is adequate for the upgrade.
 .... minimum required size: 22 MB
 .
**********************************************************************
Update Parameters: [Update Oracle Database 10.2 init.ora or spfile]
**********************************************************************
WARNING: --> "streams_pool_size" is not currently defined and needs a value of
at least 50331648
WARNING: --> "large_pool_size" needs to be increased to at least 8388608
WARNING: --> "session_max_open_files" needs to be increased to at least 20
 .
**********************************************************************
Renamed Parameters: [Update Oracle Database 10.2 init.ora or spfile]
**********************************************************************
-- No renamed parameters found. No changes are required.
 .
**********************************************************************
Obsolete/Deprecated Parameters: [Update Oracle Database 10.2 init.ora or spfile]
**********************************************************************
--> "optimizer_max_permutations"
--> "log_archive_start"
 .
 .
**********************************************************************
Components: [The following database components will be upgraded or installed]
**********************************************************************
--> Oracle Catalog Views         [upgrade]  VALID
--> Oracle Packages and Types    [upgrade]  VALID
--> Real Application Clusters    [upgrade]  INVALID
 .
**********************************************************************
Miscellaneous Warnings
**********************************************************************
WARNING: --> Deprecated CONNECT role granted to some user/roles.
 .... CONNECT role after upgrade has only CREATE SESSION privilege.
WARNING: --> Database contains stale optimizer statistics.
 .... Refer to the 10g Upgrade Guide for instructions to update
 .... statistics prior to upgrading the database.
 .... Component Schemas with stale statistics:
 ....   SYS
WARNING: --> Database contains INVALID objects prior to upgrade.
 .... USER RISK has 4 INVALID objects.
 .... USER SOP_TRT has 3 INVALID objects.
 .... USER SYS has 256 INVALID objects.
 .... USER SYSTEM has 49 INVALID objects.
 .
**********************************************************************
SYSAUX Tablespace:
[Create tablespace in the Oracle Database 10.2 environment]
**********************************************************************
--> New "SYSAUX" tablespace
 .... minimum required size for database upgrade: 500 MB
 .

PL/SQL procedure successfully completed.

Section Database

Cette section affiche les informations globales sur la base Oracle 9i (nom de la base de données, version et niveau de compatibilité). Un avertissement est affiché si le paramètre d’initialisation COMPATIBLE concernant le niveau de compatibilité doit être ajusté avant la migration.

**********************************************************************
Database:
**********************************************************************
--> name:       SOPT9
--> version:    9.2.0.7.0
--> compatible: 9.2.0
--> blocksize:  8192

Section LogFiles

Le section LogFiles affiche la liste des fichiers de redo log pour lesquels la taille est inférieure à 4Mb. De nouveaux fichiers de redo log doivent être créés avec une taille supérieure à 4Mb (idéalement 10Mb) si des avertissements sont donnés dans cette section (cf article sur la Supression et création des groupes de fichiers de redo log si c’est le cas).

Cette opération de redimensionnement des fichiers de redo log doit être réalisée avant la migration.

**********************************************************************
Logfiles: [make adjustments in the current environment]
**********************************************************************
**********************************************************************
--> The existing log files are adequate. No changes are required.
 .

Section Tablespaces

La section Tablespace liste les tablespaces systèmes (SYSTEM, UNDO, TEMP etc...) éventuellement sous dimensionnés pour une migration vers Oracle 10g.

**********************************************************************
Tablespaces: [make adjustments in the current environment]
**********************************************************************
WARNING: --> SYSTEM tablespace is not large enough for the upgrade.
 .... currently allocated size: 200 MB
 .... minimum required size: 240 MB
 .... increase current size by: 40 MB
 .... tablespace is NOT AUTOEXTEND ENABLED.
--> TEMP tablespace is adequate for the upgrade.
 .... minimum required size: 58 MB
--> UNDO tablespace is adequate for the upgrade.
 .... minimum required size: 22 MB

Dans le contexte de cette migration, le tablespace SYSTEM doit être étendu à 240 Mb (taille actuelle : 200 Mb)

Cette opération de redimensionnement des tablespaces systèmes doit être réalisée avant la migration.

Le tablespace SYSTEM étant en mode AUTOEXTEND OFF, ce dernier est étendu manuellement avec la commande ALTER DATABASE DATAFILE RESIZE après avoir interrogé la vue dba_data_files et en s’assurant que l’espace disque nécessaire est suffisant

select file_name, tablespace_name, bytes
from dba_data_files 
where tablespace_name='SYSTEM';
FILE_NAME                               TABLESPACE_NAME   BYTES
--------------------------------------  ----------------- ----------
/dba/oracle/DBAT1ORA/SYSTEM_01.dbf      SYSTEM            104857600
/dba/oracle/DBAT1ORA/SYSTEM_02.dbf      SYSTEM            104857600
ALTER DATABASE DATAFILE '/dba/oracle/DBAT1ORA/SYSTEM_01.dbf' resize 150M;
Database altered.

Tous les autres tablespaces systèmes sont correctement dimensionnés (TEMP, UNDO).

Section Update / Renamed / Obsolete or Deprecated Parameters

Les sections "Update Parameters", "Renamed Parameters" et "Obsolete/Deprecated Parameters" listent les paramètres d’initialisation de l’instance Oracle qui doivent être respectivement ajustés, renommés ou supprimés juste avant la migration vers la version 10g.

**********************************************************************
Update Parameters: [Update Oracle Database 10.2 init.ora or spfile]
**********************************************************************
WARNING: --> "streams_pool_size" is not currently defined and needs a value of
at least 50331648
WARNING: --> "large_pool_size" needs to be increased to at least 8388608
WARNING: --> "session_max_open_files" needs to be increased to at least 20
 .
**********************************************************************
Renamed Parameters: [Update Oracle Database 10.2 init.ora or spfile]
**********************************************************************
-- No renamed parameters found. No changes are required.
 .
**********************************************************************
Obsolete/Deprecated Parameters: [Update Oracle Database 10.2 init.ora or spfile]
**********************************************************************
--> "optimizer_max_permutations"
--> "log_archive_start"

Cette opération d’ajustement des paramètres d’initialisation doit être réalisée dans le fichier d’initialisation juste avant la migration 10g.

Section Components (statut INVALID pour RAC)

La section Components indique les composants bases de données (Catalog, Data Mining, OLAP, RAC…) ainsi que leur statut 9i qui vont être migrés ou installés

**********************************************************************
Components: [The following database components will be upgraded or installed]
**********************************************************************
--> Oracle Catalog Views         [upgrade]  VALID
--> Oracle Packages and Types    [upgrade]  VALID
--> Real Application Clusters    [upgrade]  INVALID
 .

Dans ce cas précis, l’outil de pré-migration indique que le composant Real Application Clusters (RAC) est présent avec un statut invalide et sera migré [upgrade].

RAC n’a jamais été installé sur cette instance et cette erreur est décrite dans la note Metalink 312071.1 du 8 mai 2009, elle concerne toutes les plateformes. Pour vérifier que l’option RAC n’est effectivement pas installée dans l’instance, interroger la vue V$OPTION :

select value from v$option where parameter = 'Real Application Clusters';

VALUE
----------------------------------------------------------------
FALSE

Cette erreur provient de la migration précédente de la version 8.1.7 (ou 9.0.1) vers la version 9.2.0.1.

Les versions 8.1.7 et 9.0.1 n’utilisaient pas de registre pour les composants. Pour RAC, durant la migration vers la version 9.2, une entrée dans DBA_REGISTRY pour Real Application Clusters est créée si la vue V$PING existe lors de la migration. Pour éliminer cette fausse erreur, une solution consiste à "downgrader" vers la version 8.1.7, à supprimer la vue V$PING et migrer à nouveau vers la version 9i : cette solution est inenvisageable. Il n’existe pas d’autre méthode supportée.

Pour éviter tout malentendu, le statut peut être modifié d’INVALID à REMOVED avec Oracle 10g et 11g grâce à la procédure removed du package dbms_registry. Cette opération sera réalisée post-migration.

Section Miscellaneous Warnings

La section Miscellaneous Warnings donne des éléments divers supplémentaires comme les objets au statut invalide pour les comptes systèmes (SYS, SYSTEM…) et les comptes utilisateurs, les schémas qui présentent des statistiques trop vieilles (stale statistics), etc.

**********************************************************************
Miscellaneous Warnings
**********************************************************************
WARNING: --> Deprecated CONNECT role granted to some user/roles.
 .... CONNECT role after upgrade has only CREATE SESSION privilege.
WARNING: --> Database contains stale optimizer statistics.
 .... Refer to the 10g Upgrade Guide for instructions to update
 .... statistics prior to upgrading the database.
 .... Component Schemas with stale statistics:
 ....   SYS
WARNING: --> Database contains INVALID objects prior to upgrade.
 .... USER RISK has 3 INVALID objects.
 .

Lorsque l’utilitaire de pré-migration affiche un avertissement sur l’un des problèmes suivants, une analyse poussée doit être réalisée avant de migrer vers la version 10g :

Rôle CONNECT obsolète (deprecated CONNECT Role)
Liens de bases de données avec mots de passe (database links with passwords)
TIMESTAMP avec le type de données TIMEZONE (TIMEZONE with TIMEZONE datatype)
Jeu de caractères national 8.1.7 (Release 8.1.7 National Character Set)
Statistiques de l’optimiseur (Optimizer Statistics)

Dans le cas pratique ici, des avertissements sont donnés sur le rôle CONNECT qui ne conserve que le privilège CREATE SESSION avec la version 10g et des statistiques trop vieilles pour le compte système SYS.

Les objets invalides pour SYS et SYSTEM ont été corrigés mais ces corrections ne font pas l’objet de cet article. Elles sont essentiellement liées au catalogue AQ et Réplication créées avec le mauvais compte en version 9i, ainsi que des vues résiduelles d’OEM. Les objets invalides utilisateur sont des erreurs purement applicatives.

Rôle CONNECT

Après migration vers Oracle 10g, le rôle CONNECT aura uniquement le privilège CREATE SESSION, tous les autres privilèges donnés au rôle CONNECT dans les versions précédentes seront révoqués durant la migration. Pour identifier les utilisateurs et rôles associés au rôle CONNECT, le résultat de cette requête doit être conservée :

SELECT grantee FROM dba_role_privs
     WHERE granted_role = 'CONNECT' and
                     grantee NOT IN (
                                'SYS', 'OUTLN', 'SYSTEM', 'CTXSYS', 'DBSNMP', 
                                'LOGSTDBY_ADMINISTRATOR', 'ORDSYS',  
                                'ORDPLUGINS',  'OEM_MONITOR', 'WKSYS', 'WKPROXY', 
                                'WK_TEST', 'WKUSER', 'MDSYS', 'LBACSYS', 'DMSYS',
                                'WMSYS',  'OLAPDBA', 'OLAPSVR', 'OLAP_USER',  
                                  'OLAPSYS', 'EXFSYS', 'SYSMAN', 'MDDATA',
                                 'SI_INFORMTN_SCHEMA', 'XDB', 'ODM');

GRANTEE
------------------------------
RISK
SOP_EP
SOP_IS

Les privilèges accordés au rôle CONNECT sont ensuite sauvegardés en interrogeant la vue role_sys_privs afin de pouvoir réattribuer les privilèges nécessaires aux utilisateurs qui disposaient de ces privilèges dans le rôle CONNECT

select role, privilege, admin_option from role_sys_privs where role='CONNECT';

ROLE                           PRIVILEGE                                ADM
------------------------------ ---------------------------------------- ---
CONNECT                        CREATE VIEW                              NO
CONNECT                        CREATE TABLE                             NO
CONNECT                        ALTER SESSION                            NO
CONNECT                        CREATE CLUSTER                           NO
CONNECT                        CREATE SESSION                           NO
CONNECT                        CREATE SYNONYM                           NO
CONNECT                        CREATE SEQUENCE                          NO
CONNECT                        CREATE DATABASE LINK                     NO

Si des utilisateurs ou rôles ont besoin de privilèges autres que le privilège CREATE SESSION, les privilèges doivent être donnés avant la migration.

Statistiques trop vieilles pour le compte SYS (stale statistics)

Lors de la migration vers Oracle 10g, les statistiques sont collectées pour les tables du dictionnaire qui ont des statistiques manquantes. La collection des statistiques peut demander du temps lors de la migration si les tables du dictionnaire sont volumineuses.

Pour diminuer l’indisponibilité durant la migration à cause de la collecte des statistiques, il est recommandé de collecter les statistiques pour les comptes systèmes avant la migration de la base de données actuelle avec le script donné en annexe pour les versions 9.0.1 ou 9.2.0.

Après mise à jour des statistiques, cet avertissement n’est plus donné par l’utilitaire utlu102i.sql.

La mise à jour des statistiques pour les comptes systèmes est réalisée si possible avant la migration.

Section SYSAUX Tablespace

Le tablespace SYSAUX est un nouveau tablespace système avec Oracle 10g. Cette section donne les informations nécessaires pour sa création (taille minimale, etc.)

--> New "SYSAUX" tablespace
 .... minimum required size for database upgrade: 500 MB
 .

Le tablespace SYSAUX doit être créé après le démarrage en mode UPGRADE de l’instance avec la version 10g et JUSTE avant que les scripts de migration ne soient invoqués.

Migration manuelle

Avant la migration effective, l’instance est sauvegardée.

Préparation de l’environnement 10g pour les fichiers d’initialisation (init) et de configuration (listener.ora et tnsnames.ora)

Par défaut, Oracle cherche le fichier d’initialisation init<Instance>.ora de l’instance dans le répetoire $ORACLE_HOME/dbs. Dans la norme adoptée, un lien initDBAT1ORA.ora est donc créé dans le répertoire /Software/oracle/app/product/10.2.0.4/dbs, lien qui pointe vers /Software/oracle/Instances/pfile/initDBAT1ORA.ora.

shell> cd /Software/oracle/app/product/10.2.0.4/dbs
shell> ln -fs /Software/oracle/Instances/DBAT1ORA/pfile/initDBAT1ORA.ora initDBAT1ORA.ora

De même, par défaut Oracle cherche les fichiers listener.ora et tnsnames.ora dans le répertoire $ORACLE_HOME/network/admin. Dans la norme adoptée, un lien listener.ora et un lien tnsnames.ora sont créés dans le répertoire /Software/oracle/app/product/10.2.0.4/network/admin, liens qui pointent respectivement vers $TNS_ADMIN/listener.ora et $TNS_ADMIN/tnsnames.ora, $TNS_ADMIN étant le répertoire /Software/oracle/Network.

shell> cd /Software/oracle/app/product/10.2.0.4/network/admin
shell> ln -fs /Software/oracle/Network/listener.ora listener.ora
shell> ln -fs /Software/oracle/Network/tnsnames.ora tnsnames.ora

La version 10.2.0.4 étant la future version majoritaire 10.2.0.x des instances, un lien 10.2.0 pointant vers le répertoire 10.2.0.4 est créé dans le répertoire /Software/oracle/app/product :

shell> cd /Software/oracle/app/product
shell> ln -fs 10.2.0.4 10.2.0

Arrêt de l’instance 9i DBAT1ORA

L’instance Oracle 9i DBAT1ORA est arrêtée avec SQL*Plus avec la commande shutdown immediate.

oracle[DBAT1ORA]> sqlplus "/ as sysdba"

shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.

Le listener LISTENER_DBAT1ORA de l’instance 9i DBAT1ORA est également arrêté avec le binaire lsnrctl.

oracle[DBAT1ORA]> lsnrctl

lsnrctl> stop LISTENER_DBAT1ORA;
Connecting to (ADDRESS=(PROTOCOL=TCP)(Host=SRVUNXFR19)(Port=1525))
The command completed successfully

Modification de l’environnement DBAT1ORA ($DBA/etc/DBAT1ORA.inst)

Le fichier d’environnement de l’instance DBAT1ORA ($DBA/etc/DBAT1ORA.inst) est alors modifié pour basculer sur la version 10.2.0. Une nouvelle variable $ORA_NLS10 spécifique 10g fait son apparition et doit pointer sur le répertoire $ORACLE_HOME10g/nls/data dans ce fichier d’environnement.

$DBA/etc/DBAT1ORA.inst

...
ORA_VERSION="10.2.0"
...
export ORA_NLS10=$ORACLE_HOME/nls/data
...

Une nouvelle session oracle en prenant l’environnement DBAT1ORA est alors lancée pour démarrer la migration en vérifiant que les 5 variables ci-dessous sont correctement initialisées :

$ORACLE_SID : DBAT1ORA
$ORACLE_HOME (ex : /Software/oracle/app/product/10.2.0)
$PATH (ex : /Software/oracle/app/product/10.2.0/bin…)
$ORA_NLS10 (ex : /Software/oracle/app/product/10.2.0/nls/data)
$LD_LIBRARY_PATH (ex : /Software/oracle/app/product/10.2.0/lib…)

Modification des paramètres d’initialisation de l’instance DBAT1ORA avant migration

Conformément aux préconisations de l’outil de pré-migration utlu102i.sql, les paramètres d’initialisation sont modifiés dans le fichier initDBAT1ORA.ora.

$CFG/initDBAT1ORA.ora

#log_archive_start = true      

large_pool_size = 8388608
streams_pool_size = 50331648
session_max_open_files = 20

Migration avec STARTUP UPGRADE, création du tablespace SYSAUX et lancement du script de migration catupgrd.sql

L’instance est alors démarrée en environnement 10g avec l’option UPGRADE de la commande STARTUP via SQL*Plus.

oracle[DBAT1ORA]> sqlplus "/ as sysdba"

STARTUP UPGRADE;

Comme il s’agit d’une version 9i et non 10.1, le tablespace système SYSAUX est créé à cette étape avec les recommandations de l’utilitaire de pré-migration (500 Mb) :

CREATE TABLESPACE SYSAUX datafile '/dba/oracle/DBAT1ORA/SYSAUX_01.dbf'
SIZE 500M REUSE
EXTENT MANAGEMENT LOCAL
SEGMENT SPACE MANAGEMENT AUTO
ONLINE;

Tablespace created.

Le script de migration catupgrd.sql peut alors être exécuté :

spool upgradeDBAT1ORA.log;
@?/rdbms/admin/catupgrd.sql;
spool off;

Consulter le fichier de log pour repérer toutes les erreurs.

Opérations post-migration

Script de vérification utlu102s.sql et dba_registry

Le script $ORACLE_HOME/admin/utlu102s.sql affiche les résultats de la migration afin de vérifier que la migration de toutes les options est valide :

@?/rdbms/admin/utlu102s.sql
Oracle Database 10.2 Upgrade Status Utility           08-18-2009 16:55:08
 .
Component                                Status         Version  HH:MM:SS
Oracle Database Server                  INVALID      10.2.0.4.0  00:29:59
Oracle Real Application Clusters        INVALID      10.2.0.4.0  00:00:03
 .
Total Upgrade Time: 00:31:35

PL/SQL procedure successfully completed.

Dans le contexte de cet article, l’option Oracle Real Application Clusters au statut INVALID n’est pas prise en compte pour la raison évoquée précédemment (bug de la migration 8i vers 9i).

En revanche la migration des composants bases de données (vues du catalogue, packages et types systèmes) est au statut INVALID. Pour plus de détails sur le(s) composant(s) invalide(s), interroger la vue dba_registry :

select comp_name, version, status from dba_registry
COMP_NAME                                 VERSION         STATUS
---------------------------------------   --------------  -----------
Oracle Database Catalog Views             10.2.0.4.0      VALID
Oracle Database Packages and Types        10.2.0.4.0      INVALID
Oracle Real Application Clusters          10.2.0.4.0      INVALID

Script de recompilation de tous les objets utlrp.sql

Dans le migration de DBAT1ORA, il existe donc au moins un ou plusieurs packages/types systèmes invalide(s). Toutefois, avant d’analyser les objets systèmes invalides, le script $ORACLE_HOME/rdbms/admin/utlrp.sql qui recompile globalement les objets systèmes/utilisateurs doit être exécuté. Il s’avère utile de faire plusieurs passes de ce script de recompilation jusqu’à obtention d’un nombre d’erreurs identiques.

@?/rdbms/admin/utlrp.sql

TIMESTAMP
--------------------------------------------------------------------------------
COMP_TIMESTAMP UTLRP_END  2009-08-18 17:09:25

PL/SQL procedure successfully completed.
 ...

OBJECTS WITH ERRORS
-------------------
                 21
 ...
ERRORS DURING RECOMPILATION
---------------------------
                          2

Détection des objets systèmes invalides (dba_objects)

La vue dba_objects permet de retrouver rapidement les objets invalides en cause afin d’apporter les corrections nécessaires.

select object_name, owner, status from dba_objects where status='INVALID' and owner in ('SYS','SYSTEM');

OBJECT_NAME          OBJECT_TYPE     OWNER
-------------------  --------------- ------------------------------
DBMS_SQLPA           PACKAGE BODY    SYS

Dans le contexte de la migration de DBAT1ORA, il s’agit du package body DBMS_SQLPA appartenant à SYS qui est au statut INVALID. Cette erreur est connue dans les migrations des versions 9i, 10gR1 et 10gR2 vers la version 10.2.0.4 et 11.1.0.6 ou 11.1.0.7 et l’erreur est décrite dans les notes Metalink 782735.1 et 605317.1.

drop table plan_table$;
drop table plan_table;

@?/rdbms/admin/catplan.sql
@?/rdbms/admin/dbmsxpln.sql
@?/rdbms/admin/prvtxpln.plb 
@?/rdbms/admin/prvtspao.plb

Après correction des erreurs, une nouvelle exécution du script utlrp.sql doit donner 0 erreur et un statut VALID dans la vue DBA_REGISTRY :

COMP_NAME                                 VERSION         STATUS
---------------------------------------   --------------  -----------
Oracle Database Catalog Views             10.2.0.4.0      VALID
Oracle Database Packages and Types        10.2.0.4.0      VALID
Oracle Real Application Clusters          10.2.0.4.0      INVALID

Mise au statut REMOVED de l’option Real Application Clusters

Comme évoqué dans les paragraphes précédents, le composant RAC est présent dans la vue dba_registry avec un statut INVALID alors que l’option n’est pas installée (bug de la migration 8i vers 9i). La seule solution actuelle est de passer le composant RAC au statut REMOVED avec la procédure removed du package dbms_registry.

exec dbms_registry.removed('RAC');

Redémarrage en mode normal de l’instance et configuration du listener

L’instance peut alors être redémarrée en mode normal.

shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
startup;
ORACLE instance started.

Le fichier listener.ora dans le répertoire $TNS_ADMIN est ensuite modifé pour prendre en compte l’environnement 10g pour l’instance DBAT1ORA et le listener démarré avec lsnrctl :

listener.ora

LISTENER_DBAT1ORA =
  (ADDRESS_LIST =
        (ADDRESS= (PROTOCOL= TCP)(Host= SRVUNXFR19)(Port= 1525))
        (ADDRESS= (PROTOCOL= IPC)(KEY=DBAT1ORA))
  )

SID_LIST_LISTENER_DBAT1ORA =
  (SID_LIST =
    (SID_DESC =
      (ORACLE_HOME = /Software/oracle/app/product/10.2.0)
      (SID_NAME = DBAT1ORA)
      (GLOBAL_DBNAME = DBAT1ORA)
    )
    )

LOG_DIRECTORY_LISTENER_DBAT1ORA=/Software/oracle/Instances/DBAT1ORA/bdump
LOG_FILE_LISTENER_DBAT1ORA=listener_DBAT1ORA.log

shell> lsnrctl

LSNRCTL> start LISTENER_DBAT1ORA
Starting /Software/oracle/app/product/10.2.0/bin/tnslsnr: please wait...

TNSLSNR for Solaris: Version 10.2.0.4.0 - Production
System parameter file is /Software/oracle/Network/listener.ora
Log messages written to /Software/oracle/Instances/DBAT1ORA/bdump/listener_dbat1ora.log
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=SRVUNXFR19)(PORT=1525)))
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=DBAT1ORA)))

Connecting to (ADDRESS=(PROTOCOL=TCP)(Host=SRVUNXFR19)(Port=1525))
STATUS of the LISTENER
------------------------
Alias                     LISTENER_DBAT1ORA
Version                   TNSLSNR for Solaris: Version 10.2.0.4.0 - Production
Start Date                18-AOÛT -2009 18:24:33
Uptime                    0 days 0 hr. 0 min. 0 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /Software/oracle/Network/listener.ora
Listener Log File         /Software/oracle/Instances/DBAT1ORA/bdump/listener_dbat1ora.log
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=SRVUNXFR19)(PORT=1525)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=DBAT1ORA)))
Services Summary...
Service "DBAT1ORA" has 1 instance(s).
  Instance "DBAT1ORA", status UNKNOWN, has 1 handler(s) for this service...
The command completed successfully

Annexe - Collecte des statistiques des tables systèmes


spool gdict

grant analyze any to sys;

exec dbms_stats.gather_schema_stats('WMSYS',options=>'GATHER', estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);
exec dbms_stats.gather_schema_stats('MDSYS',options=>'GATHER', estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);
exec dbms_stats.gather_schema_stats('CTXSYS',options=>'GATHER', estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);
exec dbms_stats.gather_schema_stats('XDB',options=>'GATHER', estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);
exec dbms_stats.gather_schema_stats('WKSYS',options=>'GATHER', estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);
exec dbms_stats.gather_schema_stats('LBACSYS',options=>'GATHER', estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);
exec dbms_stats.gather_schema_stats('OLAPSYS',options=>'GATHER', estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);
exec dbms_stats.gather_schema_stats('DMSYS',options=>'GATHER', estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);
exec dbms_stats.gather_schema_stats('ODM',options=>'GATHER', estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);
exec dbms_stats.gather_schema_stats('ORDSYS',options=>'GATHER', estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);
exec dbms_stats.gather_schema_stats('ORDPLUGINS',options=>'GATHER', estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);
exec dbms_stats.gather_schema_stats('SI_INFORMTN_SCHEMA',options=>'GATHER', estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);
exec dbms_stats.gather_schema_stats('OUTLN',options=>'GATHER', estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);
exec dbms_stats.gather_schema_stats('DBSNMP',options=>'GATHER', estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);
exec dbms_stats.gather_schema_stats('SYSTEM',options=>'GATHER', estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);
exec dbms_stats.gather_schema_stats('SYS',options=>'GATHER', estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);
spool off