[10.2]Allocation d'espace TEMP lors d'un snapshot refresh

Bonjour,
A des fins de statistiques, j'utilise un snapshot en mode "complete refresh", sur une base de test en 10.2
La vue servant à générer ce snapshot utilise des jointure externes sur d'autres vues (elles-memes utilisant des fonctions de regoupement sur une table de plusieurs millions de lignes).
La regénération de ce snapshot entraine une erreur ORA-01652 (impossible d'étendre le segment temporaire), le tablespace temporaire (de type tempfile) augmentant jusqu'à saturation (32 Go).
Sur une base 8i -sur un seveur différent-, la régénération du même snapshot, avec les mêmes données, s'effectue sans problème, et avec un tablespace temporaire plus petit (4 Go).
Naturellement, ajouter des tempfiles pour éviter une erreur d'allocation d'espace temporaire ne constitue pas une solution.
J'aimerais comprendre pourquoi un traitement qui s'exécute correctement en 8i plante en 10g.
J'ignore par où commencer mes investigations (analyser le plan d'execution ?).
Au pire, j'envisage de remplacer ce snapshot par une table, puis de faire un truncate suivi d'un insert pour rafraichir les données.
Merci à tous de votre aide.

Est-ce qu'il y a des indexes supplémentaires dans la 10g ou plus de volume ? Quel est le paramétres SORT_AREA_SIZE ou PGA_AGGREGATE_TARGET ?

Bravo pour la rapidité de la réponse ;)
La 10g contient uniquement un schéma de la 8i (intégré via un export/import), orienté "DWH" . Il n'y a pas de transactions sur la 10g, il s'agit uniquement d'évaluer le gain de performances lors de la génération de statistiques.
Sur les 2 bases, le parametre SORT_AREA_SIZE est de 64 Ko.
Sur la 10g, le parametre PGA_AGGREGATE_TARGET est de 480 Mo, l'allocation mémoire est gérée en mode automatique.

étrange... c'est EXACTEMENT la même vue pour les mêmes volumes sur les 2 bases ?

Oui, EXACTEMENT la même vue, avec les mêmes volumes de données.
Ce qui est plus curieux, c'est que seul ce snapshot plante.
D'autres, plus complexes et générant beaucoup plus de lignes s'exécutent sans problème -et plus rapidement- sur la 10g.
Je soupçonnais des statistiques manquantes, mais le traitement automatique de collecte des statistiques est pourtant bien opérationnel sur la 10g.
D'où mon désarroi...

tu as essayé de le recréer ?

Oui, j'ai fait détruit ce snapshot, puis je l'ai recréé à l'identique
(en mode complete refresh), avec les mêmes index.
Même erreur ORA-01652 lors du rafraichissement des données.
Pour le rafraichir, j'appelle dans une procédure le package DBMS_SNAPSHOT.REFRESH ([snapshot_name]);

c'est un snapshot ou une vue materialisée ?

Essaye :

Code:

---

DBMS_MVIEW.REFRESH ([snapshot_name]);

---

Ce n'est pas possible de faire du FAST ?

DBMS_MVIEW et DBMS_SNAPSHOT sont interchangeables (pour cause de compatibilité ascendante).
Les données ont besoin d'être recalculées depuis l'origine.
De toutes façons, avant de faire un fast refresh, il est nécessaire de faire au préalable un "refresh complete".
Le plus curieux : je viens de tester un CTAS (create table toto as (select * from [la vue qui sert à générer le snapshot])); mais sans aucun index sur cette table.
Et bien évidemment, les 220K lignes de données ont été intégrées dans cette table en quelques minutes, sans faire exploser le tablespace temporaire (1 Go).
AMHA, il s'agit donc d'un pb spécifique au processus de regénération du snapshot...

Fait un CREATE MATERIALIZED VIEW ON PREBUILD dans se cas, ça permet de "transformer" la table en vue matérialisée donc pas de REFRESH COMPLETE ;)