Cet article présente la migration manuelle d'une instance Oracle de la version 10g R2 10.2.0.4 64 bits vers la version 11g R2 11.2.0.1 64 bits. La plateforme est un environnement Unix Sun Solaris 10 SPARC, 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. La fonctionnalité FlashBack introduite en 10g n'est pas utilisée également.
L'instance à migrer s'appelle UBXU1ORA et elle est normalisée. La distribution 10.2.0.4 64 bits est installée dans le répertoire /Software/oracle/app/product/10.2.0.4. Dans ce même répertoire un lien 10.2.0 pointe sur le répertoire 10.2.0.4 pour gérer le cas où plusieurs versions 10g sont nécessaires pour plusieurs instances sur la même machine, le lien 10.2.0 correspondant à la distribution 10g majoritairement utilisée par les instances.
oracle@UBXU1ORA > cd /Software/oracle/app/product oracle@UBXU1ORA > ls -lrt drwxr-xr-x 61 oracle dba 66 Aug 15 2009 10.2.0.4 lrwxrwxrwx 1 oracle dba 8 Feb 9 2010 10.2.0 -> 10.2.0.4
(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 11.2.0.1 64 bits est installée dans le répertoire /Software/oracle/app/product/11.2.0.1.
L'instance 10g UBXU1ORA est sauvegardée avant l'opération de migration.
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éconisation Oracle | Solaris 10 /etc/project | Valeur par défaut Solaris 10 | |
|---|---|---|---|---|
| noexec_user_stack | 1 | x Obsolète | x | |
| semsys:seminfo_semmni | 100 | project.max-sem-ids | 128 | |
| semsys:seminfo_semmns | 1024 | x Obsolète | x | |
| semsys:seminfo_semmsl | 256 | project.max-sem-nsems | 512 | |
| semsys:seminfo_semvmx | 32767 | x Obsolète | x | |
| shmsys:shminfo_shmmax | 4294967295 | project.max-shm-memory | 2 Gb | |
| shmsys:shminfo_shmmin | 1 | x Obsolète | x | |
| shmsys:shminfo_shmmni | 100 | project.max-shm-ids | 128 | |
| shmsys:shminfo_shmseg | 10 | x Obsolète | x |
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 donne alors les entrées ci-dessous :
shell> cat /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...), il suffit juste de 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
Depuis 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 11g, valeurs minimales de certains paramètres d'initialisation de l'instance Oracle à augmenter, tailles minimales des tablespaces systèmes à créer ou augmenter.
Le script d'analyse utlu112i.sql est disponible dans la distribution 11g dans le répertoire $ORACLE_HOME/rdbms/admin. Dans ce cas pratique, le répertoire est /Software/oracle/app/product/11.2.0.1/rdbms/admin
Pour lancer la pré-analyse copier ce fichier utlu112i.sql dans un répertoire (/tmp) par exemple et exécuter ce dernier dans une session SQL*Plus en environnement Oracle 10g :
oracle@UBXU1ORA> cd /tmp oracle@UBXU1ORA> cp /Software/oracle/app/product/11.2.0.1/rdbms/admin/utlu112i.sql .
oracle@UBXU1ORA> sqlplus "/ as sysdba" SQL> spool preupgrade_11g.log SQL> @utlu112i.sql SQL> spool off SQL> exit
Voici le résultat du script utlu112i.sql en sortie pour l'instance UBXU1ORA 10g à migrer :
cat /tmp/preupgrade_11g.log
Oracle Database 11.2 Pre-Upgrade Information Tool 10-14-2010 12:14:12 . ********************************************************************** Database: ********************************************************************** --> name: UBXU1 --> version: 10.2.0.4.0 --> compatible: 9.2.0 --> blocksize: 8192 --> platform: Solaris[tm] OE (64-bit) --> timezone file: V4 . ********************************************************************** Tablespaces: [make adjustments in the current environment] ********************************************************************** WARNING: --> SYSTEM tablespace is not large enough for the upgrade. .... currently allocated size: 450 MB .... minimum required size: 464 MB .... increase current size by: 14 MB .... tablespace is NOT AUTOEXTEND ENABLED. --> TEMPO tablespace is adequate for the upgrade. .... minimum required size: 61 MB --> SYSAUX tablespace is adequate for the upgrade. .... minimum required size: 411 MB --> UNDO tablespace is adequate for the upgrade. .... minimum required size: 122 MB . ********************************************************************** Flashback: OFF ********************************************************************** ********************************************************************** Update Parameters: [Update Oracle Database 11.2 init.ora or spfile] ********************************************************************** WARNING: --> "compatible" must be set to at least 10.1.0 WARNING: --> "shared_pool_size" needs to be increased to at least 596 MB . ********************************************************************** Renamed Parameters: [Update Oracle Database 11.2 init.ora or spfile] ********************************************************************** -- No renamed parameters found. No changes are required. . ********************************************************************** Obsolete/Deprecated Parameters: [Update Oracle Database 11.2 init.ora or spfile] ********************************************************************** --> background_dump_dest 11.1 DEPRECATED replaced by "diagnostic_dest" --> user_dump_dest 11.1 DEPRECATED replaced by "diagnostic_dest" --> core_dump_dest 11.1 DEPRECATED replaced by "diagnostic_dest" . ********************************************************************** Components: [The following database components will be upgraded or installed] ********************************************************************** --> Oracle Catalog Views [upgrade] VALID --> Oracle Packages and Types [upgrade] VALID . ********************************************************************** Miscellaneous Warnings ********************************************************************** WARNING: --> Database is using a timezone file older than version 11. .... After the release migration, it is recommended that DBMS_DST package .... be used to upgrade the 10.2.0.4.0 database timezone version .... to the latest version which comes with the new release. WARNING: --> Database contains schemas with stale optimizer statistics. .... Refer to the Upgrade Guide for instructions to update .... schema statistics prior to upgrading the database. .... Component Schemas with stale statistics: .... SYS WARNING: --> Database contains INVALID objects prior to upgrade. .... The list of invalid SYS/SYSTEM objects was written to .... registry$sys_inv_objs. .... The list of non-SYS/SYSTEM objects was written to .... registry$nonsys_inv_objs. .... Use utluiobj.sql after the upgrade to identify any new invalid .... objects due to the upgrade. .... USER PUBLIC has 1 INVALID objects. .... USER SYS has 2 INVALID objects. .... USER OPS$BRU has 1 INVALID objects. WARNING: --> log_archive_format must be updated. .... As of 10.1, log_archive_format requires a %r format qualifier .... be present in its format string. Your current setting is: .... log_archive_format='T%t_S%s.arc'. .... Archive Logging is currently OFF, but failure to add the %r to the .... format string will still prevent the upgraded database from starting up. WARNING:--> recycle bin in use. .... Your recycle bin turned on. .... It is REQUIRED .... that the recycle bin is empty prior to upgrading .... your database. .... The command: PURGE DBA_RECYCLEBIN .... must be executed immediately prior to executing your upgrade. . PL/SQL procedure successfully completed.
Cette section affiche les informations globales sur la base Oracle 10g (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. La version du fichier timezone est une nouveauté 10g (timezone file), ce point est abordé un peu plus loin.
********************************************************************** Database: ********************************************************************** --> name: UBXU1 --> version: 10.2.0.4.0 --> compatible: 9.2.0 --> blocksize: 8192 --> platform: Solaris[tm] OE (64-bit) --> timezone file: V4
La section Tablespaces liste les tablespaces systèmes (SYSTEM, UNDO, TEMP etc...) éventuellement sous dimensionnés pour une migration vers Oracle 11g. Il n'y a pas de nouveaux tablespaces systèmes avec la version 11g.
********************************************************************** Tablespaces: [make adjustments in the current environment] ********************************************************************** WARNING: --> SYSTEM tablespace is not large enough for the upgrade. .... currently allocated size: 450 MB .... minimum required size: 464 MB .... increase current size by: 14 MB .... tablespace is NOT AUTOEXTEND ENABLED. --> TEMPO tablespace is adequate for the upgrade. .... minimum required size: 61 MB --> SYSAUX tablespace is adequate for the upgrade. .... minimum required size: 411 MB --> UNDO tablespace is adequate for the upgrade. .... minimum required size: 122 MB
Dans le contexte de cette migration, le tablespace SYSTEM doit être étendu à 464 Mb (taille actuelle : 450 Mb)
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
SQL> select file_name, tablespace_name, bytes from dba_data_files where tablespace_name='SYSTEM'; FILE_NAME TABLESPACE_NAME BYTES -------------------------------------- ----------------- ---------- /ubix/oracle/UBXU1ORA/SYSTEM_01.dbf SYSTEM 157286400 /ubix/oracle/UBXU1ORA/SYSTEM_02.dbf SYSTEM 157286400 /ubix/oracle/UBXU1ORA/SYSTEM_03.dbf SYSTEM 157286400 SQL> ALTER DATABASE DATAFILE '/ubix/oracle/UBXU1ORA/SYSTEM_03.dbf' resize 200M; Database altered.
Tous les autres tablespaces systèmes sont correctement dimensionnés (TEMP, UNDO).
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 11g.
********************************************************************** Update Parameters: [Update Oracle Database 11.2 init.ora or spfile] ********************************************************************** WARNING: --> "compatible" must be set to at least 10.1.0 WARNING: --> "shared_pool_size" needs to be increased to at least 596 MB . ********************************************************************** Renamed Parameters: [Update Oracle Database 11.2 init.ora or spfile] ********************************************************************** -- No renamed parameters found. No changes are required. . ********************************************************************** Obsolete/Deprecated Parameters: [Update Oracle Database 11.2 init.ora or spfile] ********************************************************************** --> background_dump_dest 11.1 DEPRECATED replaced by "diagnostic_dest" --> user_dump_dest 11.1 DEPRECATED replaced by "diagnostic_dest" --> core_dump_dest 11.1 DEPRECATED replaced by "diagnostic_dest" .
Dans l'exemple de cet article :
La section Components indique les composants bases de données (Catalog, Data Mining, OLAP, RAC ...) ainsi que leur statut 10g qui vont être migrés ou installés. Ici, tous les composants systèmes sont valides (aucun package et aucune vue du catalogue invalide) pour une migration vers la version 11g R2 ( [upgrade] ).
********************************************************************** Components: [The following database components will be upgraded or installed] ********************************************************************** --> Oracle Catalog Views [upgrade] VALID --> Oracle Packages and Types [upgrade] VALID .
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: --> Database is using a timezone file older than version 11. .... After the release migration, it is recommended that DBMS_DST package .... be used to upgrade the 10.2.0.4.0 database timezone version .... to the latest version which comes with the new release. WARNING: --> Database contains schemas with stale optimizer statistics. .... Refer to the Upgrade Guide for instructions to update .... schema statistics prior to upgrading the database. .... Component Schemas with stale statistics: .... SYS WARNING: --> Database contains INVALID objects prior to upgrade. .... The list of invalid SYS/SYSTEM objects was written to .... registry$sys_inv_objs. .... The list of non-SYS/SYSTEM objects was written to .... registry$nonsys_inv_objs. .... Use utluiobj.sql after the upgrade to identify any new invalid .... objects due to the upgrade. .... USER OPS$BRU has 1 INVALID objects. WARNING: --> log_archive_format must be updated. .... As of 10.1, log_archive_format requires a %r format qualifier .... be present in its format string. Your current setting is: .... log_archive_format='T%t_S%s.arc'. .... Archive Logging is currently OFF, but failure to add the %r to the .... format string will still prevent the upgraded database from starting up. WARNING:--> recycle bin in use. .... Your recycle bin turned on. .... It is REQUIRED .... that the recycle bin is empty prior to upgrading .... your database. .... The command: PURGE DBA_RECYCLEBIN .... must be executed immediately prior to executing your upgrade. . .
Les objets invalides pour OPS$BRU ont été étudiés et le statut invalide était applicativement normal, pour retrouver les objets au statut invalide ainsi que leur type :
SQL> select owner, object_name, object_type from dba_objects where status='INVALID';
OWNER OBJECT_NAME OBJECT_TYPE ------------ -------------------------------- ------------------- OPS$BRU UFO_RISK PACKAGE BODY
Une nouvelle version du fichier timezone est livrée avec Oracle 11gR2 pour incorporer de nouvelles définitions de fuseaux horaires. Le fichier timezone timezlrg.dat d'une distribution Oracle est localisé dans le répertoire $ORACLE_HOME/oracore/zoneinfo, ce fichier est crypté et contient tous les fuseaux horaires définis dans l'instance.
Pour retrouver la version du fichier timezone avec Oracle 10g R2, interroger la vue v$timezone_file :
SQL> select * from v$timezone_file;
FILENAME VERSION ------------ ---------- timezlrg.dat 4
À partir de la version 11g R2, le package DBMS_DST permet de migrer simplement l'instance vers la nouvelle version de fichier timezone 11g R2, la procédure était bien moins simple avec la version 11g R1. Le package DBMS_DST sera utilisé à l'issue de la migration.
Lors de la migration vers Oracle 11g, les statistiques sont collectées pour les tables du dictionnaire qui ont des statistiques manquantes ou trop anciennes. 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 10.2.0.
Après mise à jour des statistiques, cet avertissement n'est plus donné par l'utilitaire utlu112i.sql.
À partir de la version 10.1, Oracle recommande fortement d'ajouter le paramètre %r dans le format de chaîne des fichiers archivelog.
L'ancien format était T%t_S%s.arc : %t pour le numéro du thread d'archivage (ARC) écrivant le fichier d'archive log et %s pour le numéro de séquence de log.
Le script de migration vers la version 10.2 (utlu102i.sql) n'avait pas levé cette recommandation à l'époque lors de la migration de la version 9i R2 vers la version 10g R2 (10.2). Le paramètre %r correspond à l'identifiant unique de réincarnation, il renforce et sécurise l'unicité des noms des fichiers d'archive log lorsque de multiples incarnations de la base de données sont réalisées (create controlfile).
Le changement de format des fichiers d'archive log sera réalisé après la migration vers la version 11g R2 et lors de la remise en route du mode archivelog pour y ajouter le paramètre %r. Le nouveau format des archive log qui sera appliqué est le suivant : T%t_S%s_R%r.arc. Le mode archivelog est retiré durant la migration pour optimiser le temps de migration.
La corbeille (recycle bin) est une nouveauté 10g qui est par ailleurs activée par défaut.
SQL> select name, value from v$parameter where name='recyclebin';
NAME VALUE ----------------------------------- -------------------------------------- recyclebin on
Lorque la corbeille est activée et même si elle n'est pas utilisée, il est IMPERATIF que la corbeille soit vide avant la migration vers la version 11g : cet avertissement est levé dans le script utlu112i.sql. Pour vérifier si la corbeille est vide, interroger en tant que sysdba la vue recyclebin :
SQL> select object_name from recyclebin;
no rows selected
La possibilité de vider la corbeille à l'étape de la migration va dépendre des contraintes liées à l'applicatif. La commande PURGE DBA_RECYCLEBIN vide la corbeille, commande à lancer si et seulement si la valeur du paramètre COMPATIBLE est supérieure à la version 9.x puisqu'il s'agit d'une nouveauté 10g (COMPATIBLE parameter needs to be 10.0.0.0.0 or greater).
Avant la migration effective, l'instance est sauvegardée et le mode archivelog est retiré.
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 initUBXU1ORA.ora est donc créé dans le répertoire /Software/oracle/app/product/11.2.0.1/dbs, lien qui pointe vers /Software/oracle/Instances/pfile/initUBX1ORA.ora.
shell> cd /Software/oracle/app/product/11.2.0.1/dbs shell> ln -fs /Software/oracle/Instances/UBXU1ORA/pfile/initUBXU1ORA.ora initUBXU1ORA.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/11.2.0.1/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/11.2.0.1/network/admin shell> ln -fs /Software/oracle/Network/listener.ora listener.ora shell> ln -fs /Software/oracle/Network/tnsnames.ora tnsnames.ora
La version 11.2.0.1 étant la future version majoritaire 11.2.0.x des instances, un lien 11.2.0 pointant vers le répertoire 11.2.0.1 est créé dans le répertoire /Software/oracle/app/product :
shell> cd /Software/oracle/app/product shell> ln -fs 11.2.0.1 11.2.0
L'instance Oracle 10g UBXU1ORA est arrêtée avec SQL*Plus avec la commande shutdown immediate.
oracle@UBXU1ORA> sqlplus "/ as sysdba" SQL> shutdown immediate; Database closed. Database dismounted. ORACLE instance shut down.
Le listener LISTENER_UBXU1ORA de l'instance 10g UBXU1ORA est également arrêté avec le binaire lsnrctl.
oracle@UBXU1ORA> lsnrctl lsnrctl> stop LISTENER_UBXU1ORA; Connecting to (ADDRESS=(PROTOCOL=TCP)(Host=BOHRIUM)(Port=1525)) The command completed successfully
Le fichier d'environnement de l'instance UBXU1ORA ($DBA/etc/UBXU1ORA.inst) est alors modifié pour basculer sur la version 11.2.0. Une nouvelle variable ORA_NLS11 spécifique 11g fait son apparition et doit pointer sur le répertoire $ORACLE_HOME11g/nls/data dans ce fichier d'environnement.
cat $DBA/etc/UBXU1ORA.inst
... ORA_VERSION="11.2.0" ... export ORA_NLS11=$ORACLE_HOME/nls/data ...
Une nouvelle session oracle en prenant l'environnement UBXU1ORA est alors lancée pour démarrer la migration en vérifiant que les 5 variables ci-dessous sont correctement initialisées :
Conformément aux préconisations de l'outil de pré-migration utlu112i.sql, les paramètres d'initialisation sont modifiés dans le fichier initUBXU1ORA.ora.
oracle@UBXU1ORA> vi $CFG/initUBXU1ORA.ora
#core_dump_dest=/Software/oracle/Instances/UBXU1ORA/cdump #user_dump_dest=/Software/oracle/Instances/UBXU1ORA/udump #background_dump_dest=/Software/oracle/Instances/UBXU1ORA/bdump compatible=10.1.0 diagnostic_dest=/Software/oracle/Instances/UBXU1ORA/bdump shared_pool_size=600M # log_archive_format=T%t_S%s.arc log_archive_format=T%t_S%s_R%r.arc
L'instance est alors démarrée en environnement 11g avec l'option UPGRADE de la commande STARTUP via SQL*Plus.
oracle@UBXU1ORA> sqlplus "/ as sysdba" SQL> STARTUP UPGRADE;
Le script de migration catupgrd.sql peut alors être exécuté :
SQL> spool upgradeUBXU1ORA.log SQL> @?/rdbms/admin/catupgrd.sql SQL> spool off
Consulter le fichier de log pour repérer toutes les erreurs.
Une petite surprise de taille, contrairement à la version 10g, le script catupgrd.sql éteint l'instance à l'issue de la migration. L'arrêt shutdown immediate est lancé dans le script $ORACLE_HOME/rdbms/admin/utlmmig.sql (Mini migration for Bootstrap objects), script appelé par catupgrd.sql.
Petite coquille d'Oracle, le script utlu112s.sql qui vérifie l'état de la migration est lancé juste après la commande d'arrêt SHUTDOWN IMMEDIATE : les erreurs "Oracle not available" sont donc normales pour ce script.
Si le script utlmmig.sql s'est terminé avec une erreur, redémarrer l'instance avec l'option STARTUP UPGRADE afin de résoudre ce problème car dans le cas d'un redémarrage normal, l'erreur ORA-39714 sera levée (ORA-39714: upgrade script utlmmig.sql failed).
Redémarrer l'instance en mode upgrade si la commande shutdown a été lancée par le script de migration catupgrd.sql.
Le script $ORACLE_HOME/admin/utlu112s.sql affiche les résultats de la migration afin de vérifier que la migration de toutes les options est valide :
SQL> @?/rdbms/admin/utlu112s.sql
Oracle Database 11.2 Post-Upgrade Status Tool 10-16-2010 18:51:26 . Component Status Version HH:MM:SS . Oracle Server . VALID 11.2.0.1.0 00:14:32 Gathering Statistics . 00:04:53 Total Upgrade Time: 00:19:26 PL/SQL procedure successfully completed.
La vue dba_registry donne également le statut de la validité des composants systèmes à l'issue de la migration :
SQL> select comp_name, version, status from dba_registry COMP_NAME VERSION STATUS --------------------------------------- -------------- ----------- Oracle Database Catalog Views 11.2.0.1.0 VALID Oracle Database Packages and Types 11.2.0.1.0 VALID
La migration a mis au statut invalide un bon nombre d'objets systèmes et utilisateur, ce qui est normal (altération de tables, de statistiques etc...). C'est pourquoi avant d'analyser les objets réellement 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.
SQL> @?/rdbms/admin/utlrp.sql
TIMESTAMP
--------------------------------------------------------------------------------
COMP_TIMESTAMP UTLRP_END 2010-10-16 19:04:11
PL/SQL procedure successfully completed.
...
OBJECTS WITH ERRORS
-------------------
0
...
ERRORS DURING RECOMPILATION
---------------------------
0
La vue dba_objects permet de retrouver rapidement les objets invalides en cause afin d'apporter les corrections nécessaires.
SQL> select object_name, object_type, owner, status from dba_objects where status='INVALID'; OBJECT_NAME OBJECT_TYPE OWNER STATUS -------------- --------------- ------------------------- ---------- INFLATE PACKAGE BODY OPS$BRU INVALID UFO_RISK PACKAGE BODY OPS$BRU INVALID
Dans le contexte de la migration de l'instance UBXU1ORA, aucun objet système est invalide et c'est l'essentiel d'un point de vue migration infrastructure. Les seuls objets invalides sont des objets utilisateur : l'objet déjà identifié invalide avec la version 10g, invalidité applicative et "normale" (OPS$BRU.UFO_RISK) et un autre objet (OPS$BRU.INFLATE) qui est détruit avec la nouvelle version applicative accompagnant cette migration de version Oracle.
Le script utlu112i.sql indique qu'il est nécessaire de migrer la version du timezone avec DBMS_DST. L'instance doit être impérativement en mode UPGRADE pour cette opération. Si ce n'est pas le cas redémarrer l'instance en mode upgrade :
oracle@UBXU1ORA> sqlplus "/ as sysdba"
shutdown immediate; startup upgrade;
L'option upgrade du package DBMS_DST est activée vers la version 11 avec la procédure begin_upgrade de ce package :
SQL> exec dbms_dst.begin_upgrade(11);
PL/SQL procedure successfully completed.
La vue database_properties indique le statut de l'upgrade :
SQL> select property_name, property_value
from database_properties
where property_name like 'DST_%'
order by property_name;
PROPERTY_NAME PROPERTY_VALUE
-------------------------- --------------------------
DST_PRIMARY_TT_VERSION 11
DST_SECONDARY_TT_VERSION 4
DST_UPGRADE_STATE UPGRADE
La procédure dbms_dst.begin_upgrade(11) migre la plupart des tables du dictionnaire, les tables qui ne sont pas encore migrées ont le statut à YES dans la colonne UPGRADE_IN_PROGRESS de la vue ALL_TSTZ_TABLES :
SQL> select owner, table_name, upgrade_in_progress from all_tstz_tables;
OWNER TABLE_NAME UPG ------------------------------ ------------------------------ --- SYS ALERT_QT NO SYS KET$_AUTOTASK_STATUS NO
Dans le cas de l'instance UBXU1ORA, aucune table n'a le statut YES, ce qui signifie qu'il n'y a aucune table du dictionnaire à migrer vers la nouvelle version des timezones Oracle 11g.
Redémarrer ensuite l'instance en mode normal et déclencher la procédure upgrade_database du package dbms_dst si il existe des tables à migrer, puis la procédure end_upgrade pour fermer la fenêtre de migration des fuseaux horaires :
shutdown immediate; startup; set serveroutput on; declare num_of_failures number; begin dbms_dst.upgrade_database(num_of_failures); dbms_output.put_line(num_of_failures); dbms_dst.end_upgrade(num_of_failures); end ;
0 PL/SQL procedure successfully completed. PL/SQL procedure successfully completed. 0 An upgrade window has been successfully ended. PL/SQL procedure successfully completed.
Si la procédure upgrade_database rencontre des échecs, bien entendu la procédure end_upgrade se terminera également en erreur et la fenêtre de migration des timezones demeure au statut UPGRADE.
Lorsque la migration est terminée, le statut de migration des timezones passe à NONE dans la vue database_properties :
SQL> select property_name, property_value
from database_properties
where property_name like 'DST_%'
order by property_name;
PROPERTY_NAME PROPERTY_VALUE
-------------------------- --------------------------
DST_PRIMARY_TT_VERSION 11
DST_SECONDARY_TT_VERSION 0
DST_UPGRADE_STATE NONE
Si l'instance est encore en mode UPGRADE, l'instance peut alors être redémarrée en mode normal. Le mode archivelog est réactivée ultérieurement.
SQL> shutdown immediate; Database closed. Database dismounted. ORACLE instance shut down. SQL> startup; ORACLE instance started.
Le fichier listener.ora dans le répertoire $TNS_ADMIN est ensuite modifié pour prendre en compte l'environnement 11g pour l'instance UBXU1ORA et le listener correspondant est démarré avec lsnrctl :
LISTENER_UBXU1ORA =
(ADDRESS_LIST =
(ADDRESS= (PROTOCOL= TCP)(Host= BOHRIUM)(Port= 1525))
(ADDRESS= (PROTOCOL= IPC)(KEY=UBXU1ORA))
)
SID_LIST_LISTENER_UBXU1ORA =
(SID_LIST =
(SID_DESC =
(ORACLE_HOME = /Software/oracle/app/product/11.2.0)
(SID_NAME = UBXU1ORA)
(GLOBAL_DBNAME = UBXU1ORA)
)
)
LOG_DIRECTORY_LISTENER_UBXU1ORA=/Software/oracle/Instances/UBXU1ORA/bdump
LOG_FILE_LISTENER_UBXU1ORA=listener_UBXU1ORA.log
shell> lsnrctl LSNRCTL> start LISTENER_UBXU1ORA Starting /Software/oracle/app/product/11.2.0/bin/tnslsnr: please wait... TNSLSNR for Solaris: Version 11.2.0.1.0 - Production System parameter file is /Software/oracle/Network/listener.ora Log messages written to /Software/oracle/app/product/diag/tnslsnr/BOHRIUM/listener_ubxu1ora/alert/log.xml Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=BOHRIUM)(PORT=1522))) Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=UBXU1ORA))) Connecting to (ADDRESS=(PROTOCOL=TCP)(Host=BOHRIUM)(Port=1522)) STATUS of the LISTENER ------------------------ Alias LISTENER_UBXU1ORA Version TNSLSNR for Solaris: Version 11.2.0.1.0 - Production Start Date 17-OCT. -2010 19:14:14 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/app/product/diag/tnslsnr/BOHRIUM/listener_ubxu1ora/alert/log.xml Listening Endpoints Summary... (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=BOHRIUM)(PORT=1522))) (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=UBXU1ORA))) Services Summary... Service "UBXU1ORA" has 1 instance(s). Instance "UBXU1ORA", status UNKNOWN, has 1 handler(s) for this service... The command completed successfully
Tous les fichiers de log et de trace sont fortement modifiés dans la version
11g avec l'introduction de l'ADR (Automatic Diagnostic Repository), mais ce
point n'est pas l'objet de cet article.
SQL >
spool gdict
grant analyze any to sys;
exec dbms_stats.gather_dictionary_stats;
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
| Version | Date | Commentaires |
|---|---|---|
| 1.0 | 10/2010 | Version initiale |
Oracle 11g R2
BOL : Upgrading to the New Oracle Database 11g Release 2
Oracle 11g R2
BOL : Using the pre upgrade information tool
Oracle 11g R2
BOL : Steps to Upgrade Time Zone File and Timestamp with Time Zone Data