Discussion :

[Pomalaix]

Bonjour à tous

Disons qu'on fait un update sur une table, qui dure 30 secondes.
Cet update touche de multiples colonnes indexées, donc les index correspondants sont mis à jour.

Je cherche à déterminer le temps passé à mettre à jour les index, pour pouvoir dire :
temps total d'update de la table : 30 secondes
dont mise à jour des index : 20 secondes

Bien entendu, je cherche une méthode plus subtile que de tester avec et sans index !

Avez-vous une idée, parce que moi je sèche désespérément.

Merci d'avance.

[pachot]

Bonjour,

On peut partir du principe que le temps est proportionnel au nombre de blocks lus parce que sinon il y a trop de paramètres (cache, organisation dans le bloc, etc...)

Pour chaque ligne qui modifie une colonne indexée, il faut:
- trouver l'entrée de la valeur courante dans l'index (blevel + block feuille, comme un accès par index)
- marquer l'entrée comme deleted -> génération d'undo
- trouver l'entrée de la nouvelle valeur dans l'index (blevel + block feuille, comme un accès par index)
- rajouter l'entrée dans ce bloc -> génération d'undo
- si le bloc feuille est plein (probabilité plus forte si un petit malin a cru bien faire en faisant des rebuild d'index réguliers) il y aura des splits de blocs qui peuvent amener un peu plus de blocs modifiés (et d'undo)

Donc en première approximation, un delete ou insert va rajouter 3 ou 4 logical reads. Un update, le double. A comparer avec 1 logical read si il n'y a pas d'ndex.

Cordialement,
Franck.

[Pomalaix]

Bonjour Franck

Merci pour cette réponse.
Au-delà de l'approximation théorique, je cherche à effectuer une mesure effective (ou du moins m'en approcher le plus possible).

Je n'ai pas trouvé dans un fichier de trace étendue d'informations qui me paraissent utiles à cette fin.
Peut-être quelqu'un connaît-il un "event" magique à positionner pour obtenir des données là-dessus ?

[SQLpro]

N'as tu pas dans le plan d'exécution, la possibilité d'avoir le détails des temps de chaque opération ?
En récupérant ces plans et en les traitants tu devrais avoir une estimation...

PS : j'ai pas oracle sous la main !

[pachot]

N'as tu pas dans le plan d'exécution, la possibilité d'avoir le détails des temps de chaque opération ?
En récupérant ces plans et en les traitants tu devrais avoir une estimation...

Bonjour, les plans d'exécutions ne montrent que l'accès aux données. Pas la maintenance des index, mview logs, des cascade constraints, etc.

[Mohamed.Houri]

Bonjour à tous

Disons qu'on fait un update sur une table, qui dure 30 secondes.
Cet update touche de multiples colonnes indexées, donc les index correspondants sont mis à jour.

Je cherche à déterminer le temps passé à mettre à jour les index, pour pouvoir dire :
temps total d'update de la table : 30 secondes
dont mise à jour des index : 20 secondes

Bien entendu, je cherche une méthode plus subtile que de tester avec et sans index !

Avez-vous une idée, parce que moi je sèche désespérément.

Merci d'avance.

Salut Richard,

Par pure coïncidence quelqu'un a posé la même question très récemment dans otn

https://community.oracle.com/message/14173069#14173069

Comme indiqué par Jonathan Lewis et les autres tu peux te rapprocher de la réponse en analysant le contenu de la trace 10046. ASH (Active Session History) peut également donner un ordre d'idée en suivant l'object (l'index) dans les différents "sampling" faits par Oracle durant l'update.

Bien Cordialement
Mohamed Houri

[Pomalaix]

Par pure coïncidence ...

Mince, je suis démasqué !

Salut Mohamed

Je n'ai pas encore exploité les réponses données sur OTN, je les ai juste parcourues rapidement pour l'instant.

Si on accepte l'approximation que le gros du temps de mise à jour de l'index est consommé lors des E/S physiques, alors la suggestion de Jonathan Lewis de les rechercher dans une trace étendue est une voie intéressante.
En revanche, si tout est en cache de bout en bout, peut-être que dans les faits, on passe bien 70% du temps à mettre à jour les index, mais on ne détectera rien.

Je note aussi avec intérêt la piste d'ASH.
On aura la même restriction qu'avec la méthode précédente, et cette voie aura à mon avis une portée plus macroscopique que la précédente, étant donné la granularité grossière (toutes proportions gardées) de l'échantillonnage ASH.
Si je m'intéresse à une exécution individuelle, c'est bien entendu la trace étendue qui sera pertinente. Si je veux une vision plus générale, comportementale, ASH me paraît pas mal.

Juste pour la rigolade, j'ai aussi ouvert un ticket auprès du support Oracle. Fidèles à eux-mêmes, ils m'ont juste dit qu'il n'y avait pas moyen d'obtenir l'information que je recherchais.
Heureusement qu'il y a la communauté !

Merci à tous, et à suivre !