Discussion :

[glood1]

Pour afficher ton plan d'execution
met toi sous sqlplus

Code :

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

1
2
3
4
5
6
7
 
set lines 200
set pages 100
explain plan for
Ta_requete
;
select * from table(dbms_xplan.display());

ben elle est pas claire au dessus ou la :


Par défaut
Citation:


Sans explain plan ça va pas beaucoup nous aider ta requête
Plan
SELECT STATEMENT CHOOSECost: 175,576 Bytes: 3,902,860 Cardinality: 22,958
16 SORT GROUP BY Cost: 175,576 Bytes: 3,902,860 Cardinality: 22,958
15 HASH JOIN Cost: 174,468 Bytes: 3,902,860 Cardinality: 22,958
1 TABLE ACCESS FULL EXPL.BO_FAMILLE Cost: 2 Bytes: 690 Cardinality: 30
14 HASH JOIN Cost: 174,464 Bytes: 3,374,826 Cardinality: 22,958
2 TABLE ACCESS FULL EXPL.BO_SOUS_FAMILLE Cost: 2 Bytes: 9,594 Cardinality: 369
13 NESTED LOOPS Cost: 174,459 Bytes: 2,777,918 Cardinality: 22,958
11 HASH JOIN Cost: 174,459 Bytes: 2,640,170 Cardinality: 22,958
9 HASH JOIN Cost: 173,128 Bytes: 1,469,312 Cardinality: 22,958
7 HASH JOIN Cost: 7 Bytes: 380 Cardinality: 10
5 INLIST ITERATOR
4 TABLE ACCESS BY INDEX ROWID EXPL.BO_SUCCURSALE Cost: 2 Bytes: 96 Cardinality: 4
3 INDEX RANGE SCAN UNIQUE EXPL.PK_BO_SUCCURSALE Cost: 1 Cardinality: 4
6 TABLE ACCESS FULL EXPL.BO_PVT Cost: 4 Bytes: 1,064 Cardinality: 76
8 TABLE ACCESS FULL EXPL.STATARTICLE Cost: 173,099 Bytes: 35,813,830 Cardinality: 1,377,455
10 TABLE ACCESS FULL EXPL.BO_ARTICLE Cost: 347 Bytes: 18,255,297 Cardinality: 357,947
12 INDEX UNIQUE SCAN UNIQUE EXPL.PK_BO_SECTION Bytes: 6 Cardinality: 1j ai pas le temps ce soir
j'essayerai demain
sinon voir mon fichier joint il y a tout dessus

[pachot]

Bonjour,

Il serait interressant de savoir combien d'enregistrements sont retournés par la requête sans le group by.
L'optimiseur l'estime à 22958 et fait donc 22958 fois un accès à l'index PK_BO_SECTION. Si c'est beaucoup plus, alors le coôt du nested loop est peut être sous estimé.
Et combien y a-t-il d'enregistrements dans BO_SECTION ?

Au fait, les stats, elles sont à jour ?

Cordialement,
Franck.

[glood1]

Bonjour,

Il serait interressant de savoir combien d'enregistrements sont retournés par la requête sans le group by.
L'optimiseur l'estime à 22958 et fait donc 22958 fois un accès à l'index PK_BO_SECTION. Si c'est beaucoup plus, alors le coôt du nested loop est peut être sous estimé.
Et combien y a-t-il d'enregistrements dans BO_SECTION ?

Au fait, les stats, elles sont à jour ?

Cordialement,
Franck.

oui les stats sont a jours
1474 rows ds BO_SECTION

[pachot]

Je sais toujours pas combien de lignes sont retournées ...
Sinon, pour rester dans l'idée du pb de nested loop, vu que BO_SECTION est minuscule, je pense que l'accès par nested loop et index est mauvais.
Tu peux peut être essayer de forcer un full scan pour voir:

Code :

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

SELECT /*+ FULL(bo_section) */  statarticle.nusuc ...

Est-ce que tu peux vérifier les stats:

Code :

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

select table_name,blocks,num_rows from user_tables where table_name='BO_SECTION'

Cordialement,
Franck.

[glood1]

Je sais toujours pas combien de lignes sont retournées ...
Sinon, pour rester dans l'idée du pb de nested loop, vu que BO_SECTION est minuscule, je pense que l'accès par nested loop et index est mauvais.
Tu peux peut être essayer de forcer un full scan pour voir:

