Discussion :

[MatthieuQ]

Bonjour,
Le DBA de ma boite a tenté de « patcher » le serveur Oracle 10.2.0.2 en 10.2.0.3.

On installe le patch avec l’interface graphique. Pas de problème. Il nous est ensuite demandé de lancer la commande catupgrd.sql pour chaque instance.

Le script se termine avec l’information suivante DATABASE INVALID.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
Oracle Database 10.2 Upgrade Status Utility           02-13-2009 19:37:31
Component                                Status         Version  HH:MM:SS
Oracle Database Server                  INVALID      10.2.0.3.0  00:16:34
JServer JAVA Virtual Machine              VALID      10.2.0.3.0  00:03:05
Oracle XDK                                VALID      10.2.0.3.0  00:00:58
Oracle Database Java Packages           INVALID      10.2.0.3.0  00:00:19
Oracle Data Mining                   OPTION OFF      10.2.0.1.0  00:00:00
Oracle Expression Filter                  VALID      10.2.0.3.0  00:00:20
Oracle Enterprise Manager                 VALID      10.2.0.3.0  00:02:24

On vérifie les fichiers logs et on trouve les messages suivants :
Pour l’instance 1

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
SQL> /* -------------------------------------------------------------------------
>  *   DBMS_SWRF_REPORT_INTERNAL PACKAGE BODY
SQL>  *
SQL>  *     This package will handle the reporting for AWR. It will have the
SQL>  *     following interfaces:
SQL>  * ------------------------------------------------------------------------- */
SQL> create or replace package body dbms_swrf_report_internal wrapped

(...)Des milliers de lignes puis :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
Avertissement : Corps de package créé avec erreurs de compilation.
SQL> show errors;
Erreurs pour PACKAGE BODY DBMS_SWRF_REPORT_INTERNAL :
LINE/COL ERROR
-------- -----------------------------------------------------------------
0/0      ORA-04030: mémoire de traitement manquante lors d'affectation de
         16408 octets (PL/SQL Opt Poo,pdziM01_Create: New Set)

Pour l’instance 2, même message également

Concernant l’erreur Java, le code d’erreur est :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
SQL> 
SQL> select dbms_java.full_ncomp_enabled from dual;
select dbms_java.full_ncomp_enabled from dual
       *
ERREUR à la ligne 1 :
ORA-29558: JAccelerator (NCOMP) n'est pas installé. Pour plus d'informations,
reportez-vous au guide d'installation.
ORA-06512: à "SYS.DBMS_JAVA", ligne 236

D’après une doc, l’erreur Java (ORA-29558) n’est pas contraignante pour notre application. Mais l’autre (ORA-04030) peut avoir des causes très différentes (mémoire vive, espace disque, etc.)

On a redémarré nos bases et visiblement elles sont accessibles et « patchées ». On hésite donc à lancer le script sur les instances de prod.
Ce message « Oracle Database Server INVALID » nous fiche un peu les jetons ...

Savez vous si le message « INVALID » apparaît dès qu’il y a une erreur dans le log ou a-t’il une autre signification ?
Par avance, merci de vos réponses.

[Mathias44]

Bonjour,

Avez-vous scrupuleusement respecté les pré-requis avant mise à jour du dictionnaire ? Notamment en ce qui concerne la taille minimum que doit avoir la shared pool ?
Lorsque vous restaurez et que vous interrogez DBA_REGISTRY, avez-vous des composants déjà INVALID ?
Sous quel OS êtes vous (version, architecture) ?

[orafrance]

Regarde la note 423292.1, vérifie bien que les ulimit sont OK.

Pour le diagnostic complet, c'est dans la note 233869.1 que ça se passe

[MatthieuQ]

Merci à vous.
Je suis allé voir le doc 423292.1 qui permet de changer les valeurs avec ulimit.

Solution
- Increase the data segment size of shell for the user performing the migration.

- These values can be checked by 'ulimit -a' command which should return output like given below :

ulimit -a
----------
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) 131072
stack(kbytes) 32768
memory(kbytes) 32768
coredump(blocks) 2097151
nofiles(descriptors) 2000

- Increase the 'data segment' limit value to be unlimited.

Commands to perform these changes are :

> For Data Segment size : ulimit -d unlimited
> For File size : ulimit -f unlimited

After these changes, 'ulimit -a' command should return these values as follows :

ulimit -a
----------
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) unlimited

J'ai ensuite relance le script catupgrd.sql et tout est rentré dans l'ordre.
Entre temps, un contact m'a dit de changer également la valeur de stack et de le mettre à unlimited comme pour data. Pensez-vous que cela soit nécessaire ?

Merci par avance,

[MatthieuQ]

Bonjour,

Vraisemblablement, le fait de mettre stack en unlimited est impossible. Donc, le problème est réglé.

Merci.

[scheu]

Par expérience je mets toujours à "illimité" tous les paramètres ulimit du compte Unix oracle qui peuvent l'être

Sinon pour ton erreur "ORA-29558: JAccelerator (NCOMP) n'est pas installé" le problème est qu'à l'installation du noyau Oracle 10gR les composants supplémentaires du CD Companion n'ont pas été installés, d'où ton erreur

Par contre je ne sais pas si tu peux installer le CD Companion 10.2.0.1 alors que tu viens de patcher ton noyau en 10.2.0.3 (si quelqu'un à la réponse je suis preneur )

Si tu n'utilises pas JAVA sur ta base, tu peux les désinstaller (note Metalink 472937.1), puis relancer utlrp.sql, normalement ensuite "Oracle DATABASE Server" devrait repasser à VALID dans ta vue dba_registry

C'est toujours le problème quand on installe une base avec l'assistant graphique (dbca) et qu'on laisse par défaut l'installation de tous les composants (dont on n'a bien souvent pas besoin), c'est comme ça qu'on se retrouve avec ce genre de problème de migration

[MatthieuQ]

Merci de ta réponse.

Comme je le disais, le problème a été réglé en utilisant ulimit.
Pour JAccelerator, je peux m'en passer. Il ne fait pas partie des pré-requis.

Juste une petite remarque. Il est quand même incroyable de devoir attendre 20 minutes pendant lesquelles le "patch" tourne pour obtenir un message d'invalidité de la base.

Je ne vois pas trop à quoi servent ces paramètres que l'on modifie avec ulimit (je ne suis pas admin Oracle ni Unix), et je constate que mes logs d'installation du patch font plus de 15 Mo chacun. (20Mo pour le plus gros).

Il serait intéressant d'avoir de la part d'Oracle une routine qui permette de tester ces valeurs avant le passage du patch non ?

En tout cas, merci de votre aide.