Discussion :

[saysay]

Bonjour,

Nous sommes en train d'effectuer une migration de 9i vers 10g.
Celle-ci s'est à peu près bien passée.
Mais un problème persiste: le calcul des stats.
En effet, celui-ci est devenu très (très) long (pas loin de 9 fois plus... On passe de 30 min à 4h30 )
Les tables analysées sont partitionnées (voir sous-partitionnées).
Tous les soir, pour chaque table, on lance une analyse sur la partition (et/ou sous-partition) de la journée avec la commande suivante:

Code :

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

exec DBMS_STATS.GATHER_TABLE_STATS('Mon_Shema','MaTable', 'P_MaTable_20070716', estimate_percent => 75, granularity => 'PARTITION',cascade => TRUE);

Avez-vous eu vent de ce type de problèmes?
Cela peut-il être du à une mauvaise installation ?

avec DBMS_STAT, il y a une notion de 'Degree of parallelism', est-ce que ça peut être utile?


J'avoue que mes recherches ont été assez infructueuse (à part un ou deux lien sur le metalink oracle pour lequel je n'ai pas de compte )

En tout cas, merci d'avance si vous avez une petite idée sur ce point qui commence un peu à devenir critique...

Nb: Mon serveur de test n'est pas tout à fait iso prod (moins de ram). Sur ce serveur, l'analyse sur 9i dure 2 heures. Cela peut-il expliquer une telle différence?

[LeoAnderson]

Estimate_Percent >= 50 <==> COMPUTE !
pourquoi tout analyser et pas uniquement ce qui en a besoin (cf GATHER_STALE)

Le scheduled_job par défaut n'entre-t-il pas en concurrence avec vos procédures ?

en même temps, vu que vous n'avez pas de compte, cela signifie donc que vous êtes simplement en train de tester et donc, vous vous en moquez des perfs, non ?

[orafrance]

et la puissance machine et les disques sont-ils aussi performant qu'en prod ?

[saysay]

>> LeoAnderson
Je suis sur que les partitions que j'analyse on bougée de plus de 10% (pour être exact, elle sont vide en début de journée et contennent à peu près 2,5 millions de lignes à minuit)
Les partitions antérieures ne bougent plus (pas d'insert, ni delete ni update) elles sont juste dropées au bout d'un certain temps et donc n'ont pas besoins d'être analysées de nouveau (me tromp-je?)

Mince, concernant le "Estimate_Percent >= 50 <==> COMPUTE", je n'en avais pas conscience... C'est sûr?

>> orafrance
Pas tout à fait, on nous avait promis de l'iso prod, mais bon... (moins de processeurs, moins de ram et pareil en disque)
Par contre, l'analyse des stats sur ce serveur avec une version 9i d'oracle dure vers les 1h30 alors que sur 10g elle dure 4h30...
Logiquement, on devrait retrouver plus ou moins les même temps, non?

[orafrance]

la stratégie de collecte a été revu dans la 10g. Notamment, je crois que les histogrammes sont plus exhaustifs. Ceci peut expliquer le comportement de la 10g

[saysay]

Aïe!
Mais ça m'arrange pas du tout ça!
Mais bon, je t'avoue qu'au vu des différences de temps, je pense plutôt pour une bêtise de ma part...