Discussion :

[orafrance]

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

T'as déjà vu une base de données qui ne fait rien quand un traitement tourne dessus ? Moi jamais

[farenheiit]

autre chose:
le fait d'avoir lancé le traitement batch depuis une machine distante ça a un impact sur les perf?

[pifor]

T'as déjà vu une base de données qui ne fait rien quand un traitement tourne dessus ? Moi jamais

Je crois que tu mélanges les problèmes. Je parlais du temps CPU du processus client et non du serveur.

Et si dans une instance, il y a en moyenne quelques sessions actives et beaucoup de sessions inactives on aura bien en total beaucoup d'attente.

[pifor]

autre chose:
le fait d'avoir lancé le traitement batch depuis une machine distante ça a un impact sur les perf?

Cela dépend si le processus client connecté à l'instance s'exécute en local ou à distance. Et si le client se connecte en local avec ou sans Oracle Net. A priori, les échanges en local doivent être plus rapides que sur le réseau et une connection locale sans Oracle Net doit être plus rapide qu'une connection locale avec Oracle Net. Avec environ 7 millions d'échanges, quelques millisecondes peuvent coûter au total cher.

[farenheiit]

quand tu dis:

une connection locale sans Oracle Net doit être plus rapide qu'une connection locale avec Oracle Net

tu parles du fait de se connecter en local sur la base via bequeath?

[pifor]

Je pense à la façon de se connecter en positionnant uniquement ORACLE_SID et ORACLE_HOME sans utiliser de nom de service ou d'instance dans la connect string, sans utiliser le listener.

[Tracnac]

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

Oui c'est exacte time n'augmente que si il y a consommation de CPU...

Sinon farenheiit tu n'oublies pas le fichier trace...

Merci.

[farenheiit]

Sinon farenheiit tu n'oublies pas le fichier trace...

mon traitement batch s'est terminé hier à 19h36 => il a mis plus de 28 heures

je vais le relancer aujourd'hui avec le mode trace

[Tracnac]

Hello,

Ah non dommage ! c'etait dynamique il n'y avait pas besoin de le relancer !? les commandes sql que je t'ai passé quelques posts plus haut permet de passer le process en trace dynamiquement... C'est son intêret principal !!!

[orafrance]

remarque maintenant on peut avoir un rapport statspack de la dernière demi-heure du traitement, on verra peut-être les requêtes à problème

[farenheiit]

remarque maintenant on peut avoir un rapport statspack de la dernière demi-heure du traitement, on verra peut-être les requêtes à problème

comment ça???
mon traitement s'est fini hier soir
le dernier snapshot date d'hier à 11h46, je ne peux pas fournir de rapport de la dernière demi heure

question:
toutes les requêtes qui ont été executées depuis le début de mon traitement sont-elles toujours dans les vues dynamiques (v$sql)???

Que pensez vous du paramètre cursor_sharing? il est actuellement à "Exact".
Dois je le passer à "Force"?

[Tracnac]

comment ça???
mon traitement s'est fini hier soir
le dernier snapshot date d'hier à 11h46, je ne peux pas fournir de rapport de la dernière demi heure

Je ne parle pas du statspack mais du fichier dans udump (Généré grace à la trace du oradebug...)

Que pensez vous du paramètre cursor_sharing? il est actuellement à "Exact".
Dois je le passer à "Force"?

Non tes ratios hard parse/ soft parse / execute sont ok...

[farenheiit]

il me reste 5.7 Go sur le file system /oradata là ou se trouve le répertoire udump.
vous pensez que ça suffit pour activer le mode trace?

[orafrance]

comment ça???
mon traitement s'est fini hier soir
le dernier snapshot date d'hier à 11h46, je ne peux pas fournir de rapport de la dernière demi heure

D'où l'intérêt de programmer un snapshot toutes les 1/2 heure

question:
toutes les requêtes qui ont été executées depuis le début de mon traitement sont-elles toujours dans les vues dynamiques (v$sql)???

Oui, depuis le démarrage de la base

Que pensez vous du paramètre cursor_sharing? il est actuellement à "Exact".
Dois je le passer à "Force"?

Plutôt SIMILAR éventuellement mais comme l'a dit Tracnac, rien ne montre un soucis du coté du parsing

[farenheiit]

Je viens de lancer mon traitement batch

voici la tête qu'il 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
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
-- chargement mensuel
SET SERVEROUTPUT ON
 
-- truncate des tables
EXEC PCK_TRUNCATE_CNC.pGlobal_Truncate;
 
 
-- calcul des stats
EXEC DBMS_UTILITY.ANALYZE_SCHEMA(UPPER('dbo_tuning'),'COMPUTE');
EXEC DBMS_OUTPUT.ENABLE(10000);
 
SPOOL ldr_base.log;
--COMMIT;
-- Intégration des données
EXEC PCK_LOADER_UTL.PGlobal_import(to_date('31/12/2007', 'DD/MM/YYYY'));
 
 
-- Attribution+validation
EXEC PCK_LOADER_UTL.PGlobal_import_fin_chgt(to_date('31/12/2007', 'DD/MM/YYYY'));
 
-- Pools pme	
exec pck_loader_pool.pCHARGE_POOL_PME;
commit;
 
 --constitution des profils d'engagement 
host java -mx512m com.socgen.prism.constructProfilPoolPME.ConstructPoolPME 192.16.238.149 1521 PRISM dbo_tuning
 
-- Validation des pools PME
BEGIN
	FOR CUR_REC in (
	select poo_id 
	from tpool
	where poo_ind_src_alim='D' )
	LOOP
	PCK_REGLE_COMMUNE_BCE.pPOST_TRAITEMENT_POOL_IHM(cur_rec.poo_id);
	end loop;
end;
/
 
