Actualisation d'une vue matérialisée avec l'option "parallel"

En tentant de mettre en place une tâche via Oracle Scheduler qui effectue le rafraichissement d'un groupe de vues matérialisées, j'obtenais une erreur qui sentait le "service request" à plein nez !

ORA-07445: exception encountered: core dump [_memcpy()+264] [SIGSEGV] [ADDR:0x0] [PC:0xFFFFFFFF7C500908] [Address not mapped to object] []

Ce genre d'erreur n'augure jamais bien. Après avoir fouillé et effectué un ensemble de tests, j'ai réussi à identifier la vue matérialisée qui causait l'erreur. Elle comportait des colonnes dont le type de données est SDO_GEOMETRY (Oracle Spatial) et la source de celle-ci se trouve sur une base de données distante. Voilà, des particularités intéressantes...

Après avoir googolisé le Net de bout en bout, je me suis souvenu que la manipulation des données spatiales sont souvent capricieuses. J'ai alors réalisé qu'en enlevant les colonnes de la vue, je pouvais actualiser (refresh) la vue matérialisée avec succès.

Avec un peu de recul, je me suis dit : "Utilisons une commande simple qui n'utilisera pas des fonctionnalités qui pourrait augmenter les chances de provoquer des erreurs". La commande CREATE MATERIALIZED VIEW utilisait le parallélisme.... Hmmm... Spatial et parallélisme... Une autre belle particularité ! Essayons NOPARALLEL, juste pour voir. Eh bien, devinez quoi? L'actualisation de la vue matérialisée a fonctionné.

Dans mon cas, le parallélisme n'est vraiment pas obligatoire donc, je peut m'en passer sans problème. Par contre, comme je le disait plus tôt, il y a sûrement place à créer un SR chez Oracle pour identifier la cause.

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);

Message d'erreur qui ne veut rien dire

Lors de la création d'une vue matérialisée, je me suis cassé la noix à comprendre pourquoi je recevais un message d’erreur à propos d’un « deadlock ».

Ce message n’avait aucun rapport avec le problème. L’origine du problème se situait au niveau du format de la date (NLS Parameters) utilisé par ma session versus une valeur littérale (date) dont le format n’était pas spécifiée dans la vue accédée par l’énoncé SQL constituant la vue matérialisée.

Voici une reproduction du problème rencontré :

Morale de cette histoire : Il faut toujours spécifier un format de date à une valeur littérale !