Aucun message portant le libellé UTLRP. Afficher tous les messages
Aucun message portant le libellé UTLRP. Afficher tous les messages

vendredi 18 mai 2012

Statistiques non collectées automatiquement

Les statistiques sur les « fixed object » doivent être collectées manuellement. Elles ne sont pas collectées automatiquement par la tâche automatisée qu’Oracle créé pour la collecte de statistiques. La collecte s’effectue en exécutant la commande « DBMS_STATS.GATHER_FIXED_OBJECTS_STATS ».

Ces objets contiennent des informations concernant l’activité de la base de données et elles sont accédées fréquemment donc il  y a un impact direct sur le temps réponse si les statistiques sont désuètes.

Il  est recommandé de réaliser la collecte lorsqu’il y a une activité (charge) représentative sur la base de données.  D’autant plus, suite à l’exécution du script « catupgrd.sql », il est conseillé d’effectuer la collecte de statistiques sur ces objets pour optimiser le temps de traitement de la recompilation via le script « utlrp.sql ».

En ce qui concerne la fréquence de collecte, veuillez actualiser les statistiques lorsque si une mise à jour majeure est effectuée sur la base de données ou sur une application, aussi lorsque vous apportez des changements importants à la configuration de la base de données.

mercredi 6 mai 2009

ORA-00600 suite à une migration à 10.2.0.4.0

Suite à la migration d'une base de données de la version 10.2.0.3.0 à 10.2.0.4.0, l'exécution du script de recompilation "utlrp.sql" provoquait l'erreur suivante :

ORA-00600: internal error code, arguments: [psdmsc.c: spawned type invalid],
[], [], [], [], [], [], []

Pour résoudre ce problème, il suffit de procéder comme suit :

cd $ORACLE_HOME/rdbms/admin
sqlplus / as sysdba
shutdown immediate
startup upgrade
@utlirp

Declare
MASK constant varchar2(80) := 'SYS_PLSQL_[0-9]+_([0-9]+DUMMY)_[12]';
dep_count number;
Begin
select count(*) into dep_count from dba_dependencies
where (referenced_owner, referenced_name, referenced_type) in
(select owner, object_name, object_type from dba_objects
where object_type = 'TYPE'
and regexp_like(object_name, MASK))
and not (type = 'TYPE' and regexp_like(name, MASK));

if (dep_count > 0) then
raise_application_error(-20001,
'Unknown dependent objects on system-generated types');
end if;

for r in (select owner, object_name from dba_objects
where object_type = 'TYPE'
and regexp_like(object_name, MASK))
loop
execute immediate 'drop type "'r.owner'"."'r.object_name
'" force';
end loop;
End;
/

Shutdown immediate
startup
@utlrp.sql

Réf. : Oracle Metalink, Note 726623.1

lundi 16 mars 2009

ORA-07445 sur compilation avec UTLRP

La recompilation avec l’utilitaire « UTLRP » peut planter avec l’erreur suivante :

ORA-07445: exception encountered: core dump [kglsget()+140] [SIGSEGV] [Address not mapped to object] [0x000000008] [] []

Cette erreur est causé par un manque de privilège sur un objet, par exemple une table, qui est référé dans un objet PL/SQL (procédure, fonction, package, trigger).

C’est un bug connu chez Oracle. Pour contourner le problème, il suffit de donner les droits manquants au schéma concerné.

Ce problème a été observé sur une base de données 10.2.0.3.0 sous Sun Solaris.

Pour plus de détails, voir la note « 465095.1 » sur Oracle Metalink

samedi 28 février 2009

Migrer une base de données vers un autre ORACLE_HOME

J'ai eu à migrer une bases de données 10.2.0.3 à 10.2.0.4.

La façon préconisée a été d'installer un nouveau "ORACLE_HOME" et tant qu'à faire, j'en ai profité pour déployer le CPU d'Oracle (Critical Patch Update Jan2009).

Installation
1. Installer le logiciel "Oracle Database 10.2.0.1"
2. Installer le patchset "Oracle Database 10.2.0.4"
3. Installer le "CPU January 2009"

Migration
1. Arrêt de la base de données

$ sqlplus / as sysdba
SQL> shutdown immediate

2. Création d'un fichier de paramètres PFILE à partir du SPFILE

$ sqlplus / as sysdba
SQL> create pfile='ORACLE_HOME/dbs/initORCL.ora' from spfile;
$ cd ORACLE_HOME/dbs
$ cp initORCL.ora NOUV_ORACLE_HOME/dbs/initORCL.ora

3. Editer le PFILE et modifier les paramètres dont ceux qui pointent dans l'ancien ORACLE_HOME ( compatible, optimizer_features_enable, etc...)

$ cd NOUV_ORACLE_HOME/dbs
$ vi initORCL.ora

4. Modifier le fichier ORATAB

Changer l'ORACLE_HOME correspondant à la base de données

$vi oratab
ORCL:NOUV_ORACLE_HOME:Y

5. Modifier le fichier de configuration du listener

(SID_DESC =
(GLOBAL_DBNAME = ORCL.world)
(ORACLE_HOME = NOUV_ORACLE_HOME)
(ENVS = 'LD_LIBRARY_PATH=NOUV_ORACLE_HOME/lib')
(SID_NAME = ORCL)

6. Redémarrer le listener

$ lsnrctl reload lsnr1020

7. Création des liens pour des fichiers (optionel)

Si vous n'utilisez pas les emplacements par défaut de certains fichiers (c'est mon cas!) alors vous devez créer des liens symboliques sous Unix.

Il suffit de se positionner dans le répertoire par défaut puis d'exécuter la commande:

- Pour l' ALERTSID.LOG
cd NOUV_ORACLE_HOME/rdbms/log
ln -s REPERTOIRE_DE_DESTN/alert_ORCL.log alert_ORCL.log

- Pour les fichiers de configuration (PFILE, SPFILE)
cd NOUV_ORACLE_HOME/dbs
ln –s REPERTOIRE_DE_DESTN/initORCL.ora initORCL.ora
ln –s REPERTOIRE_DE_DESTN/spfileORCL.ora spfileORCL.ora

8. Créer le fichier de mot de passe

$ orapwd file=NOUV_ORACLE_HOME/dbs/orapwORCL password= entries=20

9. Démarrer la base de données sous le nouveau ORACLE_HOME

$ sqlplus / as sysdba
SQL> create spfile from pfile='NOUV_ORACLE_HOME/dbs/initORCL.ora';

10. Démarrer la migration de la base de données

SQL> startup upgrade
SQL> SPOOL upgrade_info.log
SQL> @?/rdbms/admin/utlu102i.sql
SQL> SPOOL OFF

-- Vérifier le log précédent pour tout problème

SQL> SPOOL patch.log
SQL> @?/rdbms/admin/catupgrd.sql
SQL> SPOOL OFF
-- Vérifier le log précédent pour tout problème

11. Redémarrer la base de données en mode normal

SQL> SHUTDOWN IMMEDIATE
SQL> STARTUP

12. Recompiler les objets invalides

SQL> @?/rdbms/admin/utlrp.sql

13. Vérifier le statut des composantes de la base de données

SQL> SELECT COMP_NAME, VERSION, STATUS FROM SYS.DBA_REGISTRY;


Cette façon permet de réinstaller proprement le logiciel de la base de données. Aussi, l'avantage de celle-ci est que si votre ORACLE_HOME actuel est partagé par plusieurs bases de données, vous pourrez migrer une base de données sans impacter les autres. Cette méthode peut aussi être utilisé pour déplacer une base de données vers un autre ORACLE_HOME.