Discussion :

[bstevy]

Bonjour,



J'ai un petit problème avec une requête qui ne veut pas me rendre la main lorsque je lui passe une date "parametrée" alors que la date codée en dure passe très bien.


Voici la requête :

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
select  PROP_CREATED_DATE , 
        TVS_CHANNEL.TVS_DESCRIPTION CHANNEL, 
        CASE OVM_CATEGORY   WHEN '9'  then 'BIKE'
                            WHEN '10' then 'BIKE'
                            WHEN '11' then 'BIKE'
                            ELSE 'CAR'
            END AS PRODUCT, TVS_ACTION.TVS_DESCRIPTION BROKER, APV_ACTION_REFERENCE
from ad_proposals
inner join ad_proposal_versions on PROP_REFERENCE = APV_PROP_REFERENCE  
inner join ad_proposal_objects  on POB_APV_PROP_REFERENCE = APV_PROP_REFERENCE 
                                and POB_APV_VERSION_NUMBER = APV_VERSION_NUMBER
inner join ov_motors    on OVM_OBJ_ID = POB_OVM_OBJ_ID
                        and POB_OVM_NUMBER = OVM_NUMBER 
INNER JOIN table_values TVS_CHANNEL on TVS_CHANNEL.TVS_CODE = PROP_CHANNEL and TVS_CHANNEL.TVS_TAD_CODE = 'CHANNEL'
left outer join table_values TVS_ACTION on TVS_ACTION.TVS_CODE = APV_ACTION_REFERENCE and TVS_ACTION.TVS_TAD_CODE = 'EBROKERID'
where APV_CREATED_DATE >= add_months(trunc(sysdate),-1)
and APV_VERSION_NUMBER = 1
and APV_ORIGIN_TYPE = 'NBV'

Le passage qui me bloque est APV_CREATED_DATE >= add_months(trunc(sysdate),-1)
Si je remplace ca par APV_CREATED_DATE >= date '2015-05-29', ca m'affiche le résultat de suite (y'a un index sur ce champ - APV_CREATED_DATE est du type date) mais avec la date calculée, ca ne veut pas me rendre la main, je sais pas ce que ca calcule, mais ca y va...

Est ce que vous auriez une explication à ce phénomène et une idée de comment je pourrais faire pour avoir ma date en paramétrée ?
(le but étant de l'utilisée dans un dashboard sur une période de 1 mois glissant)


Merci d'avance pour vos réponses.

[mnitu]

Comme je vous l’ai disait hier c’est un problème des cardinalités. Mauvaise cardinalité implique => mauvais méthode d’accès => de jointure et => d’ordre de jointure des tables.

La requête qui utilise des littéraux en dur a comme avantage le fait d’exposer directement à l’optimiseur la valeur proposée. Celui-ci peut donc utiliser les informations statistiques qu’il a stockées pendant la collecte des statistiques pour estimer avec précision (*) la cardinalité du résultat. Mais elle a un grand désavantage qui est lié au fait que chaque changement de la valeur implique un hard parsing de la requête ce qui est très couteaux !

(*) surtout en présence des histogrammes quand les valeurs de la colonne ne sont pas distribuées d’une manière uniforme.

La requête qui utilise une variable de liaison (ce n’est pas votre cas) dans laquelle la valeur a été stockée au préalable, élimine le besoin des étapes de hard parsing redondantes à chaque changement de la valeur mais traite tous les valeurs de la même manière, ce qui s’avère à être un désastre en présence des distributions non-uniforme des valeurs. Il y a un mécanisme d’introspection de la valeur lors du hard parsing qui permet éventuellement de bénéficier de la présence des histogrammes mais si les valeurs sont distribuées d’une manière fortement non-uniforme alors le comportement de la requête peut être assez décevant lors des exécutions répétitives avec des valeurs différentes. Ce mécanisme a été amélioré en version 11g via « l’adaptive sharing » mais cela coût quand même une exécution sous-optimale de la requête. Et en 12g encore il y a des nouvelles avec des plans d’exécutions adaptives.

L’autre requête de votre exemple utilise en fait une fonction, donc sa valeur est inconnue à l’optimisateur. Dans ce cas qu’est-ce que celui-ci pourrais faire ? Il suppose d’une manière optimiste que ce prédicat va ramener 5% des enregistrements et il optimise la requête en conséquence.

Normalement vous devez voir ces différences des cardinalités dans le deux plans d’exécution ainsi que des ordres et peut être des méthodes de jointure différentes.

Commencez par investiguez les deux plans, les données (la distribution des valeurs), les statistiques (je pense que des histogrammes sont présents) ainsi que les cas d’utilisation de la requête. Si la requête s’exécute 5 fois par jour utilisez des valeurs en dur sinon faite appels à des autres techniques d’optimisation en fonction des besoins et/ou autres contraintes.

[bstevy]

Merci pour ces explications.

Les plans sont strictements identiques, à l'exeption de cette ligne :

INDEX RANGE SCAN INDEX JAPHONIE.AD_PROPOSAL_VERSIONS_IDX5; Optimizer=Analyzed; Search_columns=1; Cost=1; Cardinality=2; Cpu_cost=8,666; Io_cost=1; Access_predicates="ad_proposal_versions"."apv_created_date">=to_date(' 2015-05-31 00:00:00', 'syyyy-mm-dd hh24:mi:ss'); Time=1

INDEX RANGE SCAN INDEX JAPHONIE.AD_PROPOSAL_VERSIONS_IDX5; Optimizer=Analyzed; Search_columns=1; Cost=1; Cardinality=2; Cpu_cost=8,666; Io_cost=1; Access_predicates="ad_proposal_versions"."apv_created_date">=add_months(trunc(sysdate@!),-1); Time=1

Toutes les autres valeures de cardinalité et de cout sont strictement identiques...



J'ai trouvé une solution temporaire de contournement en utilisant les deux conditions vue que la partie sysdate sera toujours supérieure à l'autre date.

[mnitu]

...
Toutes les autres valeures de cardinalité et de cout sont strictement identiques...
...

Si tout est identique vous n'avez pas de problème et les deux requêtes s'exécutent dans le même temps.

[bstevy]

Mais justement, non ! C'est bien la mon problème

Le plan est identique, la query devrait être identique si c'est n'est le coté "paramétrée" de la date ; et pourtant, lorsque j'éxecute la partie "paramétrée" je n'arrive pas à obtenir de réponse. Ca mouline, et mouline encore... et au bout d'une heure, j'ai toujours pas de résultat. Donc à part ma solution temporaire j'arrive pas à me dépatouiller de ce problème.

[mnitu]

Donc en réalité ce n'est pas identique!
Essayez de choper le plan réel de la requête qui mouline: via les structures de mémoire v$SQL..., via le sql_id or via une trace sql étendue.