[11g] Précision SELECT ou affichage ?

**lc2ms1978** · 03/02/2012, 18h27

Bonsoir,

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

Code :

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

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** · 04/02/2012, 22h03

Que donne un dump de toto ?

Code :

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

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

**lc2ms1978** · 06/02/2012, 10h30

Envoyé par McM

Que donne un dump de toto ?

Code :

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

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** · 06/02/2012, 11h02

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

**lc2ms1978** · 06/02/2012, 12h33

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** · 06/02/2012, 13h17

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** · 06/02/2012, 14h14

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

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
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** · 06/02/2012, 14h40

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** · 06/02/2012, 15h21

Ç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** · 06/02/2012, 15h42

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** · 06/02/2012, 17h16

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** · 06/02/2012, 21h56

Code :

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

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** · 07/02/2012, 11h04

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** · 07/02/2012, 11h12

Envoyé par mnitu

Code :

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

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** · 07/02/2012, 11h20

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** · 07/02/2012, 12h13

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** · 07/02/2012, 12h29

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** · 07/02/2012, 12h31

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** · 07/02/2012, 14h21

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 ?