Discussion :

[lulu14]

Bonjour,
Nous alimentons quotidiennement un datawarehouse.
Nous étions avant en 9i et optimizer 8.1.7 et utilisions :

Code :

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

analyze table xxx estimate statistics

Nous sommes passés en 10g optimizer par défaut de 10g et utilisons :

Code :

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

dbms_stats.gather_table_stats(ownname=>xxx,tabname=>xxx,cascade=>true);

Les performances sont dégradées
Quelqu'un aurait-il un équivalent plus performant à me proposer ?
J'ai essayé avec les options :

Code :

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

1
2
estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE,
DEGREE => DBMS_STATS.AUTO_DEGREE

et j'ai gagné 30% mais je me demande si le résultat attendu est le même...
Merci bien avance.

[orafrance]

quel perfs sont dégradées ? Celles des requêtes ou celle du calcul des stats ?

[lulu14]

Dans notre traitement quotidien d'alimentation du dwh, nous analisons les tables qui sont relues par la suite dans le traitement (dans le cas d'un premier chargement, si les stats sont à zéros alors que l'on a inséré 1 million de lignes avant dans une table que l'on relit = notre traitement se bloque).
C'est dans le traitement que les perfs sont dégradées, le calcul des stats est trop long.

[orafrance]

essaye de mettre en place le monitoring pour ne calculer les stats que si bcp de données ont bougé

[LeoAnderson]

est-ce que vous avez bien désactivé le scheduled jobs natif 10g ?
(ça sert à rien que vous calculiez les stats d'une façon si derrière la tâche Oracle les recalcule différement !)

Mais si c'est le calcul des stats qui est trop long... calculez-les moins souvent !

[lulu14]

Merci pour les réponses.
Le monitoring au niveau table est déjà en place et le scheduler est bien disable.
J'affine mes recherches sur les options du gather_table_stats.