[11g] Précision SELECT ou affichage ?

[lc2ms1978]

Bonsoir,

Sous TOAD je me connecte à une base Oracle 11g et j'exécute le code suivant :

Code :

1
2
3
4
5
6
CREATE TABLE toto (toto number(38,28));
 
INSERT INTO toto (toto) VALUES (123.12345678901234567 );
commit;
 
SELECT toto , to_char(toto) FROM toto;

Voici le résultat obtenu :

123.123456789012 | 123,12345678901234567

Donc en base les 17 chiffres après la virgule sont bien présents (puisque le to_char les restitue bien). Mais quand on l'affiche avec un select il n'y en a plus que 12 (il arrondi à la 12ième décimal et nous l'affiche).

C'est embétant parce que lorsque j'exécute cette même requete depuis mon ETL le comportement est identique. Donc au lieu de manipuler dans les traitements un réel avec 17 décimal, l'ETL ne travaille qu'avec 12 décimal...

Est ce qu'il y a un paramétrage de la base Oracle à faire pour que le SELECT n'arrondisse pas et remonte le nombre avec toutes ses décimales ?

Ou quelqu'un aurait il une autre piste sous Oracle ?

Merci d'avance

[McM]

Que donne un dump de toto ?

Code :

SELECT toto , dump(toto), to_char(toto) FROM toto;

[lc2ms1978]

Envoyé par McM

Que donne un dump de toto ?

Code :

SELECT toto , dump(toto), to_char(toto) FROM toto;

Merci pour ta réponse. Voici le résultat obtenu :

toto =123.123456789012
dump(toto) = 'Typ=2 Len=12: 194,2,24,13,35,57,79,91,13,35,57,71'
to_char(toto) = 123,123456789012345674567

Et j'obtiens le même résultat avec
SELECT toto , dump(toto,10), to_char(toto) FROM toto
et
SELECT toto , dump(toto,1010), to_char(toto) FROM toto

Je ne sais pas si je lis bien le résultat de cette fontion m'ais j'en déduis que sa longueur est sur 12 bytes. Je ne sais pas quelle longueur en caractère cela donne... Par ailleurs je ne comprends pas pourquoi le fait de rajouter le second paramètre ne me formate pas la sortie en nombre décimal.

[McM]

J'ai le même dump sous 9i, par contre mon select sous toad me ramène bien tous les chiffres.

[lc2ms1978]

Envoyé par McM

J'ai le même dump sous 9i, par contre mon select sous toad me ramène bien tous les chiffres.

A ton avis pourrait il s'agir d'un paramètrage de la base de données ?

De toute façon ca n'est pas un problème de stockage en base. C'est un problème de récupération de la donnée.

[McM]

Surement un bug de la version 11. Vérifie sur Oracle Support et ouvre un SR si nécessaire.
recherche "precision loss", tu trouveras quelques bugs corrigés dans des patchs.
exemple le n° 7489902

[mnitu]

Je ne pense pas qu'il s'agit d'un quelconque bug

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
Oracle DATABASE 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
WITH the Partitioning, OLAP, DATA Mining AND Real Application Testing options
 
SQL> SELECT toto FROM toto;
 
      TOTO
----------
123,123457
 
SQL> col toto format 999D9999999999999999999999999999
SQL> r
  1* SELECT toto FROM toto
 
                             TOTO
---------------------------------
 123,1234567890123456700000000000
 
SQL>

[McM]

Oui mais là, t'es sous sql+, c'est pas le top niveau rendu d'affichage.
"col toto format 999D9999999999999999999999999999" est une commande spécifique sqlplus
lc2etc parle de toad et de son ETL.

[Waldar]

Ça doit être du paramétrage dans TOAD mais il faut trouver où, j'ai regardé un peu mais je n'ai pas trouvé.

Ce qui est amusant dans TOAD, ou plutôt perturbant, c'est qu'en exécutant la requête unitairement (sélection + F9) :

TOTO                    TO_CHAR(TOTO)
----------------------- ---------------------
123.12345678901234567   123,12345678901234567

En lançant en tant que script (sélection + F5) :

      TOTO TO_CHAR(TOTO)                           
---------- ----------------------------------------
123.123457 123.12345678901234567                   

[mnitu]

Envoyé par McM

Oui mais là, t'es sous sql+, c'est pas le top niveau rendu d'affichage.
"col toto format 999D9999999999999999999999999999" est une commande spécifique sqlplus
lc2etc parle de toad et de son ETL.

Sqlplus, Toad ou autre outil qu’est-ce que ça change ?

[pacmann]

Salut,

Du même avis que Mnitu, mais pas de preuve ultime.

Quand tu demandes l'affichage, c'est un paramètre du client.
SQL*Plus : col format
Grid Toad : ??
=> A priori, on peut se dire que ce sont les mêmes données brutes qui sont transférées ?

D'ailleurs, quand dans toad tu exécutes avec F5, c'est exécuté en SQL*Plus (tu peux ajouter un col toto format(...) dans ta sélection Waldar).

Un truc à tenter, c'est de binder le select avec un autre langage (genre java), sur un type de données côté client assez gros, et utiliser une routine du client pour afficher.

Concernant l'ETL, c'est peut être dans l'étape intermédiaire "ETL" que tu perds la précision ? (Une variable intermédiaire trop petite dans l'outil ?)

