Depuis quelques temps, j'effectue des essais de performance sur des bases de données 10.2.0.4 et 10.2.0.3. Je compare plusieurs résultats obtenus suite à l'exécution de requêtes SQL et des blocs PL/SQL.
Malheureusement, les résultats démontrent que 10.2.0.4.0 est plus lent dans plusieurs situations... je trouve ça très dommage car j'en ai besoin pour utiliser certaines fonctionnalités de cette version.
Aujourd'hui, un de mes collègues m'a donné un coup de main et il m'a demandé si j'avais refait le calcul des statistiques système sur la base de données suite à la migration de celle-ci à 10.2.0.4. Je lui ai répondu que oui mais, pour éliminer tout doute, je lui ai dit qu'il pouvait les recalculer et refaire des essais.
Suite à cette mise à jour des statistiques, le temps réponse des requêtes figurant dans mes essais de performance ont diminué magistralement. Certaines s'exécutent en 2 à 3 fois moins de temps. Je n'y comprennait rien !?!
J'ai alors demandé à mon collègue de me montrer la commande qu'il avait utilisée pour refaire les statistiques système. Je constatait qu'il exécutait la même commande que moi mais sans aucun paramètre... donc, il utilisait les valeurs par défaut de ceux-ci. Le mode de collecte par défaut est "NOWORKLOAD".
exec dbms_stats.gather_system_stats;
Quand j'effectuais une collecte, je la planifiais pour qu'elle s'échelonne sur une période significative de charge de travail pour avoir des statisitques représentatives... finalement pas sûre que ça valait le coup de me cassé la tête à exécuter, par exemple, ceci :
exec dbms_stats.gather_system_stats(gathering_mode=>'START', stattab=>'stats', statid=>'stats', statown=>'SYS');
À l'avenir, je vérifierai le mode simple (sans aucun paramètre) et le mode avancé pour la collecte des statistiques système.
Aucun commentaire:
Publier un commentaire