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.
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
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.
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" SQL> spool pre_upgrade.log SQL> @utlu102i.sql SQL> spool off SQL> exit
Voici le résultat du script utlu102i.sql en sortie pour l'instance DBAT1ORA 9i à migrer ;
cat /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.
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
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 la création des groupes de fichiers de redo log si c'est le cas).
********************************************************************** Logfiles: [make adjustments in the current environment] ********************************************************************** ********************************************************************** --> The existing log files are adequate. No changes are required. .
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)
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 -------------------------------------- ----------------- ---------- /dba/oracle/DBAT1ORA/SYSTEM_01.dbf SYSTEM 104857600 /dba/oracle/DBAT1ORA/SYSTEM_02.dbf SYSTEM 104857600 SQL> 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).
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"
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 :
SQL> 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.
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 :
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 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.
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 :
SQL> 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
SQL 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
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.
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 .
Avant la migration effective, l'instance est sauvegardée.
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
L'instance Oracle 9I DBAT1ORA est arrêtée avec SQL*Plus avec la commande shutdown immediate.
oracle@DBAT1ORA> sqlplus "/ as sysdba" SQL> 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=CALYPSO)(Port=1525)) The command completed successfully
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.
cat $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 :
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.
oracle@DBAT1ORA> vi $CFG/initDBAT1ORA.ora
#log_archive_start = true large_pool_size = 8388608 streams_pool_size = 50331648 session_max_open_files = 20
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" SQL> 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) :
SQL> 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é :
SQL> spool upgradeDBAT1ORA.log SQL> @?/rdbms/admin/catupgrd.sql SQL> spool off
Consulter le fichier de log pour repérer toutes les erreurs.
Le script $ORACLE_HOME/admin/utlu102s.sql permet de d'afficher les résultats de la migration afin de vérifier que la migration de toutes les options est valide :
SQL> @?/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) qui est invalide, interroger la vue dba_registry :
SQL> 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
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.
SQL> @?/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
La vue dba_objects permet de retrouver rapidement les objets invalides en cause afin d'apporter les corrections nécessaires.
SQL> 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.
SQL> drop table plan_table$; SQL> drop table plan_table; SQL> @?/rdbms/admin/catplan.sql SQL> @?/rdbms/admin/dbmsxpln.sql SQL> @?/rdbms/admin/prvtxpln.plb SQL> @?/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
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.
SQL> exec dbms_registry.removed('RAC');
L'instance peut alors être redémarrée en mode normal.
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 modifé pour prendre en compte l'environnement 10g pour l'instance DBAT1ORA et le listener démarré avec lsnrctl :
LISTENER_DBAT1ORA =
(ADDRESS_LIST =
(ADDRESS= (PROTOCOL= TCP)(Host= CALYPSO)(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=CALYPSO)(PORT=1525))) Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=DBAT1ORA))) Connecting to (ADDRESS=(PROTOCOL=TCP)(Host=CALYPSO)(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=CALYPSO)(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
SQL >
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
| Version | Date | Commentaires |
|---|---|---|
| 1.0 | 08/2009 | Version initiale |
Upgrading to
the New Oracle Database 10g Release
Initialization
Parameter and Data Dictionary Changes
Deprecated
Initialization Parameters
Obsolete
Initialization Parameters