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

Introduction

Cet article présente la migration manuelle d’une instance Oracle de la version 8.1.7.4 vers la version 9.2.0.6. La plateforme est un environnement Unix Solaris 2.8, 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.

Prérequis

Upgrade des colonnes utilisateur de type nchar (nchar, nvarchar2, nclob)

Avec Oracle 9i, les types de données NCHAR (NCHAR, NVARCHAR2 et NCLOB) sont désormais limités à UTF8 et AL16UTF16. En version 8, la compatibilité des jeux de caractère autres que UTF8 et AL16UTF16 avec les types de données NCHAR (comme par exemple JA16SJISFIXED) n’est plus supportée.

Si initialement le jeu de caractères est UTF8, il demeure en UTF8 après migration Oracle 9, dans tous les autres cas, le jeu de caractères est migrée vers le jeu AL16UTF16 pour ces colonnes NCHAR. Oracle recommande d’utiliser l’outil « character set scanner » sur les colonnes de types NCHAR avant migration afin d’identifier les caractères invalides potentiels pour la conversion.

Des actions spécifiques sont nécessaires au cours de la migration vers la version 9 pour les colonnes utilisateur nchar, nvarchar2 et nclob (étape décrite dans ce document). Les colonnes système de type nchar sont prises en charge par la migration.

Pour savoir si des colonnes de type NCHAR sont mises en œuvre dans l’instance :

select table_name, owner, data_type
from dba_tables
where owner not in ('SYS','SYSTEM')
and data_type in ('NCHAR', 'NVARCHAR2', 'NCLOB');

Dimensionnement du tablespace system

Avant d’opérer la migration, il faut s’assurer qu’il reste assez d’espace libre dans le tablespace SYSTEM. Le tableau ci-dessous récapitule l’espace nécessaire pour le tablespace SYSTEM en fonction de la version initiale de l’instance.

La vue dba_free_space donne l’espace libre dans le tablespace SYSTEM :

select sum(bytes/1024000) as "Free space (Mb)",
       tablespace_name
from dba_free_space
group by tablespace_name;

 Free space (Mb) tablespace_name
  --------------- -----------------------
             2.04 INDX
           19.592 RBS
            223.8 SYSTEM
             3.88 USERS

Dimensionnement des rollback segments pour l’upgrade

Un large segment d’annulation public (rollback segment) est nécessaire pour migrer les bases de données contenant un large nombre d’objets (packages, tables, etc.). Un segment d’annulation d’au moins 70 Mb est recommandé lorsque le nombre d’objets dans la base excède 5000.

Pour déterminer le nombre total d’objets dans une base de données :

select count(*) from dba_objects;

COUNT(*)
----------
2947

Lorsque ce nombre dépasse 5000. Il est préférable de créer un large segment d’annulation public (public rollback segment) pour la migration, pour créer ce dernier :

create public rollback segment rbs_upgrade tablespace rbs storage (maxextents unlimited);

alter rollback segment rbs_upgrade online;

Pour vérifier le statut ONLINE de ce nouveau segment d’annulation :

select segment_name, tablespace_name,status from dba_rollback_segs
where segment_name='RBS_UPGRADE';

SEGMENT_NAME TABLESPACE_NAME STATUS
------------ --------------- -------------
RBS_UPGRADE  RBS             ONLINE 

Au prochain redémarrage de l’instance à migrer, pour spécifier que ce segment d’annulation doit être en ligne, public et unique, modifier le fichier d’initialisation de l’instance init<INSTANCE_NAME>.ora pour ne mettre que le segment d’annulation rbs_upgrade dans le paramètre rollback_segments :

init<INSTANCE_NAME>.ora

# Fichier d’initialisation de l’instance
# rollback_segments=(RBS01,RBS02,RBS03,RBS04)
rollback_segments=(RBS_UPGRADE)

Migration manuelle

Sauvegarde à froid de l’instance 8.1.7

Avant la migration, une sauvegarde à froid de l’instance 8.1.7 doit être faite. Cette sauvegarde à froid consiste à sauvegarder tous les fichiers (fichiers de données, fichiers de redo log et fichiers de contrôle).

Pour récupérer tous les fichiers de données :

select name from v$datafile union select name from v$tempfile;

