Discussion :

[IndianaAngus]

Bonjour,

Je rencontre un problème étrange, lorsque je spool le résultat d'un requête en AL32UTF8, cela prend 31 secondes. Lorsque je spool en WE8ISO8859P15, cela prend 2 secondes. Le character set de la base de données est UTF8.

Voici un exemple:

Code sql :

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
20
21
22
23
24
25
26
27
28
29
30
 
1. création de la table
CREATE TABLE source_data
 ( x, y, z
 , CONSTRAINT source_data_pk
      PRIMARY KEY (x,y,z)
 )
 AS
    SELECT ROWNUM           AS x
    ,      RPAD('x',50,'x') AS y
    ,      RPAD('y',50,'y') AS z
    FROM   dual
    CONNECT BY ROWNUM <= 100000;
 
2. query.sql
 
set pages 0
set heading off
set feed off
set pause off
set termout off
set linesize 32767
set longc 6000000
set long 6000000
set trimout on
set trimspool on
set timing on
spool test.log;
select * from source_data;
exit;

le test en lui même:
1. export NLS_LANG=AMERICAN_AMERICA.AL32UTF8
sqlplus
@query.sql
31 secondes elapsed

2.export NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P15
sqlplus
@query.sql
2 secondes elapsed....

La majorité du temps est passé en "SQL*Net message from client". Est ce que c'est à cause d'UTF8? Qu'est ce qui fait que l'on passe de 2 à 31 secondes pour la même requête?
Si vous avez une idée du pourquoi du comment je suis preneur.

Merci

[al1_24]

Obtiens-tu les mêmes durées en inversant l'ordre d'exécution des commandes ? (WE8ISO8859P15 avant AL32UTF8)

[IndianaAngus]

oui, on peut le faire dans le sens que l'on veux, c'est toujours le même résultat. J'ai refait un test et sans le spool c'est aussi long. Donc ce n'est pas ça le problème.

Autre test, en modifiant la linesize à 5000, je descends à 5.15s vs 0.57. C'est plus rapide mais ca reste quand même une sacré différence... La seule explication que je peux avoir c'est que UTF8 est multibyte et que donc ca prend plus de temps à traiter...

[Ikebukuro]

Ne mélange pas tes tests : le character set d'un côté puis, une fois OK, le linesize mais si tu fais varier deux paramètres, le résultat sera trop dur à interpréter.

[vanagreg]

Bonjour,

Quelle est la version de la base de données?

[Ikebukuro]

Mais, hé, dans le premier SELECT, les données sont certainement sur le disque dur suite à la création de la table alors que pour le deuxième je pense qu'ils sont en mémoire, d'où les temps de réponse très différents.
Peux-tu faire la chose suivante, si tu es sur une base non de prod et que cela ne gêne personne: tu vides le buffer cache pour remettre tous les blocs sur disque dur puis tu relances le .sql

Code :

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

1
2
3
4
5
Linux> export NLS_LANG=AMERICAN_AMERICA.AL32UTF8
Linux> sqlplus user/password
sqlplus> set timing on
sqlplus> alter system flush buffer_cache;
sqlplus> @query.sql;

Puis, test 2 :

Code :

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

1
2
3
4
5
Linux> export NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P15
Linux> sqlplus user/password
sqlplus> set timing on
sqlplus> alter system flush buffer_cache;
sqlplus> @query.sql;

Quels sont les temps obtenus?

[skuatamad]

Pour rappel, sqlplus n'est qu'un client de la base de données oracle, ici on mesure donc le fonctionnement du client avec l'UTF8.

Le facteur le plus impactant en terme de performance c'est le LINESIZE.

Le paramètre LINESIZE impacte la quantité de mémoire nécessaire au traitement, et j'imagine que l'affichage d'une ligne en UTF8 nécessite de réserver plus de mémoire que pour l'affichage d'une ligne en ISO.
Plus le traitement est gourmant en ram, plus le traitement est long.

https://docs.oracle.com/cd/B19306_01...b14357/ch8.htm

SET LINESIZE

SET LINESIZE sets the total number of characters that SQL*Plus displays on one line before beginning a new line.

Keep LINESIZE as small as possible to avoid extra memory allocations and memory copying.

However, if LINESIZE is too small, columns that cannot fit next to each other are put on separate lines. This may reduce performance significantly.

Par contre, le paramétrage du NLS_LANG n'a pas rien à voir avec les performances, mais doit correspondre au jeu de caractères du client :
https://www.oracle.com/fr/database/t...-nls-lang.html

[Ikebukuro]

Tout à fait, le paramètre LINESIZE est très important mais comme ici il ne change pas sa taille entre les deux tests, l'origine du pb n'est pas là.
En plus il l'a mis à 32767... sachant que sur un écran de 30 pouces, tu dois avoir 300 caractères d'affichables, donc cherchons ailleurs.

Ah, autre point, tu dis : "La majorité du temps est passé en "SQL*Net message from client"", ce qui pourrait indiquera beaucoup d'aller-retours entre le client et le serveur.
Que vaut sous SQL*Plus le paramètre ARRAYSIZE? S'il vaut 15 (valeur par défaut), essaye de le mettre à 200 ou 300 pour améliorer les perfs, il y aura ainsi plus de données envoyées entre les deux systèmes à chaque échange.

[IndianaAngus]

Merci pour vos réponses.
La base est une 11.2.0.4 et je me connecte directement depuis le serveur (mais en fait ca change rien même si je suis sur une machine distante).
Comme évoqué, je peux faire le test 10 fois, lorsque je met NLS_LANG à UTF8, c'est plus lent. Ce n'est donc pas une questions de données en cache ou sur le disque dur.
Si j'ajoute des caractère accentué, ils n'apparaissent pas correctement en WE8ISO8859P15 et donc c'est pour cela que je mets en UTF8. J'ai aussi essayé d'augmenter le Arraysize mais ca ne change rien.
Si je ne défini pas de NLS_LANG, et bien mes "é" deviennent "e". Je vais creuser côté NLS_LANG.

Sinon, en faisant un petit pl/sql avec utl_file, je n'ai aucun problème.

[Ikebukuro]

Dans ce cas là, fait sous SQL*Plus un SET AUTOTRACE ON et relance ton SELECT dans les deux configurations et poste ici le résultat : le plan d'exécution et les indicateurs comme Consistents Gets etc etc.