Code :

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

SELECT /*+ FULL(bo_section) */  statarticle.nusuc ...

Est-ce que tu peux vérifier les stats:

Code :

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

select table_name,blocks,num_rows from user_tables where table_name='BO_SECTION'

Cordialement,
Franck.

re
moi non plus la requete rame pendant 35 minutes elle me les a pas affiché et a un peu planter mon toad.en plus cela fait un max d io
donc je peux la lancer que le soir
3000 ou 30000 je me souviens plus car cela a comme exploser je voyait juste un compteur me ramenan les lignes

forcer le full scan avec le hint et afficher le plan d 'execution ou tu dire combien cela ramene de lignes

Code :

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

select table_name,blocks,num_rows from user_tables where table_name='BO_SECTION'

BO_SECTION 13 blocks 1474 num row

[pachot]

forcer le full scan avec le hint et afficher le plan d 'execution ou tu dire combien cela ramene de lignes

Oui, explain plan pour voir s'il ne fait plus le nested loop et execution pour voir si c'est mieux.

Pour moi, il est clair que le plan d'execution n'est pas optimal:
L'opération 11 est supposée retourner 22958 lignes de 115 octets
Et pour aller voir BO_SECTION, oracle choisit d'aller voir 22959 fois l'index.

Par contre, celà n'a peut être pas beaucoup d'impact sur les temps de réponse.

Autre point: est-ce nécessaire d'aller voir BO_SECTION ? Parce que tu ne ne vas pas y voir d'autre colonnes que la clé primaire.
Donc peutêtre faut il voir si la requête veut dire quelque chose...

[tmenard]

Quels sont les valeurs de tes paramètres d'initialisations. SGA. PGA. Auto_agregate_target, *_area_size?
Taille de temp

Lorsque tes plus grosses requêtes tournent (TOP CPU de ton report)

Qu'elle est l'état/contenu de ton tablespace temporaire. (passe les requêtes suivantes quand ton SQL tourne, et que tu as des perf mauvaises.)

-- Objets occupants le tablespace temporaire

Code :

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

1
2
3
4
5
6
7
SELECT substr(b.TABLESPACE,1,5) T, a.program, sum(ROUND (  (  ( b.blocks * p.VALUE ) / 1024 / 1024 ), 2 )) size_mb
, a.SID, a.serial#, substr(a.username,1,12) UB, substr(a.osuser,1,8) OSU, a.status, b.segfile#, b.segblk#
    FROM v$session a, v$sort_usage b, v$process c, v$parameter p
   WHERE p.NAME = 'db_block_size' AND a.saddr = b.session_addr AND a.paddr = c.addr
group by substr(b.TABLESPACE,1,5), a.program,a.SID, a.serial#, substr(a.username,1,12), 
substr(a.osuser,1,8), a.status, b.segfile#, b.segblk#
ORDER BY size_mb, b.segfile#, b.segblk#;

-- Le type de tris

Code :

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

1
2
3
4
SELECT s.sid, u.segtype, blocks*p.value / 1024 / 1024 "Taille en MB"
FROM v$sort_usage u, v$session s,v$parameter p
WHERE u.session_addr = s.saddr
AND p.name='db_block_size';

-- Localisation des tris

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
SELECT name, value
FROM v$sysstat
WHERE name like 'sort%'
UNION
-- % de Tri sur Disque 
SELECT 'disk sort percent', TRUNC(a.value/(a.value+b.value)*100,2)
FROM v$sysstat a, v$sysstat b
WHERE a.name = 'sorts (disk)'
AND b.name = 'sorts (memory)'
UNION
-- Lignes par tri 
SELECT 'rows per sort', TRUNC(c.value/(a.value+b.value))
FROM v$sysstat a, v$sysstat b, v$sysstat c
WHERE a.name = 'sorts (disk)'
AND b.name = 'sorts (memory)'
AND c.name = 'sorts (rows)';

[glood1]

Oui, explain plan pour voir s'il ne fait plus le nested loop et execution pour voir si c'est mieux.

Pour moi, il est clair que le plan d'execution n'est pas optimal:
L'opération 11 est supposée retourner 22958 lignes de 115 octets
Et pour aller voir BO_SECTION, oracle choisit d'aller voir 22959 fois l'index.

