Discussion :

[debdba]

Bonjour,
En oracle 10.2.0.1 sur AIX, j'effectue cette requete

Code :

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

select sum(total) from (select sum(col1) as total, col2, col3, col4, col5, col6 from tab1, tab2 where .....and tab2.col6 = '2008' and tab2.mois between '0' and '12' group by col2, col3, col4, col5, col6,tab2.mois) A1;

j'obtiens un résultat numérique qui ne correspond pas à la réalité!
En revanche si j'utilise la mème requète en enlevant dans le group by le dernier champ qui est tab2.mois, le résultat est conforme à la réalité = 0.
La colonne col1 sur laquelle se fait le cumul est déclarée number (maximum par défault est de 22 digits je crois), les paramètres au niveau de la database sont nls_language=american, nls_characterset=WE8ISO8859P1, nls_sort=binary,nls_comp=binary.
Avez vous une idée sur la raison qui justifie cet écard de résultat

Merci

[orafrance]

t'as pas de valeur null par hasard ?

[debdba]

Il s'agit d'une colonne définie NOT NULL NUMBER.
ce qui est étrange c'est que selon les colonnes dans le group by on a un résultat différent

[orafrance]

c'est idiot mais pourquoi tu ne fais pas tout simplement :

Code :

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

SELECT sum(col1) AS total FROM tab1, tab2 WHERE .....AND tab2.col6 = '2008' AND tab2.mois BETWEEN '0' AND '12'

Tu la fais où ta requête : SQL*Plus, Reports, autre ?

Sinon, ça ressemble au Bug 4604970 ou 4040934

Montre nous le plan d'exécution STP

Faudra prévoir un upgrade au moins 10.2.0.3

[debdba]

La requete en question fait partie d'un livrable non modifiable.
Les plans d'executions des 2 requetes sont
Celle sui fonctionne

Rows Row Source Operation
------- ---------------------------------------------------
1 SORT AGGREGATE (cr=338602 pr=387726 pw=50491 time=59922865 us)
25995 VIEW (cr=338602 pr=387726 pw=50491 time=59923854 us)
25995 HASH GROUP BY (cr=338602 pr=387726 pw=50491 time=59897854 us)
3923199 HASH JOIN (cr=338602 pr=387726 pw=50491 time=45521496 us)
355704 TABLE ACCESS FULL TAB2(cr=32292 pr=32266 pw=0 time=752636 us)
6996220 TABLE ACCESS FULL TAB1(cr=306310 pr=304969 pw=0 time=13993295 us)

Celle qui ramène des résultats différents à chaque exécution

Rows Row Source Operation
------- ---------------------------------------------------
1 SORT AGGREGATE (cr=338602 pr=381162 pw=44745 time=36446909 us)
62783 VIEW (cr=338602 pr=381162 pw=44745 time=36398492 us)
62783 HASH GROUP BY (cr=338602 pr=381162 pw=44745 time=36398485 us)
3923199 HASH JOIN (cr=338602 pr=380790 pw=44373 time=29123066 us)
355704 TABLE ACCESS FULL TAB2(cr=32292 pr=32275 pw=0 time=619867 us)
6996220 TABLE ACCESS FULL TAB1(cr=306310 pr=304142 pw=0 time=6996856 us)

J'ai essayé d'appliquer le contournement préconisé dans metalink pour le 1er bug sans résultat concluant.
La migration vers 10.2.0.3 ne peut être accepté que si je prouve qu'il s'agit bien d'un bug et non pas d'une mauvaise configuration de buffer de tri ou de calcul quelconque.

merci pour votre aide

[orafrance]

C'est pas plus simple de faire l'upgrade sur une base de test et montrer qu'en 10.2.0.3 le problème ne se reproduit pas ? De toute façon la 10.2.0.1 est super buggée alors l'upgrade est plus que conseillé

[debdba]

Bonjour,

En attendant l'autorisation d'upgrader, j'ai rajouté dans l'init.ora ces paramètres
optimizer_features_enable=10.1.0
_gby_hash_aggregation_enabled = False

Aprés réouverture de la base cela fonctionne bien les 2 requetes donnent le mème résultat.

Merci beaucoup pour votre aide.

[orafrance]

ça prouve donc le bug ce qui devrait permettre d'obtenir l'autorisation pour l'upgrade