Résultat d'une vue qui diffère suivant ordre de tri

[jjjjjggggg]

Bonjour,

Je suis sur Oracle 11 et travaille avec TOAD, j'ai un problème pour lequel je ne vois aucune explication rationnelle :

J'ai une vue v1 (vue standard du type create view as subquery) qui associe une clef c1 à un clob contenant du XML à partir d'une table t1 (identifiée par c1) et d'une autre vue générant du XML.

Dans une procédure stockée, j'essaie de lire le contenu de cette vue v1 et de l'ajouter dans une table physique t2.
Pour ce faire :
- je fais d'abord un select bulk collect des clés d'une table t0 (table mère de t1 identifiée elle-aussi par c1 et qui contient plus d'enregistrement que t1) dans un type table indexé par binary_integer.
- je fais ensuite à l'intérieur d'un forall un insert dans t2 à partir d'un select de v1 en me basant sur les clef stockées dans mon type table.

Ma procédure stockée insère toujours le même clob XML dans la table t2 (la variable utilisée dans le forall elle varie bien).

C'est comme si ma vue s'exécutait une première fois, mettait son résultat en cache puis, lors des select suivant sur d'autres clefs, prendrait la valeur en cache plutôt que de se rafraichir...

J'ai fait la requête suivante pour voir le paramétrage de mon cache et, normalement, oracle ne devrait pas l'utiliser dans la mesure ou je ne lui demande pas.

Code :

1
2
3
SELECT name, value, isdefault
FROM v$parameter
WHERE name LIKE 'result_cache%';

ça me dit : result_cache_mode MANUAL

Dans le doute, j'ai quand même essayé de rajouter des hints /*+ NO_RESULT_CACHE */ dans tous les select impliqués mais ça ne fonctionne pas mieux.

Est-ce que ça parle à quelqu'un, parce que là je sèche ?


Merci infiniment pour votre aide

EDIT : Message initial mis à jour

[Waldar]

La description est complète mais demande un peu trop de temps à analyser.

Pouvez-vous publier un comportement similaire avec des tables t1 t2 t3 et quatre / cinq lignes dedans ?

[jjjjjggggg]

Je met un exemple

table : t0
Colonne : cle | colonne quelconque 1 | col qcq 2
------------------------------------------------
a | toto | tutu
b | tata | titi
c | tete | tyty


table : t1
Colonne : cle | colonne quelconque 1 | col qcq 2
------------------------------------------------
a | toto | tutu
b | tata | titi

vue : v1
Colonne : cle | XML
------------------------------------------------
a | <toto><tutu/></toto>
b | <tata><titi/></tata>


Avec tri descendant dans la procédure stockée
t2
Colonne : cle | XML
------------------------------------------------
a | <toto><tutu/></toto>
b | <toto><tutu/></toto>
c |

Avec tri ascendantdans la procédure stockée
t2
Colonne : cle | XML
------------------------------------------------
c |
b |
a |

[orafrance]

Envoyé par jjjjjggggg

- je fais d'abord un select bulk collect des clés d'une table t0 (table mère de t1 identifiée elle-aussi par c1 et qui contient plus d'enregistrement que t1) dans un type table indexé par binary_integer.
- je fais ensuite à l'intérieur d'un forall un insert dans t2 à partir d'un select de v1 en me basant sur les clef stockées dans mon type table.

Et pourquoi pas INSERT INTO t2 SELECT * FROM t0 ?

[jjjjjggggg]

J'ai volontairement simplifié l'explication, la vue v1 fait des modifs sur les colonnes de to : calculs, renommage de colonne, encapsulation dans une seule chaine XML contenue dans un clob. Et en fait il n'y a pas qu'une seule table t0 : il y en a 4, 4 tables t1 et 4 vues v1. La procédure stockée fait bien un insert de select, select qui lui même est décomposé en 4 select distincts sur les 4 vues v1.


Il y a beaucoup de volume donc j'ai suivi les conseils du fameux Don Burleson pour optimiser mes inserts : select des clefs en bulk collect + forall d'insert avec hint append et table en nologging

cf http://www.dba-oracle.com/t_optimize...erformance.htm

[mnitu]

Envoyé par jjjjjggggg

...Il y a beaucoup de volume donc j'ai suivi les conseils du fameux Don Burleson pour optimiser mes inserts : select des clefs en bulk collect + forall d'insert avec hint append et table en nologging
...

Pas vraiment fiable Don Burleston. Le "insert into ...' proposé par orafrance peut aussi être exécuté avec le hint append, etc.