Salut,
Dernièrement, j’ai migré l’OMS (Oracle Management Service) ainsi que tous les agents à la version 10.2.0.4.0. Et, actuellement, nous sommes entrain de migrer les bases de données à la version 10.2.0.4.0.
Depuis que certaines bases de données sont passées à la nouvelle version (10.2.0.4.0), les agents sur les hôtes réagissent d’une façon très étrange. En l’espace de 2 à 3 minutes, le mécanisme de notification m’informe que l’agent ne peut pas être contacté puis, par la suite, je reçois un autre message m’indiquant que le problème est résolu.
Voici des exemples de messages de notification reçus :
Agent is Unreachable (REASON = Connection refused) but the host is UP.
Agent is Unreachable (REASON = Received unexpected response text : EMDClient request Error:nmemdisp_main Internal Error)
Ce message provenant de la notification n’indique absolument rien de précis. Je me suis pencher sur le problème et en fouillant davantage dans le fichier de trace de l’agent, j’ai trouvé une erreur qui se répétait à plusieurs reprises :
2009-03-30 16:08:37,105 Thread-1931 ERROR upload: nmehursf_logError:lfiflu failed -2 rawdata.dat 2009-03-30 16:08:37,105 Thread-1931 ERROR upload: rawdata.dat rename failed 2009-03-30 16:08:37,105 Thread-1931 ERROR upload: rawdata.dat deleted, it will not be merged 2009-03-30 16:08:37,105 Thread-1931 ERROR upload: ERROR: nmehursf_Rowset_write - lfiopn failed -2 rawdata.dat 2009-03-30 16:08:37,106 Thread-1931 ERROR upload: Error happened in nmehursf_Rowset_write:lfiopn, error = 24: Too many open files for rawdata.dat
Comme toute bonne chose à une fin, ce problème est connu chez Oracle et, un patch est disponible.
L’agent nécessite qu’un correctif soit installé sur les cibles de type base de données de la version 10.2.0.3.0. Ce correctif porte le numéro #5872000. Le correctif s’intitule :
HEALTHCHECK ERROR OCCURS FOR 32BIT DATABASE ON 64BIT OS DUE TO BUG4526916 FIX
Ce problème est perceptible seulement si l’agent doit surveiller des bases de données 10.2.0.3.0 et 10.2.0.4.0 sur un même hôte.
lundi 30 mars 2009
mardi 24 mars 2009
RMAN ne veut rien savoir, "Incarnation is not current"
Hier après-midi, je m’apprêtais à faire des essais de sauvegarde/récupération sur un serveur Unix.
Après avoir enregistré les bases de données MIG10203 et MIG10204 au catalogue RMAN, j’ai eu un problème lors d’une tentative de sauvegarde.
J’obtenais l’erreur suivante :
RMAN-20011: target database incarnation is not current in recovery catalog
Après quelques recherches, je me suis rendu compte que l’identifiant unique de la base de données (DBID) était le même pour les 2 bases de données.
C’est normal car la base de données MIG10204 a été créée en dupliquant manuellement la base de données MIG10203.
Donc, pour corriger le tout, j’ai désinscrit les 2 bases de données :
RMAN> unregister database;
Puis, j’ai suivi les étapes ci-dessous pour changer le DBID d’une des bases de données :
1. Prendre une copie de sécurité de la base de données
2. Fermer la base de données
shutdown immediate
3. Démarrer en mode « mount »
startup mount
4. démarrer une session Unix et exécuter "NID" avec les privilèges SYSDBA
$ nid TARGET=SYS/password@MIG10204
5. Fermer la base de données
shutdown immediate
6. si non fait, initialiser le paramètre "db_name" au nom désiré
7. créer un fichier de mot de passe
orapwd file=/juliet_u01/home/dba/oracle/product/10.2.0.4.0/dbs/orapwmig10204 password= entries=20
8. Démarrer et ouvrir la base de données en réinitialisant les journaux
startup mount
alter database open resetlogs
Après avoir enregistré les bases de données MIG10203 et MIG10204 au catalogue RMAN, j’ai eu un problème lors d’une tentative de sauvegarde.
J’obtenais l’erreur suivante :
RMAN-20011: target database incarnation is not current in recovery catalog
Après quelques recherches, je me suis rendu compte que l’identifiant unique de la base de données (DBID) était le même pour les 2 bases de données.
C’est normal car la base de données MIG10204 a été créée en dupliquant manuellement la base de données MIG10203.
Donc, pour corriger le tout, j’ai désinscrit les 2 bases de données :
RMAN> unregister database;
Puis, j’ai suivi les étapes ci-dessous pour changer le DBID d’une des bases de données :
1. Prendre une copie de sécurité de la base de données
2. Fermer la base de données
shutdown immediate
3. Démarrer en mode « mount »
startup mount
4. démarrer une session Unix et exécuter "NID" avec les privilèges SYSDBA
$ nid TARGET=SYS/password@MIG10204
5. Fermer la base de données
shutdown immediate
6. si non fait, initialiser le paramètre "db_name" au nom désiré
7. créer un fichier de mot de passe
orapwd file=/juliet_u01/home/dba/oracle/product/10.2.0.4.0/dbs/orapwmig10204 password=
8. Démarrer et ouvrir la base de données en réinitialisant les journaux
startup mount
alter database open resetlogs
mercredi 18 mars 2009
Archiver error... Quel est la cause ?
Durant le weekend, une base de données a rencontrée des problèmes. Elle générait plein d'écritures donc, plein de fichiers d'archive jusqu’à remplir le disque réservé aux archives.
J'avais remarqué que c'était une job (DBMS_JOB) qui exécutait un rafraichissement de vues matérialisées via un groupe de rafraichissement. Voici le code exécuté par la job :
dbms_refresh.refresh('"ABC"."ABC_GRP_REPLC"');
La job plantait et elle s'exécutait de nouveau pour effectuer une reprise automatique. Je l’ai donc interrompu, le temps de trouver la cause exacte.
Pour débuter, j’ai tenté de rafraichir les vues, à tour de rôle, pour finalement rencontrer cette erreur lors du rafraichissement manuelle d'une d'entre-elle :
ABC@ORCL> exec dbms_mview.refresh('ABC.ABC_V_DIRCT_TERRT_GENRL','C');
ERROR:
ORA-03114: pas connecté à ORACLE
BEGIN dbms_mview.refresh('ABC.ABC_V_DIRCT_TERRT_GENRL','C'); END;
*
ERROR at line 1:
ORA-03113: fin de fichier sur canal de communication
Process ID: 0
Session ID: 412 Serial number: 3177
Suite à cette erreur rencontré dans l'outil SQL*Plus, j’ai consulté le fichier « alertSID.log » de la base de données et, j’ai trouvé cette erreur :
ORA-07445: exception encountered: core dump [qcdlgcd()+116] [SIGSEGV] [Address not mapped to object] [0x000000037] [] []
Après avoir faire quelques recherches, je suis tombé sur la note 459323.1 du site Oracle Metalink qui explique ce problème. La cause provient de l’énoncé SQL qui constitue la vue matérialisée. Cet énoncé est invalide. Elle fait référence à une colonne qui n’existe plus. Pour résoudre ce problème, on doit détruire et recréer la vue matérialisée.
Étape de résolution :
- Détruire la vue matérialisée
DROP MATERIALIZED VIEW "ABC"."ABC_V_DIRCT_TERRT_GENRL";
- Créer la vue matérialisée
CREATE MATERIALIZED VIEW "ABC"."ABC_V_DIRCT_TERRT_GENRL"
TABLESPACE "ABC_D01"
USING INDEX TABLESPACE "ABC_D01"
REFRESH FORCE AS
SELECT…
- Rétablir les droits sur la vue matérialisée
GRANT SELECT ON ABC.ABC_v_dirct_terrt_genrl TO abcpool;
- Ajouter la vue matérialisée au groupe de rafraichissement
BEGIN
DBMS_REFRESH.ADD(
name => '"ABC"."ABC_GRP_REPLC"',
list => '"ABC"."ABC_V_DIRCT_TERRT_GENRL"',
lax => TRUE);
END;
/
- Exécuter la job
exec DBMS_JOB.RUN(job => 372);
J'avais remarqué que c'était une job (DBMS_JOB) qui exécutait un rafraichissement de vues matérialisées via un groupe de rafraichissement. Voici le code exécuté par la job :
dbms_refresh.refresh('"ABC"."ABC_GRP_REPLC"');
La job plantait et elle s'exécutait de nouveau pour effectuer une reprise automatique. Je l’ai donc interrompu, le temps de trouver la cause exacte.
Pour débuter, j’ai tenté de rafraichir les vues, à tour de rôle, pour finalement rencontrer cette erreur lors du rafraichissement manuelle d'une d'entre-elle :
ABC@ORCL> exec dbms_mview.refresh('ABC.ABC_V_DIRCT_TERRT_GENRL','C');
ERROR:
ORA-03114: pas connecté à ORACLE
BEGIN dbms_mview.refresh('ABC.ABC_V_DIRCT_TERRT_GENRL','C'); END;
*
ERROR at line 1:
ORA-03113: fin de fichier sur canal de communication
Process ID: 0
Session ID: 412 Serial number: 3177
Suite à cette erreur rencontré dans l'outil SQL*Plus, j’ai consulté le fichier « alertSID.log » de la base de données et, j’ai trouvé cette erreur :
ORA-07445: exception encountered: core dump [qcdlgcd()+116] [SIGSEGV] [Address not mapped to object] [0x000000037] [] []
Après avoir faire quelques recherches, je suis tombé sur la note 459323.1 du site Oracle Metalink qui explique ce problème. La cause provient de l’énoncé SQL qui constitue la vue matérialisée. Cet énoncé est invalide. Elle fait référence à une colonne qui n’existe plus. Pour résoudre ce problème, on doit détruire et recréer la vue matérialisée.
Étape de résolution :
- Détruire la vue matérialisée
DROP MATERIALIZED VIEW "ABC"."ABC_V_DIRCT_TERRT_GENRL";
- Créer la vue matérialisée
CREATE MATERIALIZED VIEW "ABC"."ABC_V_DIRCT_TERRT_GENRL"
TABLESPACE "ABC_D01"
USING INDEX TABLESPACE "ABC_D01"
REFRESH FORCE AS
SELECT…
- Rétablir les droits sur la vue matérialisée
GRANT SELECT ON ABC.ABC_v_dirct_terrt_genrl TO abcpool;
- Ajouter la vue matérialisée au groupe de rafraichissement
BEGIN
DBMS_REFRESH.ADD(
name => '"ABC"."ABC_GRP_REPLC"',
list => '"ABC"."ABC_V_DIRCT_TERRT_GENRL"',
lax => TRUE);
END;
/
- Exécuter la job
exec DBMS_JOB.RUN(job => 372);
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
vendredi 13 mars 2009
Spatial : Vérifier la présence des métadonnées et index
Lorsqu'on manipule des données spatiales, des métadonnées doivent être définies et insérées dans la table "USER_SDO_GEOM_METADATA".
Pour me simplifier la vie, j'ai conçu un requête qui me permet de vérifier la présence de ces métadonnées pour chaque colonne de type spatiale. Si elle est absente, la requête ci-dessous retourne un enregistrement :
Select 'TABLE' Type_Obj,utc.TABLE_NAME, utc.COLUMN_NAME
from user_tab_columns utc,
user_tables ut
where utc.data_type = 'SDO_GEOMETRY'
and ut.table_name = utc.table_name
and not exists
(
select 'x'
from user_sdo_geom_metadata usgm
where usgm.table_name = utc.table_name
and usgm.column_name = utc.column_name
)
Union
Select 'VUE',utc.TABLE_NAME, utc.COLUMN_NAME
from user_tab_columns utc,
user_views ut
where utc.data_type = 'SDO_GEOMETRY'
and ut.view_name = utc.table_name
and not exists
(
select 'x'
from user_sdo_geom_metadata usgm
where usgm.table_name = utc.table_name
and usgm.column_name = utc.column_name
)
order by 1,2,3;
Dans la même ordre d'idée, un index de type "DOMAIN" est nécessaire pour accéder aux données spatiales d'une colonne. La requête suivante me permet de vérifier la présence d'un index sur toutes les colonnes de type spatiale pour un schéma donné :
Select *
from user_tab_columns utc,
user_tables ut
where utc.data_type = 'SDO_GEOMETRY'
and ut.table_name = utc.table_name
and not exists
(
select 'x'
from user_ind_columns uic, user_indexes ui
where uic.table_name = utc.table_name
and uic.column_name = utc.column_name
and uic.table_name = ui.table_name
and uic.index_name = ui.index_name
and ui.index_type = 'DOMAIN'
)
order by utc.table_name, utc.column_name;
Ce n'est pas des requêtes très complexes mais elles m'évitent bien des problèmes.
Pour me simplifier la vie, j'ai conçu un requête qui me permet de vérifier la présence de ces métadonnées pour chaque colonne de type spatiale. Si elle est absente, la requête ci-dessous retourne un enregistrement :
Select 'TABLE' Type_Obj,utc.TABLE_NAME, utc.COLUMN_NAME
from user_tab_columns utc,
user_tables ut
where utc.data_type = 'SDO_GEOMETRY'
and ut.table_name = utc.table_name
and not exists
(
select 'x'
from user_sdo_geom_metadata usgm
where usgm.table_name = utc.table_name
and usgm.column_name = utc.column_name
)
Union
Select 'VUE',utc.TABLE_NAME, utc.COLUMN_NAME
from user_tab_columns utc,
user_views ut
where utc.data_type = 'SDO_GEOMETRY'
and ut.view_name = utc.table_name
and not exists
(
select 'x'
from user_sdo_geom_metadata usgm
where usgm.table_name = utc.table_name
and usgm.column_name = utc.column_name
)
order by 1,2,3;
Dans la même ordre d'idée, un index de type "DOMAIN" est nécessaire pour accéder aux données spatiales d'une colonne. La requête suivante me permet de vérifier la présence d'un index sur toutes les colonnes de type spatiale pour un schéma donné :
Select *
from user_tab_columns utc,
user_tables ut
where utc.data_type = 'SDO_GEOMETRY'
and ut.table_name = utc.table_name
and not exists
(
select 'x'
from user_ind_columns uic, user_indexes ui
where uic.table_name = utc.table_name
and uic.column_name = utc.column_name
and uic.table_name = ui.table_name
and uic.index_name = ui.index_name
and ui.index_type = 'DOMAIN'
)
order by utc.table_name, utc.column_name;
Ce n'est pas des requêtes très complexes mais elles m'évitent bien des problèmes.
jeudi 12 mars 2009
Créer une base de données à l'image d'une existante
Je devais recréer (écraser) une base de données déjà existante. Pour me simplifier la vie, j'ai utilisé l'assistant de configuration de base de données.
Cet assistant me permet de générer un modèle (template) basé sur une installation. Il suffit d'exécuter cette ligne de commandes :
./dbca -silent -createTemplateFromDB -sourceDB -sysDBAUserName sys -sysDBAPassword -templateName .dbt -maintainFileLocations true
Ensuite, on doit exécuter une commande qui permettra de généréer les scripts que nous pourrons exécuter pour crééer la nouvelle base de données :
./dbca -silent -generateScripts -templateName.dbt -gdbName -scriptDest /tmp/oracle
Cet assistant me permet de générer un modèle (template) basé sur une installation. Il suffit d'exécuter cette ligne de commandes :
./dbca -silent -createTemplateFromDB -sourceDB
Ensuite, on doit exécuter une commande qui permettra de généréer les scripts que nous pourrons exécuter pour crééer la nouvelle base de données :
./dbca -silent -generateScripts -templateName
dimanche 1 mars 2009
Notification sur un tablespace... inexistant !
En testant la notification à propos de l'espace utilisé des tablespaces, je me suis trouvé à provoquer un dépassement de seuil pour recevoir un message électronique.
Le message concernait un tablespace qui consommait plus que 85% de l'espace alloué.
Après avoir constaté que ça fonctionnait correctement, j'ai détruit le tablespace dont le seuil a été dépassé.
À ma grande surprise, j'ai continué à recevoir des messages électroniques même si le tablespace a été complètement détruit !?!
J'ai alors décidé de recréer le tablespace pour voir comment ça allait se comporter. Après quelques minutes, je ne recevais plus de messages. Afin d'être complètement certain, j'ai attendu près de 24 heures avant de détruire à nouveau le tablespace.
Le message concernait un tablespace qui consommait plus que 85% de l'espace alloué.
Après avoir constaté que ça fonctionnait correctement, j'ai détruit le tablespace dont le seuil a été dépassé.
À ma grande surprise, j'ai continué à recevoir des messages électroniques même si le tablespace a été complètement détruit !?!
J'ai alors décidé de recréer le tablespace pour voir comment ça allait se comporter. Après quelques minutes, je ne recevais plus de messages. Afin d'être complètement certain, j'ai attendu près de 24 heures avant de détruire à nouveau le tablespace.
S'abonner à :
Messages (Atom)