Discussion :

[orafrance]

ba en fait y'a un package principal qui appelle d'autres packages qui eux même appellent d'autres packages etc...

traque les ouvertures de curseurs... très souvent j'ai vu des curseurs ouverts pour traiter ligne à ligne ce qui peut être fait en une requête SQL. En plus, c'est souvent source d'algo qui partent en vrille

[farenheiit]

Quelle démarche je dois adopter pour optimiser ma base et mon appli?
j'ai fait la formation tuning chez Oracle, je me suis pris plein d'info dans la tête pendant une semaine (optimisation du buffer cache, de la shared pool, des tris, des ordres sql, des redo logs...) mais je n'ai pas appris de démarche.

Certains m'ont dit de commencer par statspack d'autres me disent le contraire...je comprend plus rien.

Par rapport, à mon résultat statspack on peut dire en résumé qu'il n'a ya pas de souci apparent au niveau de la configuration de la machine, et qu'il faut donc que j'optimise le code PL/SQL c'est ça?

[Tracnac]

Lequel des 2 correspond à ton traitement.

Code :

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

1
2
23:06:52 979656 oracleprism (LOCAL=NO)
01:54:20 964368 oracleprism (LOCAL=NO)

Une petite dernière et je t'embete plus (sous unix tout du moins... )

Code :

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

1
2
 
ps -efo time,stime,pid,vsz,args | grep prism | sort -r +0 | head -20

[farenheiit]

mon traitement correspond à la 1ère ligne (979656).

Code :

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

ps -efo time,stime,pid,vsz,args | grep prism | sort -r +0 | head -20

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
 
23:38:13   Feb_18 17191 979656 oracleprism (LOCAL=NO)
01:57:42   Feb_18 15124 964368 oracleprism (LOCAL=NO)
27:07   Feb_18  1884 974848 ora_lgwr_prism
23:10   Feb_18  1882 977192 ora_dbw0_prism
17:20   Feb_18  8021 963672 oracleprism (LOCAL=NO)
16:04 15:53:00  6397 967920 oracleprism (LOCAL=NO)
10:28   Feb_18  1894 970728 ora_arc0_prism
05:57   Feb_18 28184 966520 oracleprism (LOCAL=NO)
04:15   Feb_18 29088 966336 oracleprism (LOCAL=NO)
04:01   Feb_18 29090 966296 oracleprism (LOCAL=NO)
02:50   Jan_21  7014 345800 ora_pmon_prism
02:49   Jan_21  7016 345728 ora_dbw0_prism
02:30   Jan_21  7018 345216 ora_lgwr_prism
02:29   Jan_21  7020 345240 ora_ckpt_prism
02:25   Jan_21  7026 345344 ora_arc0_prism
02:25   Feb_18 28202 967984 oracleprism (LOCAL=NO)
02:25   Feb_18  1886 970784 ora_ckpt_prism
01:31   Feb_18  1880 964688 ora_pmon_prism
01:28   Feb_18 24963 963504 oracleprism (LOCAL=NO)
00:50   Feb_18 13985 964048 oracleprism (LOCAL=NO)

A quoi ça te sert de savoir ça?

[Tracnac]

C'est un gouffre à CPU ton process...

23:38:13 Feb_18 17191 979656 oracleprism (LOCAL=NO)

