Discussion :

[kervoaz]

Bonjour,

j'ai actuellement un problème de consommation énorme sur une table dù à un problème de type de bind variable.
Pour faire simple, une table de 8 000 000 de lignes avec entre autre 2 colonnes:
col1 = quasiment PK
col2 = repartition non uniforme (val1= 2 000 000 rows, val2= 1 000 000 rows, ..valn= 1 row)
les 2 colonnes en VARCHAR2 sont indexées (avec des histogrammes).

Les exécutions des requête via TOAD utilisant les 2 colonnes sont normales dans tous les cas. Je pensais que vu la répartition de col2, y avait un pb de bind(pas de hard parse) mais en fait le probleme est plus grave.
En fait suivant le type de bind variable utilisée pour col2(VARCHAR2 ou CHAR), le plan est completement different. Vous allez me dire normal car en regardant dans v$SQL_SHARED_CURSOR on sait pourquoi la requete a ete reparsee. Je vois bien bien qu'il s'agit un problème de type et que la requête utilise du char(30) au lieu de VARCHAR2.

OK cependant la requête provient de Forms: le type dans FORMS est du CHAR type générique qui englobe CHAR et VARCHAR2. Donc je ne vois pas de solution pour le faire changer de type depuis Forms.
même avec des traces en 10053, lorsque c'est du CHAR utilisé, on voit l'optimizer estime à UNE ligne la recherche dans l'index de col2. Ce cout est donc toujours le plus faible et c'est cet index qui est choisi(quelque soit la valeur demandée pour la colonne): vous imaginez quand c'est la valeur ramenant 2 000 000 de lignes.

Les explications sont un peu longues mais je suis désarmé face à ce problème.
Pourquoi l'optimizer calcule toujours faux avec du CHAR?
Est ce un problème de stat/histo, un paramètre de Forms(je doute), une presence extra-terrestre dans ma base...

A l'aide svp
Merci

[mnitu]

Est-ce que dans Forms la zone col2 est définie en longueur fixe, propriété FIXED LENGTH égal à TRUE ?
Si non la variable de binding correspondante BXXX n'est pas de type CHAR mais VARCHAR2.

[kervoaz]

Bonjour,

je ne trouve pas cette propriété FIXED LENGTH(mon Forms est en french )
Par contre j'ai fait des tests avec le FORMAT MASK et SEMANTICS et même résultat.

J'ai par contre trouvé le bug 4752814 sur Metalink qui ressemble fortement à mon problème. Mauvaise estimation des cardinalités pour des variables CHAR sur data en VARCHAR2.

Merci

[mnitu]

Mon forms est en version 4.5 et en Anglais. Mais je pense que la propriété en question existe toujours (LONGUER FIXE !?). C’est dans le groupe de propriétés DATA (DONNES ?) toute suite après la propriété qui indique la longueur maximale de la zone de type char.
Je comprends qu’il y a des bugs aussi chez Oracle mais d’après tes tests si le type de la variable de liaison (bind variable ) est Varchar2 tu n’aurais pas de problème, ou je n’ai pas bien compris ?

[kervoaz]

Je suis en 10G et apparemment la propriété n'existe plus. J'ai cherché dans l'aide et il n'en est fait mention nulle part.

Concernant ta compréhension du problème, je dirais OUI... MAIS.

En fait plus j'y pense et plus je trouve ca bizarre.
Le type CHAR de Forms encapsule les types CHAR, VARCHAR2, NCHAR de la base donc je peux comprendre que ces types arrivent en simple CHAR pour la requête.
Par contre ce que je ne comprends pas, c'est la très mauvaise estimation des cardinalités de l'optimizer suivant le type CHAR et VARCHAR2. Hormis la gestion interne de la mémoire de ces types, il n'y a finalement pas tant de différence. La non-utilisation d'index peut apparaitre s'il y avait un cast implicite des données mais je l'aurais vu dans le calcul du plan.
Or là, il n'y a rien du tout.

Donc la solution du bug m'irait bien(pas par fainéantise )

Cdt

[mnitu]

Bref, la propriété en question a disparu entre le passage Forms 6 à Forms 9I. En plus je me suis trompé dans sa destination : elle servait seulement à la validation pour s’assurer que l’utilisateur a saisi N caractères ; ce que le Format Mask peut le faire.
Par contre comment sait tu que le type de la variable de liaison qui est utilisé dans la requête généré par Forms est char et non pas varchar ?

[kervoaz]

Dans les traces 10053 et dans les vues dynamiques, les variables sont du CHAR.
De plus dans TOAD par exemple, le problème se produit en changeant le type de la variable bindée.

cdt