Discussion :

[wakan]

Bonjour,
J'ai une vue matérialisé MV1 définie par un group by sur T1

Code :

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

1
2
3
4
5
6
7
8
9
10
11
CREATE MATERIALIZED VIEW MV1 
BUILD IMMEDIATE
REFRESH COMPLETE ON DEMAND
WITH PRIMARY KEY
AS 
  SELECT XXXXXX, count(*) FROM T1
   WHERE     PLOP=12
GROUP BY XXXXXX;
CREATE OR REPLACE PUBLIC SYNONYM DTW_MV1 FOR MV1;
 
CREATE INDEX PLOP ON MV1 (PLOP);

Refresh PL/SQL :

Code :

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

dbms_mview.REFRESH('DTW_.' || p_NOM_SNAP);

Il y a de nombreux delete et insert sur T1. Donc certainement pendant le refresh.
Temps de refresh, plus de 5H.
Nbre de lignes de T1 environ 10 millions.

Le refresh fonctionne 1 fois sur 10 erreur :

L'enregistrement que vous essayez de modifier ne correspond plus à
la version existante.
Un autre utilisateur a effectué des modifications depuis votre dernière sélection.

Je me demande si cela correspond à

The Selected Record Has Been Modified by Another User since it was retrieved

Est ce qu'il peut y avoir des solutions existantes pour résoudre le problème ?
Je m'en doute mais pouvez vous me confirmer le fait que les insert et delete fond planter le refresh ?
Est ce qu'il ne faudrait pas mettre des locks sur T1 pendant le refresh ?

Merci d'avance de votre aide.

[skuatamad]

Pouvez-vous fournir le code d'erreur oracle.

Je m'en doute mais pouvez vous me confirmer le fait que les insert et delete fond planter le refresh ?

Pour moi le risque est surtout de se prendre un snapshot too old lors de la sélection (paramétrez votre UNDO RETENTION).

Faites une trace pour identifier où vous perdez du temps, est-ce dans la sélection ou dans l'écriture ?

Si c'est dans l'écriture, vous pouvez regarder :
http://asktom.oracle.com/pls/asktom/...95500346622064
http://asktom.oracle.com/pls/asktom/...15695764787749

Par ailleurs l'option WITH PRIMARY KEY ne semble pas adaptée mais est probablement ignorée.

PS: PLOP est probablement une combinaison de colonnes, car dans l'exemple tel que présenté, l'index sur PLOP est l'index le plus inutile du monde

[wakan]

Bonjour skuatamad,
Merci pour votre réponse aussi rapide.
Les remarques sont précises et pertinentes, je vais étudier tous cela.
Les réponses rapides :

Pouvez-vous fournir le code d'erreur oracle.

Je vais essayer mais comme c'est un traitement qui tourne la nuit, et que je ne l'ais pas dans les logs, ça va être un peu dur.

un snapshot too old

Ce n'est pas très grave.

UNDO RETENTION

Je vais étudier cette piste avec attention.

Faites une trace pour identifier où vous perdez du temps

Le temps de traitement ne me dérange pas trop. C'est surtout le fait qu'il tombe trop souvent en erreur.

Par ailleurs l'option WITH PRIMARY KEY ne semble pas adaptée mais est probablement ignorée.

C'est noté merci.

PS: PLOP est probablement une combinaison de colonnes, car dans l'exemple tel que présenté, l'index sur PLOP est l'index le plus inutile du monde

Mon énoncé était ambiguë. Dans le select et le groupe by PLOP représente un ensemble de colonne. Par contre l'index est fait sur un sous ensemble de PLOP. Je penses que cet index est utile pour les requête d'interrogation sur la vue matérialisé créé.
Merci encore pour votre réponse.