Par contre, celà n'a peut être pas beaucoup d'impact sur les temps de réponse.

Autre point: est-ce nécessaire d'aller voir BO_SECTION ? Parce que tu ne ne vas pas y voir d'autre colonnes que la clé primaire.
Donc peutêtre faut il voir si la requête veut dire quelque chose...

cela marche mieux avec le hints 15 ou lieux de 30 minutes
c 'est pas top mais cela va dans le bon sens
cela ramene les lignes et les affiches
135 401 row
je pense pas que c 'est necessaire d' aller voir bo_sections que changer dans la requete

cela veut dire quoi qu il faut supprimer l index sur bo_section ?
ci joint le plan avec le hints
Plan
SELECT STATEMENT CHOOSECost: 176 K Bytes: 4 M Cardinality: 23 K
16 SORT GROUP BY Cost: 176 K Bytes: 4 M Cardinality: 23 K
15 HASH JOIN Cost: 174 K Bytes: 4 M Cardinality: 23 K
1 TABLE ACCESS FULL EXPL.BO_FAMILLE Cost: 2 Bytes: 690 Cardinality: 30
14 HASH JOIN Cost: 174 K Bytes: 3 M Cardinality: 23 K
2 TABLE ACCESS FULL EXPL.BO_SOUS_FAMILLE Cost: 2 Bytes: 9 K Cardinality: 369
13 HASH JOIN Cost: 174 K Bytes: 3 M Cardinality: 23 K
3 TABLE ACCESS FULL EXPL.BO_SECTION Cost: 3 Bytes: 9 K Cardinality: 1 K
12 HASH JOIN Cost: 174 K Bytes: 3 M Cardinality: 23 K
10 HASH JOIN Cost: 173 K Bytes: 1 M Cardinality: 23 K
8 HASH JOIN Cost: 7 Bytes: 380 Cardinality: 10
6 INLIST ITERATOR
5 TABLE ACCESS BY INDEX ROWID EXPL.BO_SUCCURSALE Cost: 2 Bytes: 96 Cardinality: 4
4 INDEX RANGE SCAN UNIQUE EXPL.PK_BO_SUCCURSALE Cost: 1 Cardinality: 4
7 TABLE ACCESS FULL EXPL.BO_PVT Cost: 4 Bytes: 1 K Cardinality: 76
9 TABLE ACCESS FULL EXPL.STATARTICLE Cost: 173 K Bytes: 34 M Cardinality: 1 M
11 TABLE ACCESS FULL EXPL.BO_ARTICLE Cost: 347 Bytes: 17 M Cardinality: 358 K

ou voit tu cela >> choisit d'aller voir 22959 fois l'index. sur etape 13

[glood1]

Quels sont les valeurs de tes paramètres d'initialisations. SGA. PGA. Auto_agregate_target, *_area_size?
Taille de temp

Lorsque tes plus grosses requêtes tournent (TOP CPU de ton report)

Qu'elle est l'état/contenu de ton tablespace temporaire. (passe les requêtes suivantes quand ton SQL tourne, et que tu as des perf mauvaises.)

-- Objets occupants le tablespace temporaire

Code :

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

1
2
3
4
5
6
7
SELECT substr(b.TABLESPACE,1,5) T, a.program, sum(ROUND (  (  ( b.blocks * p.VALUE ) / 1024 / 1024 ), 2 )) size_mb
, a.SID, a.serial#, substr(a.username,1,12) UB, substr(a.osuser,1,8) OSU, a.status, b.segfile#, b.segblk#
    FROM v$session a, v$sort_usage b, v$process c, v$parameter p
   WHERE p.NAME = 'db_block_size' AND a.saddr = b.session_addr AND a.paddr = c.addr
group by substr(b.TABLESPACE,1,5), a.program,a.SID, a.serial#, substr(a.username,1,12), 
substr(a.osuser,1,8), a.status, b.segfile#, b.segblk#
ORDER BY size_mb, b.segfile#, b.segblk#;

T PROGRAM SIZE_MB SID SERIAL# UB OSU STATUS SEGFILE# SEGBLK#
TEMP DSA6:[ORACLE9I.][bin]sqlplus.exe;1 24 16 123 EXPL EXPL ACTIVE 201 36 105



