|
Publicité ' | |||||||||||||||||||||||
|
|
#1 | ||
|
Invité de passage
![]() Inscription : septembre 2007 Messages : 5 ![]() |
Bonjour,
Nous alimentons quotidiennement un datawarehouse. Nous étions avant en 9i et optimizer 8.1.7 et utilisions : Nous sommes passés en 10g optimizer par défaut de 10g et utilisons : Code :
dbms_stats.gather_table_stats(ownname=>xxx,tabname=>xxx,cascade=>true); ![]() Quelqu'un aurait-il un équivalent plus performant à me proposer ? J'ai essayé avec les options : Code :
Merci bien avance. |
||
|
|
00
|
|
|
#2 |
![]() ![]() Inscription : janvier 2004 Messages : 15 861 ![]() |
quel perfs sont dégradées ? Celles des requêtes ou celle du calcul des stats ?
|
|
|
00
|
|
|
#3 |
|
Invité de passage
![]() Inscription : septembre 2007 Messages : 5 ![]() |
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. |
|
|
00
|
|
|
#4 |
![]() ![]() Inscription : janvier 2004 Messages : 15 861 ![]() |
essaye de mettre en place le monitoring pour ne calculer les stats que si bcp de données ont bougé
|
|
|
00
|
|
|
#5 |
|
Expert Confirmé
![]() Inscription : septembre 2004 Messages : 2 942 ![]() |
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 ! |
|
|
00
|
|
|
#6 |
|
Invité de passage
![]() Inscription : septembre 2007 Messages : 5 ![]() |
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. |
|
|
00
|
Copyright © 2000-2012 - www.developpez.com