/cgcdb/oracle/OEMD1ORA/INDX_01.DBF
/cgcdb/oracle/OEMD1ORA/RBS_01.DBF
/cgcdb/oracle/OEMD1ORA/SYSTEM_01.DBF
/cgcdb/oracle/OEMD1ORA/TEMP_01.DBF
/cgcdb/oracle/OEMD1ORA/USERS_01.DBF
/cgcdb/oracle/OEMD1ORA/USERS_02.DBF

Pour récupérer tous les fichiers de redo log :

select member from v$logfile;

/cgcdb/oracle/OEMD1ORA/redo3_01.log
/cgcdb/oracle/OEMD1ORA/redo3_02.log
/cgcdb/oracle/OEMD1ORA/redo2_01.log
/cgcdb/oracle/OEMD1ORA/redo2_02.log
/cgcdb/oracle/OEMD1ORA/redo1_01.log
/cgcdb/oracle/OEMD1ORA/redo1_02.log

Pour récupérer tous les fichiers de contrôle :

select name from v$controlfile;

/cgcdb/oracle/OEMD1ORA/control01.ctl
/cgcdb/oracle/OEMD1ORA/control02.ctl
/cgcdb/oracle/OEMD1ORA/control03.ctl

Tous les fichiers listés par les 3 requêtes ci-dessus doivent être sauvegardés à l’issue de l’arrêt de l’instance.

shutdown immediate;

Le listener doit être également arrêté :

lsncrtl > stop LISTENER_<INSTANCE_NAME>

Modification de l’environnement

Modification des variables d’environnement

L’environnement de l’instance doit être migré vers l’arborescence Oracle 9.2 en positionnant les variables ci-dessous :

export ORACLE_HOME=/Software/oracle/app/product/9.2.0
export ORA_NLS_33 =$ORACLE_HOME/ocommon/nls/admin/data
LD_LIBRARY_PATH=$ORACLE_HOME/lib:$LD_LIBRARY_PATH
PATH=$ORACLE_HOME/bin:$PATH
export LD_LIBRARY_PATH, PATH

Modification des fichiers init, orapw, listener et tnsnames

Il faut prendre garde au répertoire Oracle 9.2 $ORACLE_HOME/dbs, ce dernier doit bien contenir le fichier d’initialisation de l’instance à migrer init<INSTANCE_NAME>.ora et éventuellement le fichier password orapw<INSTANCE_NAME>. Même si ce ne sont pas les fichiers physiques mais des liens qui sont implémentés dans le répertoire $ORACLE_HOME/dbs, il faut s’assurer de la validité des liens :

cd /Software/oracle/app/product/9.2.0/dbs

initOEMD1ORA.ora -> /Software/oracle/Instances/OEMD1ORA/pfile/initOEMD1ORA.ora
orapwOEMD1ORA -> /Software/oracle/Instances/OEMD1ORA/mdp/orapwOEMD1ORA

Il en est de même des fichiers tnsnames.ora et listener.ora dans la repertoire Oracle 9.2 $ORACLE_HOME/network/admin

cd /Software/oracle/app/product/9.2.0/network/admin

listener.ora -> /Software/oracle/Network/admin/listener.ora
tnsnames.ora -> /Software/oracle/Network/admin/tnsnames.ora

Le fichier listener.ora doit être également revu pour s’assurer de la validité des paramètres $ORACLE_HOME indiqués pour les listeners et basculer de la version 8.1.7.4 à la version 9.2 pour l’instance Oracle à migrer.

Modification du fichier d’initialisation

Ci-dessous sont listés les paramètres d’initialisation devenus obsolètes après la version 8.1.7.4 :

Si l’un des paramètres listés ci-dessus est mis en œuvre dans le fichier d’initialisation de l’instance, une attention toute particulière doit être portée sur la suppression du paramètre.

Si le paramètre REMOTE_LOGIN_PASSWORDFILE n’est pas positionné à NONE dans le fichier d’initialisation, dans ce cas ce paramètre doit être à NONE le temps de la migration

# Fichier d’initialisation de l’instance
# remote_login_passwordfile=exclusive
remote_login_passwordfile=none

Si le paramètre NLS_LENGTH_SEMANTICS est positionné à char dans le fichier d’initialisation, ce paramètre doit être à byte le temps de la migration

# Fichier d’initialisation de l’instance
# nls_length_semantics=char
nls_length_semantics=byte

