98% de consommation CPU pour un full scan dans real-time monitoring

Bonjour
Je suis curieux de savoir comment une opération de full scan de table dans un plan d'exécution bouffe 98% de CPU(real time monitoring) ?
Qu'est ce qu'il peut y avoir comme travail pour une telle consommation ?
Pour moi un FS de table génère plutôt des IOs ...
Quelle que chose m'échappe :)
Sinon est-ce 98% de cpu est un mauvais signe ?dois-je étudier l'utilisation d'un index pour la table en question ?
Enfin le %cpu est il par rapport à la totalité de la requête ou par rapport à la CPU de toute la session voir l'instance ???
Merci les Experts ;)

Bonjour,
Un full table scan qui ne fait pas de physical read c'est qu'il est probablement appelé très souvent sur une table qui log en mémoire.
Dans SQL monitoring, les pourcentage sont calculés par rapport au temps de la requête passée en base de donnée.
Ce full table scan se trouverait-il dans une requête exàcutée très frequemment, ou dans un nested loop ?
Cordialement,
Franck.

N’importe quelle requête SQL consomme du CPU. Une requête qui fait un full table scan implique la recherche dans le buffer cache ce qui consomme de la CPU ; de même pour le parsing éventuel de la requête ou le sql récursif généré par la requête.
98% indique plutôt que tout se passe bien si la contribution dans le temps CPU du parsing ou du sql récursif ne sont pas importantes.

Citation:

---

Envoyé par pachot

Bonjour,
Un full table scan qui ne fait pas de physical read c'est qu'il est probablement appelé très souvent sur une table qui log en mémoire.
Dans SQL monitoring, les pourcentage sont calculés par rapport au temps de la requête passée en base de donnée.
Ce full table scan se trouverait-il dans une requête exàcutée très frequemment, ou dans un nested loop ?
Cordialement,
Franck.

---

Bonjour Franck ,
Il s'agit d'une requête exécutée fréquemment dans un Nested Loop.
L'ajout d'un index a résolu le problème.
Mais en général qu'est qui fait consommer beaucoup de CPU dans des opérations de FS ?

Citation:

---

Envoyé par zidane2012

Mais en général qu'est qui fait consommer beaucoup de CPU dans des opérations de FS ?

---

Full table scan ou pas, c'est lire des blocs qui consomme de la CPU. Y accéder (buffer get) et les données dans les blocs. C'est juste que quand un full scan va sur disque, la conso CPU se voit moins.

Citation:

---

Envoyé par zidane2012

...
Il s'agit d'une requête exécutée fréquemment dans un Nested Loop.
...

---

Je me demande bien qu'est-ce que cela devrait être cette bizarrerie ? Est-ce une opération du plan d'exécution exécutée dans un Nested Loop ou une requête SQL exécutée dans une boucle ?

Citation:

---

Envoyé par mnitu

Je me demande bien qu'est-ce que cela devrait être cette bizarrerie ? Est-ce une opération du plan d'exécution exécutée dans un Nested Loop ou une requête SQL exécutée dans une boucle ?

---

Désolé Mnitu je me suis mal exprimé ,il s'agit bien d'une opération du plan exécutée dans un NL.
Merci.

Dans ce cas je pense que vous devez avoir eu également un problème des statistiques incorrectes ou de calcule (estimations) des cardinalités des tables concernées par la requête. En fait Oracle ne privilégie pas des jointures NL sur des tables sans index; mais bon sans requête et pas mal des autres informations c’est plutôt un jeu de charades.