tu as un (stime) qui date du 18 février donc ton process est up depuis cette date...
le time "23:38:13" est le temps CPU que tu as consommé depuis cette date... (C'est enorme...)

le reste nous servira plus tard...

Par contre ça c'est pas normal ? T'aurais pas des problème avec les IPC par hazard ?

02:50 Jan_21 7014 345800 ora_pmon_prism
01:31 Feb_18 1880 964688 ora_pmon_prism

Que donnes :

Code :

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

ipcs -a

Merci

[Tracnac]

As tu une autre version d'oracle installée... avec le même SID ?

[farenheiit]

tu as un (stime) qui date du 18 février donc ton process est up depuis cette date...
le time "23:38:13" est le temps CPU que tu as consommé depuis cette date... (C'est enorme...)

C'est normal! j'ai dit tout à l'heure que mon traitement batch dure un peu moins de 30h, et je l'ai lancé hier après midi donc effectivement il tourne depuis hier et ne va pas tarder à se terminer. Je vois pas ce qui te choque car ça correspond à ma problématique. C'est pour ça que j'ai ouvert cette discussion sur le forum => pour réduire de moitié la durée de mon traitement batch

T'aurais pas des problème avec les IPC par hazard

je ne vois pas ce que tu veux dire

Code :

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

ipcs -a

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
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
IPC status from <running system> as of Tue Feb 19 17:06:54 CET 2008
T         ID      KEY        MODE        OWNER    GROUP  CREATOR   CGROUP CBYTES  QNUM QBYTES LSPID LRPID   STIME    RTIME    CTIME
Message Queues:
q          0   0x34568766 --rw-rw-rw-     root    other     root    other      0     0  65536     0     0 no-entry no-entry 18:18:14
T         ID      KEY        MODE        OWNER    GROUP  CREATOR   CGROUP NATTCH      SEGSZ  CPID  LPID   ATIME    DTIME    CTIME
Shared Memory:
m   33554518   0x152ed9b8 --rw-r-----   ora928      dba   ora928      dba     78  918552576  1878 13636 17:06:50 17:06:50  3:22:11
m   33554516   0x4120b018 --rw-rw-rw-   patrol   patrol   patrol   patrol      0       1280 29328 29328 17:06:10 17:06:10 15:03:10
m   33554515   0x4120b016 --rw-rw-rw-   patrol   patrol   patrol   patrol      0      88124 29328 29328 17:06:10 17:06:10 14:34:10
m   33554512   0x4120b017 --rw-rw-rw-   patrol   patrol   patrol   patrol      0        768 29328 29328 17:06:10 17:06:10 15:19:10
m   33554510   0x4120b015 --rw-rw-rw-   patrol   patrol   patrol   patrol      0       4352 29328 29328 17:06:20 17:06:20 15:18:20
m   33554501   0x4120b013 --rw-rw-rw-   patrol   patrol   patrol   patrol      0        768 29328 29328 17:06:20 17:06:20 15:18:20
m   33554499   0x4120b012 --rw-rw-rw-   patrol   patrol   patrol   patrol      0        256 29328 29328 17:06:20 17:06:20 15:18:20
m   33554498   0x4120b011 --rw-rw-rw-   patrol   patrol   patrol   patrol      0       3840 29328 29328 17:06:20 17:06:20 15:18:20
m   33554488   0x4120b010 --rw-rw-rw-   patrol   patrol   patrol   patrol      0        256 29328 29328 17:06:20 17:06:20 15:18:20
m   33554487   0x4120b005 --rw-rw-rw-   patrol   patrol   patrol   patrol      0        256 29328 29328 17:06:20 17:06:20 15:18:20
m   33554486   0x4120b004 --rw-rw-rw-   patrol   patrol   patrol   patrol      0        256 29328 29328 17:06:20 17:06:20 15:18:20
m   33554485   0x4120b00f --rw-rw-rw-   patrol   patrol   patrol   patrol      0        768 29328 29328 17:06:20 17:06:20 15:18:20
m   33554483   0x4120b00e --rw-rw-rw-   patrol   patrol   patrol   patrol      0        256 29328 29328 17:06:20 17:06:20 15:18:20
m   33554480   0x120b00c  --rw-rw-rw-   patrol   patrol   patrol   patrol      0       2296 29321 29321 15:19:05 15:19:05 15:18:09
m   33554479   0x220b00d  --rw-rw-rw-   patrol   patrol   patrol   patrol      0       2048 29321 29328 17:06:50 17:06:50 15:18:09
m   16777278   0xf119e4ec --rw-r-----   ora816 oinstall   ora816 oinstall      7  316997632  6768 16609 14:35:37 17:19:37  9:26:06
m        100   0xdead     -----------     root    other     root    other      1          4 16746  4046 11:17:00 11:17:00 18:18:06
m         57   0x5e710be4 --rw-------     root     root     root     root      1        512   890 13383 15:21:41 17:04:22 15:21:41
T         ID      KEY        MODE        OWNER    GROUP  CREATOR   CGROUP NSEMS   OTIME    CTIME
Semaphores:
s   33554480   0x3642d5ec --ra-r-----   ora928      dba   ora928      dba   204 17:06:54  3:22:13
s   33554476   0xc120b018 --ra-ra-ra-   patrol   patrol   patrol   patrol     2 17:06:10 15:19:05
s   33554475   0xc120b017 --ra-ra-ra-   patrol   patrol   patrol   patrol     2 17:06:10 15:19:03
s   33554474   0xc120b015 --ra-ra-ra-   patrol   patrol   patrol   patrol     2 17:06:20 15:18:13
s   33554473   0xc120b013 --ra-ra-ra-   patrol   patrol   patrol   patrol     2 17:06:20 15:18:11
s   33554472   0xc120b012 --ra-ra-ra-   patrol   patrol   patrol   patrol     2 17:06:20 15:18:11
s   33554471   0xc120b011 --ra-ra-ra-   patrol   patrol   patrol   patrol     2 17:06:20 15:18:11
s   33554470   0xc120b010 --ra-ra-ra-   patrol   patrol   patrol   patrol     2 17:06:20 15:18:11
s   33554469   0xc120b005 --ra-ra-ra-   patrol   patrol   patrol   patrol     2 17:06:20 15:18:11
s   33554468   0xc120b004 --ra-ra-ra-   patrol   patrol   patrol   patrol     2 17:06:20 15:18:11
s   33554467   0xc120b00f --ra-ra-ra-   patrol   patrol   patrol   patrol     2 17:06:20 15:18:11
s   33554466   0xc120b00e --ra-ra-ra-   patrol   patrol   patrol   patrol     2 17:06:20 15:18:11
s   33554465   0xc120b016 --ra-ra-ra-   patrol   patrol   patrol   patrol     2 17:06:10 15:18:10
s   33554463   0x8220b00d --ra-ra-ra-   patrol   patrol   patrol   patrol     2 17:06:50 15:18:09
s   33554462   0x8120b00c --ra-ra-ra-   patrol   patrol   patrol   patrol     2 15:19:05 15:18:08
s   16777290   0x3565a76  --ra-r-----   ora816 oinstall   ora816 oinstall   114  9:26:09  9:26:06
s         72   0x55000c99 --ra-ra-ra-     root     root     root     root     1 14:40:36 19:22:17
s          0   0x71710b67 --ra-ra-ra-     root     root     root     root     1 17:51:14 11:51:32

[pifor]

Quelle démarche je dois adopter pour optimiser ma base et mon appli?
j'ai fait la formation tuning chez Oracle, je me suis pris plein d'info dans la tête pendant une semaine (optimisation du buffer cache, de la shared pool, des tris, des ordres sql, des redo logs...) mais je n'ai pas appris de démarche.

Certains m'ont dit de commencer par statspack d'autres me disent le contraire...je comprend plus rien.

Dans les grandes lignes

1. identifier l'objectif de performance
2. utiliser les outils Oracle comme Statspack, la trace SQL/TKPROF pour analyser où passe le temps d'exécution dans la base
3. si des problèmes sont identifiés coté base de données, les corriger(paramètres d'instance, taille des redo logs, etc. mais aussi ordres SQL à optimiser voire à réécrire)
4. si le temps écoulé est en dehors de la base, trouver où le temps est consommé: dans les clients connectés ? dans le réseau ? ailleurs sur le serveur car le serveur est partagé avec d'autres instances ou d'autres services ?
5. diminuer les temps d'exécution ou les temps d'attente trouvés en dehors de la base
6. aller à l'étape 2 jusqu'à objectif atteint

Par rapport, à mon résultat statspack on peut dire en résumé qu'il n'a ya pas de souci apparent au niveau de la configuration de la machine, et qu'il faut donc que j'optimise le code PL/SQL c'est ça ?

Je doute que le PL/SQL soit le problème ici: il n'y aurait pas des millions d'échanges client/serveur dans ce cas.

[farenheiit]

As tu une autre version d'oracle installée... avec le même SID ?

non cette machine est dédiée à notre base de données et au serveur WebLogic.

Il n' y a rien d'autres sur cette machine

[Tracnac]

Non désolé 23 Heures 30 de CPU c'est pas normal soit ton traitement fait des transfomée de fourrier soit tu calcul un DIVX ... il ne s'agit pas de 23H30 depuis le démarrage du process mais de 23H30 de consommation CPU ce qui n'a rien avoir...

C'est ok pour les 2 pmon... une instance 9i et une 8i visiblement...

Sinon dans un premier temps... sous sqlplus sur le serveur...

Code :

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

1
2
3
4
5
6
7
8
9
 
SQL> connect / as sysdba
SQL> oradebug setospid 17191
SQL> oradebug event 10046 trace name context forever, level 12
 
Laisse tourner...
Puis 
 
SQL> oradebug event 10046 trace name context off

[Tracnac]

non cette machine est dédiée à notre base de données et au serveur WebLogic.

Il n' y a rien d'autres sur cette machine

Ah bah si t'as une instance qui traine sous 8i....

[pifor]

Ah bah si t'as une instance qui traine sous 8i....

Il y a même plus de connexions que sur l'instance 9i (114 processus attachés contre 78).

[farenheiit]

ça fait quoi cette commande? je te demande ça parceque je suis sur la base de prod là

[Tracnac]

On va passer le process en trace
le fichier trace est généré sous udump

[farenheiit]

Ah bah si t'as une instance qui traine sous 8i....

c'est incroyable ça!!!!
on a fait un migration 8i vers 9i en septembre 2007 mais on a changé de serveur. L'hébergeur n'était pas sensé nous installer d'instance 8i...

Citation:
Envoyé par Tracnac Voir le message
Ah bah si t'as une instance qui traine sous 8i....
Il y a même plus de connexions que sur l'instance 9i (114 processus attachés contre 78).

comment vous voyez ça??
désolé je suis une bille en UNIX

[pifor]

On va passer le process en trace
le fichier trace est généré sous udump

ATTENTION
1. le paramètre max_dump_file_size est sans doute trop petit => trace tronquée
2. avec des millions d'instructions SQL et d'échanges client/serveur le fichier trace risque d'être TRES volumineux.

[pifor]

comment vous voyez ça??
désolé je suis une bille en UNIX

La colonne NATTACH de ipcs donne le nombre de processus qui utilisent la resource: ici c'est le segment de mémoire partagé = la SGA. Tous les processus Oracle comptent: les démons (sauf le listener) et les serveurs dédiés et/ou partagés.

[Tracnac]

Oui "pifor" a raison cela risque d'être volumineux assez rapidement... c'est juste histoire de capturer un peu d'info évidement il faut pas laisser trainer le paramêtre pendant 10 Heures...

Disons 15 minutes cela nous donnera de l'eau au moulin...

Désolé pour ta 8i...

Attends la fin de ton traitement et sous le compte ora816 un petit shutdown qui va bien...

m 16777278 0xf119e4ec --rw-r----- ora816 oinstall ora816 oinstall 7 316997632 6768 16609 14:35:37 17:19:37 9:26:06

[orafrance]

le time "23:38:13" est le temps CPU que tu as consommé depuis cette date... (C'est enorme...)

Sauf s'il a passé son temps à ne rien faire

le but de la trace niveau 8 c'est au moins avoir les waits et les requêtes exécutées... si on voit tout le temps la même ça veut dire qu'une seule requête est exécutée dans un LOOP en ne changeant qu'une variable... on en revient au problème de dév dont je parlais... je persiste à croire que vous faite fausse toute

[pifor]

Sauf s'il a passé son temps à ne rien faire
:

Si un processus ne fait rien sous Unix, je ne pense pas que son temps d'exécution CPU augmente.