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 ?