Administration - Opérations longues

Bonjour,

Lors de la création d'un index (ou de sa reconstruction) sur une table à forte volumétrie, il peut être interessant ne serait ce que pour savoir si on a le temps d'entamer une sieste de savoir on l'on se situe par rapport à l'opération en cours.
Il existe pour cela une vue système qui peut nous aider. A savoir : v$session_longops

Un petit desc sur la vue, vous donnera l'ensemble des colonnes qui pour la plupart parlent d'elle même.
Je vais en citer quelques unes

- SQL_ID pour identifier la requête longue en question
- START_TIME pour indentifier l'heure de début d'execution
- ELAPSED_TIME pour identifier le temps déjà écoulé.
- MESSAGE pour connaitre l'action en cours

et bien sur TIME_REMAINING pour avoir une idée de combien temps il reste pour l'opération en cours...
Il sera également possible bien sur d'idenitfier la session effectuant l'opération longue via les colonnes SID et SERIAL#
Une requête assez simple du type nous donnera donc des informations importantes

---

SELECT Message,Time_Remaining FROM V$session_longops
WHERE Time_Remaining>0;

---

exemple:



Le resultat suivant nous indique que l'opération en cours est un "Sort Output", que le traitement à parcouru 260822 blocs sur 462733 et qu'il reste environ 527 secondes avant la fin du traitement.

Attention : à une instruction SQL ne corresponds pas forcement une et une seule opération.... La création d'un index est constitué des plusieurs actions... Mais cela fera l'objet d'un autre post.

Dans l'exemple, j'ai parlé de création d'index, mais il peut bien sur s'agir d'autres opérations.....

LAO.

Comments

[siouat]

Merci pour votre réponse.
Ma base n'était plus en archivelog. J'utilise une VM de 1Go de ram avec 3 bases d'installées. La base servant de test pour la création de la table partitionnée comporte 92M de SGA et 24M de pga. Il y a pas d'antivirus d'installé sur la VM.
Reponse_1_P n'a jamais pu être crée et le Time_remaining n'arrêtait pas de croître. La VM finit par se figer. J'ai tout arrêté pour l'instant...

[LAO]

Bonjour,

Pour créer la table, et surtout la remplir, vous avez utilisé quel article ? Car j'ai écris un premier article, avec un remplissage "à la sauvage", et par la suite dans le cadre d'un article sur
les performances, j'ai utilisé la syntaxe "for all". http://www.lao-dba.com/article-24228696.html
Dans le premier cas, ca avait pris plusieurs heures, et je crois même que ca avait finit par partir en vrille. Dans l'autre cas (forall) cela n'avait pris qu'une heure.
LAO.

[siouat]

Merci encore pour vos articles.

"Pendant que j'ai lancé le script de creation des tables partionnées(range+hash) reponse_1_P,
j'ai cherché à savoir combien de temps est nécessaire ou reste t-il pour cette création.
A ma grande surprise, le temps restant va en augmentant...! Curieux non ? Comment l'expliquer ?
Merci.

TIME_REMAINING
--------------
Table Scan: LAO.REPONSE_1: 3776 out of 64174 Blocks done
96643

TIME_REMAINING
--------------
Table Scan: LAO.REPONSE_1: 3976 out of 64174 Blocks done
101122

TIME_REMAINING
--------------
Table Scan: LAO.REPONSE_1: 3984 out of 64174 Blocks done
101284

TIME_REMAINING
--------------
Table Scan: LAO.REPONSE_1: 4454 out of 64174 Blocks done
111771

TIME_REMAINING
--------------
Table Scan: LAO.REPONSE_1: 4527 out of 64174 Blocks done
112930

[LAO]

Bonjour,

Curieux ! oui et non. Lorsque l'on copie un répertoire contenant des milliers de fichiers, windows effectue un estimation qui peut également varier. On peut supposer qu'Oracle effectue également
une estimation. Après il va de soit que pendant cette étape, si vous utiliser votre PC pour effectuer autre chose (web, manipulations Oracle,...) voir que votre pc lance un scan (antivirus),... La
création des tables avec une volumétrie conséquente va entrainer énormément d'accès IO (en écriture). Et par conséquent tout ce qui effectuera des accès disques en même temps que la création de la
table ralentira le process. J'espère que vous n'aviez pas laissé votre base en archivelog ?

LAO.