-- Le type de tris

Code :

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

1
2
3
4
SELECT s.sid, u.segtype, blocks*p.value / 1024 / 1024 "Taille en MB"
FROM v$sort_usage u, v$session s,v$parameter p
WHERE u.session_addr = s.saddr
AND p.name='db_block_size';

SID SEGTYPE Taille en MB
16 SORT 22



-- Localisation des tris

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
SELECT name, value
FROM v$sysstat
WHERE name like 'sort%'
UNION
-- % de Tri sur Disque 
SELECT 'disk sort percent', TRUNC(a.value/(a.value+b.value)*100,2)
FROM v$sysstat a, v$sysstat b
WHERE a.name = 'sorts (disk)'
AND b.name = 'sorts (memory)'
UNION
-- Lignes par tri 
SELECT 'rows per sort', TRUNC(c.value/(a.value+b.value))
FROM v$sysstat a, v$sysstat b, v$sysstat c
WHERE a.name = 'sorts (disk)'
AND b.name = 'sorts (memory)'
AND c.name = 'sorts (rows)';

NAME VALUE
disk sort percent 0
rows per sort 2 477
sorts (disk) 26
sorts (memory) 33 112
sorts (rows) 82 115 541

[glood1]

NAME VALUE
disk sort percent 0
rows per sort 2 477
sorts (disk) 26
sorts (memory) 33 112
sorts (rows) 82 115 541

plus personne por favor

[tmenard]

Désolé

Tu n'as pas donné tes paramètres d'initialisation

PGA_Agregate_target =
SORT_AREA_SIZE =

Je ne suis pas expert en Tuning SQL, mais tu as :
8 TABLE ACCESS FULL EXPL.STATARTICLE Cost: 173,099 Bytes: 35,813,830 Cardinality: 1,377,455

==> tu fais un full scan or quand on regarde ta requête c'est la partie limitative de ta requête (Qui contient énormément de calcul..SUM, SORT, GROUP BY)

un index (dtenr6,nusuc) me semble utile
ou une table temporaire (permet de limiter les colonnes en sortie, donc le coût d'une ligne, et d'avoir les colonnes que tu ramènes par rapport au nombre de colonne total de ta table statarticle par rapport à l'index) et de faire du pré-calcul).

Donc tu as intérêt à passer par une table temporaire pour faire tes opérations. Les experts te conseilleront laquelle.
Moi déjà je ferai une extraction de ta table statarticle afin de ne récupérer que les lignes et colonnes qui t'intéressent.

Pour la partie fonctionnel tu fais énormément de jointure sur la table Bo.section or tu ne ramènes aucun champs de cette table.. Il faudrait revoir au niveau fonctionnel l'utilité de la table section /rt a statarticle

==> En gros si la table bo.section est limitative par rapport à statarticle elle présente un intérêt (et il faut voir le gain..) sinon, a quoi servent ces jointures?

Tes champs nufa et nusf sont joins sur bcp de tables..(peut-être une des deux jointures avec sous-famille ou statarticle est inutile, voir les deux...).

A prendre avec des pincettes je suis pas experts SQL..

1 - Fais ta table temporaire.

Code :

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

1
2
3
4
SELECT   nusuc, nupvtl,nuart, cdtyar,nufa,nusf,
FROM statarticle
WHERE dtenr6 BETWEEN '200810' AND '200909'
          AND nusuc IN ('14', '27', '94', '50');

et regardes déjà la difference de volumétrie (Si gros gain, tu passeras par une procédure stocker pour avoir tes nusuc et dtenr6 en variable.

2 - Comment tu passes tes stats?

Code :

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

EXEC dbms_stats.gather_table_stats(ownname =>'<nom_owner>', tabname => 'STATARTICLE', granularity => 'ALL', CASCADE => TRUE);

[glood1]

(dtenr6,nusuc) me semble utile
ces indexes sont déjà présents

PGA_Agregate_target = 25165824
SORT_AREA_SIZE = 524288

Code :

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

select * from v$sysstat where name like '%sort%';

STATISTIC# NAME CLASS VALUE
252 sorts (memory) 64 83 587
253 sorts (disk) 64 38
254 sorts (rows) 64 289 542 737


pour ta requete elle ne fonctionne pas faut creer une table temporaire avant ?