[mnitu]

Code :

SELECT toto FROM toto

Une fois le plan élaboré Oracle va aller dans un bloc des données identifier l'enregistrement en question et va lire la séquencé des octets qui est mise en évidence par la fonction dump.
Si la commande est issue d'un outil comme sqlplus ou Toad etc. cette suite des octets représentant une valeur numérique est transformée dans une chaine des caractères lisible par l'opérateur humain, en utilisant éventuellement quelques paramètres qui gèrent l'affichage (numwidth, numformat, column sous sqlplus).
Et si cette même requête est exécuté par un langage de programmation 3G genre java ou c?
Dans ce cas il faut bien s'appeler qu'il y a une différence entre la précision que Oracle est capable de gérer et celle des variables numériques (float double) du langage choisies comme cible d'affectation

[lc2ms1978]

Envoyé par pacmann

Concernant l'ETL, c'est peut être dans l'étape intermédiaire "ETL" que tu perds la précision ? (Une variable intermédiaire trop petite dans l'outil ?)

Salut,
L'ETL utilisé est Informatica. L'objet (SQ) interroge juste la base et celle-ci lui remonte directement le champ mais pas avec toute la précision. Il n'y a aucune variable ou traitement intermédiaire.

[lc2ms1978]

Envoyé par mnitu

Code :

SELECT toto FROM toto

Une fois le plan élaboré Oracle va aller dans un bloc des données identifier l'enregistrement en question et va lire la séquencé des octets qui est mise en évidence par la fonction dump.
Si la commande est issue d'un outil comme sqlplus ou Toad etc. cette suite des octets représentant une valeur numérique est transformé dans une chaine des caractères lisible par l'opérateur humain, en utilisant éventuellement quelques paramètres qui gèrent l'affichage (numwidth, numformat, column sous sqlplus).
Et si cette même requête est exécuté par un langage de programmation 3G genre java ou c?
Dans ce cas il faut bien s'appeler qu'il y a un différence entre la précision que Oracle est capable de gérer et celle des variables numériques (float double) du langage choisies comme cible d'affectation.

Je n'ai pas tout compris lol. Mais bon, la variable numerique sous informatica est paramétrable comme bon nous sembles pour affecter la précision exacte souhaitée. Et je l'ai définie de façon identique à ORACLE c'est à dire 17 précisions. En fait j'ai constaté que le problème apparaissait avec l'affectation sous Informatica. C'est vraiment ce qui est envoyé par oracle qui pose problème.

Par contre dump(toto) = 'Typ=2 Len=12:194,2,24,13,35,57,79,91,13,35,57,71'

Est ce que Len représente la longueur ?

[McM]

len représente la longueur du codage interne
Chaque nombre (en dehors du 194) représente 2 chiffres. Le second est égal au chiffre + 1

194,2,24,13,35,57,79,91,13,35,57,71
02 24 13 35 57 79 91 13 35 57 71
01 23 12 34 56 78 90 12 34 56 70

tu retrouves ton nombre
123.12345678901234567

[skuatamad]

C'est quand même un problème client, donc informatica
Utilisez vous le mode High precision ?
http://www.element61.be/e/resourc-de...?ResourceId=57

High precision
The high precision mode will allow using decimals up to a precision of 28 digits. Using this kind of precision will result in a performance penalty in reading and writing data. It is therefore recommended to disable high precision when not really needed. When turned off, decimals are converted to doubles that have a precision up to 15 digits.

[lc2ms1978]

Envoyé par skuatamad

C'est quand même un problème client, donc informatica
Utilisez vous le mode High precision ?
http://www.element61.be/e/resourc-de...?ResourceId=57

Oui j'ai déjà activé l'option High precision

[lc2ms1978]

Envoyé par skuatamad

C'est quand même un problème client, donc informatica
Utilisez vous le mode High precision ?
http://www.element61.be/e/resourc-de...?ResourceId=57

Pourquoi pensez vous qu'il s'agisse d'un problème du client ?

[skuatamad]

Envoyé par lc2ms1978

Pourquoi pensez vous qu'il s'agisse d'un problème du client ?

Les différents exemple sur toad et sqlplus le montre, et pour informatica ça peut être un problème de conversion implicite comme le mentionnait mnitu.

Quelques recherches montrent qu'en fonction de la version d'informatica il y a une limitation sur le type decimal à 28 :
https://community.informatica.com/thread/22623
http://datawarehouse.ittoolbox.com/g...nscale-1748043

Je ne connais pas informatica mais je pense qu'il faut chercher dans ce sens.
La colonne number(38,28) est elle réellement correctement dimensionnée ?

[lc2ms1978]

Envoyé par skuatamad

La colonne number(38,28) est elle réellement correctement dimensionnée ?

En tous cas moi je l'ai définit de la sorte aussi bien sous oracle qu'informatica.