Discussion :

[Le-DOC]

Bonjour,

Je suis entrain de m'entrainer sur le Tuning Oracle, et je m'attaque a un gros poisson en ce moment.
Un rechargement de data-warehouse complet qui commence a durer un moment.

Pourriez vous m'aider a interpréter ce rapport statpack ?

Merci

[Heaven93]

bonsoir,
je vais vous poser les questions d'usage;
premier regard : quels sont les changements qui ont précédé la dégradation?
depuis quand avez-vous migré en 11g? le volume de direct reads est important
le problème sur la procédure Update_Gl_Amounts_Po est-il récent?
dégradation subite?
changement sur le serveur lui même?
fnd_stats tourne-t-il quand il faut? (là des stats ont été calculées pendant le snapshot ce qui peut correspondre à la fenêtre de maintenance normale mais c'est mieux après le batch ou avant s'il y a eu beaucoup d'updates pendant la journée)
les temps de lecture sont mauvais sur pas mal de tablespaces. des changements à ce niveau?

[pachot]

Bonjour,

Code :

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

1
2
3
4
5
6
 
Top 5 Timed Events                                                    Avg %Total
~~~~~~~~~~~~~~~~~~                                                   wait   Call
Event                                            Waits    Time (s)   (ms)   Time
----------------------------------------- ------------ ----------- ------ ------
DBWR slave I/O                               5,454,184      30,135      6   34.2

Code :

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

1
2
3
4
5
6
7
8
 
init.ora Parameters  DB/Inst: DWBIP/DWBIP  Snaps: 12261-12289
 
 
                                                                  End value
Parameter Name                Begin value                       (if different)
----------------------------- --------------------------------- --------------
dbwr_io_slaves                4

Y-a-t-il un raison pour utiliser dbwr_io_slaves=4 ?

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
 
                                                     CPU      Elapsd     Old
  Buffer Gets    Executions  Gets per Exec  %Total Time (s)  Time (s) Hash Value
--------------- ------------ -------------- ------ -------- --------- ----------
 
 
     57,415,771           65      883,319.6   36.3   803.35   5493.92 3674655091
Module: JDBC Thin Client
UPDATE WC_GL_AMOUNTS SET NUM_COMMANDE = :B7 ,PO_DISTRIBUTION_ID
= :B6 ,PO_NUM_LINE = :B5 ,PRODUCT_WID = :B4 ,PURCH_RQSTN_ITEM =
:B3 ,PURCH_RQSTN_NUM = :B2 ,ID_LINE_MARCHE = :B1 WHERE JE_HEADER
_ID = :B9 AND JE_LINE_NUM = :B8
 
 
     22,674,726           29      781,887.1   14.3   253.10   1803.01  383539334
Module: JDBC Thin Client
UPDATE WC_GL_AMOUNTS SET PO_DISTRIBUTION_ID = TO_NUMBER(:B7 ) ,N
UM_COMMANDE = :B6 ,PO_NUM_LINE = :B5 ,PRODUCT_WID = :B4 ,PURCH_R
QSTN_ITEM = :B3 ,PURCH_RQSTN_NUM = :B2 ,ID_LINE_MARCHE = :B1 WHE
RE JE_HEADER_ID = :B9 AND JE_LINE_NUM = :B8

Il faudrait voir ces 2 update qui lisent 1 million de blocs par exécution. Voir leur plan d'exécution par exemple.
Cordialement,
Franck.

[Le-DOC]

Bonjour, et merci pour ces réponces.

@Heaven93 > Le temps de chargement a toujours été long, mais il est de plus en plus au vue de la quantité de donnée qui ne cesse d'augmenter (j'ai toujours pas trouvé un moyen de stopper l'horloge )
L'environnement a toujours été en 11g
pas de changements de serveur ou autre (ce sont des VM)
le FND_STAT a l'air de tourner pendant ce chargement (update, rebuild des indexes, ect... en gros, il y a plus de 400 traitements pendant ce chargement)
Update_Gl_Amounts_Po --> Livraison d'une nouvelle version de notre presta, aucun changement de temps...


@pachot > dbwr_io_slaves=4 a été préconisé par le DBA de notre prestataire, et cela nous a fait gagner 15% de temps de chargement
concernant les 2 updates, je ne me rapelle plus comment voir le plan d'execution d'une requete distante, ou déja executée ?

Merci

[mnitu]

Le traitement peut prendre plus du temps simplement parce qu’il traite de plus en plus des données.

L’évènement en TOP 5 DBWR Slave I/O semble à être de type class Iddle donc pourrait être ignoré. A priori votre système d’exploitation ne supporte pas les I/O en mode asynchrone.

Je ne pense pas que vous pouvez vous en sortir sans une compréhension de ce qui se passe dans le traitement exécuté par la procédure en question.

[Le-DOC]

Bonjour,

En effet, avant que je ne modifie le parametre dbwr_io_slaves, j'avais bcp de wait sur l'event: db file async I/O submit

Quant vous dites: A priori votre système d’exploitation ne supporte pas les I/O en mode asynchrone.
j'utilise une Red Hat EL 5.5 en 64bits.

Est que c'est la redhat qui ne gere pas ce type d'écriture, ou la VM qui est derriere ?
Est t'il possible de modifier ca, en changeant la configuration de la VM, ou en faisant une MAJ de l'OS ?

[mnitu]

DBWR_IO_SLAVES is intended for scenarios where you cannot use multiple DB_WRITER_PROCESSES (for example, where you have a single CPU). I/O slaves are also useful when asynchronous I/O is not available, because the multiple I/O slaves simulate nonblocking, asynchronous requests by freeing DBWR to continue identifying blocks in the cache to be written. Asynchronous I/O at the operating system level, if you have it, is generally preferred.

...
Using multiple DBWRs parallelizes the gathering and writing of buffers. Therefore, multiple DBWn processes should deliver more throughput than one DBWR process with the same number of I/O slaves. For this reason, the use of I/O slaves has been deprecated in favor of multiple DBWR processes. I/O slaves should only be used if multiple DBWR processes cannot be configured.

A compréhension, avoir multiple DBWR est préférable que d’utiliser un seul DBWR avec multiple esclaves. Ce scénario existe juste come une solution de contournement quand le système ne supporte pas des E/S asynchrones.

Mais comme je disais je ne pense pas que vous pouvez optimiser ce traitement sans analyser/comprendre ce qui fait la procédure en question.
Finalement c'est cette procédure qui modifie beaucoup de blocks des données ce qui induit le travail pour le DBWR.

[Le-DOC]

Concernant le plan d’exécution, j'ai réussi à choper ça sur un autre environnement.

SQL Text 
--------------------------------------------------------------------------------
UPDATE WC_GL_AMOUNTS
 SET PO_DISTRIBUTION_ID = TO_NUMBER(:B7 ) ,NUM_COMMANDE = :B6 ,PO_NUM_LINE = :B5 ,PRODUCT_WID = :B4 ,PURCH_RQSTN_ITEM = :B3 ,PURCH_RQSTN_NUM = :B2 ,ID_LINE_MARCHE = :B1 
WHERE JE_HEADER_ID = :B9 AND JE_LINE_NUM = :B8 

Global Information 
--------------------------------------------------------------------------------
Status : DONE 
Instance ID : 1 
Session : BAW (194:22309) 
SQL ID  : f4yz3myyjrpvt 
SQL Execution ID : 16777216 
Execution Started : 09/12/2014 16:26:56 
First Refresh Time : 09/12/2014 16:27:03 
Last Refresh Time : 09/12/2014 16:51:07 
Duration : 1451s 
Module/Action : JDBC Thin Client/- 
Service : SYS$USERS 
Program : JDBC Thin Client 
PLSQL Entry Ids (Object/Subprogram) : 567960,1 
PLSQL Current Ids (Object/Subprogram) : 567960,1 

Binds Name Position Type Value 
:B9 8 NUMBER 1061779 
:B8 9 NUMBER 340 

Elapsed Time(s)  Cpu Time(s)  IO Waits(s)  Other Waits(s)  Buffer Gets  Read Reqs  Read Bytes  
1451 				65 			1356 			29 				3M 		233K 		4GB 


SQL Plan Monitoring Details (Plan Hash Value=3089646069) 
id	 Operation 		Name 		Rows (Estim)  		Cost 		Time Active(s)  	Start Active  Execs 	Rows (Actual)  Read Reqs  Read Bytes  Activity (%)  Activity Detail (# samples)  
0 UPDATE STATEMENT       30000       
1 . UPDATE  WC_GL_AMOUNTS   1451 +1 30000  0  231K 4GB 99.59 free buffer waits (30) write complete waits (18) Cpu (53) db file parallel read (53) db file sequential read (1287)  
2 .. INDEX RANGE SCAN  WC_GL_AMOUNTS_FK4 1  3  1445 +7 30000  192K 1337  21MB 0.41 Cpu (1) db file sequential read (5)  

Désolé pour la mise en page

[Le-DOC]

Rebonjour,

Apparement, cette procédure fait simplement du select, et de l'update.

J'ai tenté de mettre les environnements de production et de recette aux meme caracteristiques (mémoire, fichier de parametre, VM, physique)
Mais les temps de chargements sont du simple au double.
J'ai tiré 2 rapports statpack, et j'aurais besoin de votre avis