/*
-- invalidation des DC et poids 50 
*/
 
UPDATE TCONCOURS SET CNC_VALIDE='N', CNC_POIDS=50 
WHERE CNC_ID IN ( 
  SELECT CNC_ID FROM TCONCOURS_DER_CRE2 DC 
  WHERE CDC_NOMINAL_DC_EUR IS NULL OR CDC_NOMINAL_DC_EUR = 0 
  AND NOT EXISTS (SELECT 1 FROM TTAB_NOMINAL TAB WHERE DC.CNC_ID=TAB.CNC_ID) 
);
 
COMMIT;
 
UPDATE TGARANTIE SET GAR_VALIDE='N', GAR_POIDS=50 WHERE TGR_CODE IN ( 
SELECT gar.TGR_CODE FROM TGARANTIE gar, TTYP_GARANTIE typ 
WHERE NOT EXISTS (SELECT 1 FROM TLIEN_GAR_SGCIB lien WHERE gar.tgr_code=lien.tgr_code) AND 
NOT EXISTS (SELECT 1 FROM TLIEN_GAR_SGCIB_DET lien WHERE gar.tgr_code=lien.tgr_code) 
AND gar_valide='O' AND gar.tgr_code = typ.tgr_code AND typ.TGR_IND_TYPE='C' 
);
 
COMMIT;
 
/*
-- Invalidation des garanties
-- cause d''invalidité 
*/
 
INSERT INTO TGARANTIE_VAL 
(CRV_CODE, GAR_ID)
(select 2000000, GAR_ID 
FROM TGARANTIE 
WHERE TGR_CODE IN (SELECT gar.TGR_CODE 
                  FROM TGARANTIE gar, TTYP_GARANTIE typ 
                  WHERE NOT EXISTS (SELECT 1 FROM TLIEN_GAR_SGCIB lien WHERE gar.tgr_code=lien.tgr_code) AND 
                  NOT EXISTS (SELECT 1 FROM TLIEN_GAR_SGCIB_DET lien WHERE gar.tgr_code=lien.tgr_code) 
                  AND gar_poids=50 AND gar.tgr_code = typ.tgr_code AND typ.TGR_IND_TYPE='C') 
);
 
 
COMMIT;
-- Reconstitution du portefeuille mensuel
EXEC PMARKPORTREF;
COMMIT ;
 
 
--Lancement de l'ANALYZE
BEGIN
For cur in (Select table_name
			From   user_tables
			where  table_name not like '%_LDR'
				   and table_name not like 'TCALC_%'
				   and table_name not like 'TPME_%')
LOOP						
  EXECUTE IMMEDIATE 'analyze table ' || cur.table_name ||' compute statistics';
END LOOP;
--
END;
/
 
COMMIT;
 
 
SPOOL OFF;
EXIT
EOF

Tracnac pour passer le process en trace:
j'ai fait:

Code :

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

oradebug setospid 1473

mais que dois je mettre dans la ligne suivante:

Code :

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

oradebug event 10046 trace name context forever, level 12

A quoi correspond le numéro 10046 et le numéro de level?

[Tracnac]

Tracnac pour passer le process en trace:
j'ai fait:

Code :

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

oradebug setospid 1473

J'espère que 1473 c'est bien le process qui effectue cette opération... et je te conseille :

max_dump_file_size=unlimited; si cela n'a pas été déjà fait...

Sinon je te conseille ça pour t'éclairer un peu...

http://www.tafora.fr/wp/tafora_tunin...10046.doc.html

[pifor]

toutes les requêtes qui ont été executées depuis le début de mon traitement sont-elles toujours dans les vues dynamiques (v$sql)???

Cela dépend de l'activité du nombre de requête exécutées, de la taille du shared_pool. On ne peut pas être sûr à 100% qu'une requête non exécutée depuis un certain temps soit toujours en cache.

[pifor]

Je viens de lancer mon traitement batch

voici la tête qu'il a:

Donc vous avez bien du PL/SQL: c'est un fait. Et vous avez aussi un programme Java. Pour avoir un première idée du temps d'éxécution des différentes étapes, vous pouvez rajouter l'instruction SQL*Plus:

Code :

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

set timing on

A plus long terme, vous pouvez envisager plutôt d'utiliser DBMS_STATS au lieu de ANALYZE et vous poser la question de savoir si une mise à quotidienne des statistisques est nécessaire en fonction du temps d'exécution nécessaire et du volume des mises à jour des données.

[farenheiit]

SET timing ON

pas besoin mon application génère déjà un fichier LOG qui indique la durée de chargement pour chaque package appelé

Cela dépend de l'activité du nombre de requête exécutées, de la taille du shared_pool. On ne peut pas être sûr à 100% qu'une requête non exécutée depuis un certain temps soit toujours en cache.

je comprends pas...dans v$sql on ne trouve que les reqêtes actuellement dans la library cache ou bien toutes les requêtes depuis le démarrage de la base?
Qui a raison? Pifor ou Orafrance?

[pifor]

pas besoin mon application génère déjà un fichier LOG qui indique la durée de chargement pour chaque package appelé

Mais cela ne donne pas le temps d'exécution du code PL/SQL qui n'est dans pas un package ni du programme Java (que je mets au premier dans la liste des "suspects"). Et vous pouver donnez les temps d'exécutions des différents packages ? C'est une des premières choses à analyser.

je comprends pas...dans v$sql on ne trouve que les reqêtes actuellement dans la library cache ou bien toutes les requêtes depuis le démarrage de la base?
Qui a raison? Pifor ou Orafrance

je cite Tom Kyte qui répond à une question similaire

All of the queries you ran since you session began might not even be in the shared pool (...) Queries get pushed out on an LRU basis when more space is needed for new queries