Il faut par ailleurs s’assurer des valeurs minimales requises pour les paramètres d’initialisation ci-dessous :

Démarrage de l’instance en mode restrict et migration

Se positionner dans le répertoire $ORACLE_HOME/rdbms/admin et démarrer l’instance en mode restrict :

startup migrate;

À ce stade, des erreurs peuvent apparaître sur des paramètres d’initialisation obsolètes. Il est alors préférable d’étudier ces paramètres et de redémarrer l’instance en mode restrict après suppression de ces paramètres obsolètes.

Préparer ensuite un fichier de log de l’upgrade avec la commande SQL*Plus spool :

spool upgradev9_instance.log

Et exécuter ensuite le script sql approprié contenu dans le répertoire $ORACLE_HOME/rdbms/admin en fonction de la version d’origine de l’instance :

Dans le contexte de notre cas pratique :

@u0801070.sql

Le script en question créé et altère des tables du dictionnaire puis exécuter les fichiers catalog.sql et catproc.sql de la version 9.2.

À l’issue de l’exécution du script d’upgrade général, exécuter également le script cmpdbmig.sql pour upgrader les composants annexes listés dans le tableau qui suit :

@cmpdbmig.sql

Pour déterminer les composants qui ont été migrés : interroger la vue dba_registry :

SELECT comp_name, version, status
FROM dba_registry;

COMP_NAME                     VERSION         STATUS
----------------------------- --------------- -----------
Oracle9i Catalog Views        9.2.0.6.0       VALID
Oracle9i Packages and Types   9.2.0.6.0       VALID
JServer JAVA Virtual Machine  9.2.0.6.0       VALID
Oracle9i Java Packages        9.2.0.6.0       VALID
Oracle XDK for Java           9.2.0.2.0       UPGRADED
Oracle Text                   9.0.1           LOADED
Oracle Workspace Manager      9.2.0.6.0       VALID
Oracle interMedia             9.0.0.0.0       LOADED
Oracle Spatial                9.0.0.0.0 BETA  LOADED
Ultrasearch                   9.0.1.0.0       LOADED
OLAP Catalog                  9.2.0.6.0       VALID
OLAP Analytic Workspace       9.2.0.1.0       LOADED

Les composants Oracle Text, Oracle Spatial, Oracle Visual Information Retrieval, Oracle Ultra Search et Oracle InterMedia nécessitent des étapes supplémentaires (se reporter à la documentation correspondante).

Exécuter ensuite le script utlrp.sql pour recompiler les objets et le code Java

@utlrp.sql

À l’issue de la recompilation, analyser les objets qui sont toujours invalides afin de corriger les erreurs et vérifier si ces erreurs sont liées à la migration Oracle v9 (utilisation de mots clés, etc.), pour retrouver les objets invalide :

select distinct(object_name) from dba_objects where status='INVALID';

Tâches complémentaires pour une instance Oracle 8.1.7.4 (colonnes NCHAR)

Lorsque la base de données contient des tables utilisateur avec des colonnes de type NCHAR, les colonnes NCHAR doivent être migrées pour qu’elles puissent être utilisées par Oracle 9.

Le script utlnchar.sql est dédié à la migration des colonnes NCHAR :

@utlnchar.sql;

Redémarrage de l’instance Oracle en version 9

Les opérations sont terminées, l’instance Oracle migrée en version 9 peut être redémarrée en mode normal.

spool off;
shutdown immediate;

Il ne faut pas oublier de remettre en mode public et en ligne les segments d’annulation classiques de l’instance dans le fichier d’initialisation de l’instance avant le démarrage normal si le segment d’annulation rbs_upgrade a été créé:

# Fichier d’initialisation de l’instance
rollback_segments=(RBS01,RBS02,RBS03,RBS04)
# rollback_segments=(RBS_UPGRADE)

Les paramètres REMOTE_LOGIN_PASSWORDFILE et NLS_LENGTH_SEMANTICS sont remis à leur ancienne valeur si ces paramètres ont été modifiés pour les besoins de la migration :

# Fichier d’initialisation de l’instance
remote_login_passwordfile=exclusive
# remote_login_passwordfile=none
nls_length_semantics=char
# nls_length_semantics=byte /* pour migration v9 */

startup;

Il reste ensuite à supprimer le segment d’annulation rbs_upgrade :

drop rollback segment rbs_upgrade;