Mot Cle "N" dans ma requete SQL

Version imprimable

17/07/2009, 09h41
rgarnier

Mot Cle "N" dans ma requete SQL

Bonjour,

J'utilise un logiciel qui me génère automatiquement la requete SQL (Crystal Report en l'occurrence).

Le pb est qu'il me génère des requetes avec des N dans les clauses where, ce qui d'après ce que j'ai pur trouver qu'il ne doit pas utiliser les indexs (en tout cas, le temps d'execution de la requete est /50 car pas de full scan).

Exemple :

Citation:

SELECT NOM FROM CLIENTS WHERE VILLE = N'LONDRES'

Plusieurs questions : ou trouver de la donc sur ce mot clé ? peut-on passer outre ?
Bref, comment virer ça .....

D'avance merci.
17/07/2009, 09h47
pifor

Il s'agit d'un marqueur "jeu de caractères National": http://download.oracle.com/docs/cd/B...003.htm#i42617
17/07/2009, 15h51
rgarnier

Ok, merci de l'info. Je vais essayer de voir comment m'en passer .....

tu définis tes colonnes en nvarchar2...

Code:

1
2
3
4
5
6
7
8
9
10
11
12
SQL> create table clients(nom nvarchar2(40), ville nvarchar2(40))
Table created.
SQL> create index lsc_i on clients(ville)
Index created.
SQL> exec dbms_stats.gather_table_stats(user,'CLIENTS',cascade=>true)
PL/SQL procedure successfully completed.
SQL> SELECT NOM FROM CLIENTS WHERE VILLE = N'LONDRES'
Execution Plan
----------------------------------------------------------
   0       SELECT STATEMENT Optimizer Mode=ALL_ROWS (Cost=1 Card=1 
   1    0    TABLE ACCESS BY INDEX ROWID SCOTT.CLIENTS (Cost=1 
   2    1      INDEX RANGE SCAN SCOTT.LSC_I (Cost=1 Card=1)

20/07/2009, 16h40
rgarnier

Merci pour ta solution, mais mon pb est double :
- je ne suis pas maitre de la construction de la requete (donc, l'ajout du N est obligatoire)
- je ne suis pas maitre de la structure de la bd (VARCHAR et pas NVARCHAR)

n'y aurait-il pas moyen de mettre un paramètre qui dirait de ne pas s'occuper du N ???? (Car le full scan sur mes table de milliers d'enreg pénalise énormément le serveur ...)

Merci de votre aide.
20/07/2009, 17h11
mnitu

Citation:

Envoyé par rgarnier

...n'y aurait-il pas moyen de mettre un paramètre qui dirait de ne pas s'occuper du N ???? ...

Ce paramètre devrait exister plutôt du coté de Crystal Report vu que c’est lui qui génère les requêtes.

bon, tu peux créer un FBI

Code:

1
2
3
4
5
6
7
8
9
10
11
12
SQL> create table clients(nom varchar2(40), ville varchar2(40))
Table created.
SQL> create index lsc_i on clients(to_nchar(ville))
Index created.
SQL> exec dbms_stats.gather_table_stats(user,'CLIENTS',cascade=>true)
PL/SQL procedure successfully completed.
SQL> SELECT NOM FROM CLIENTS WHERE VILLE = N'LONDRES'
Execution Plan
----------------------------------------------------------
   0       SELECT STATEMENT Optimizer Mode=ALL_ROWS (Cost=1 Card=1 
   1    0    TABLE ACCESS BY INDEX ROWID SCOTT.CLIENTS (Cost=1 
   2    1      INDEX RANGE SCAN SCOTT.LSC_I (Cost=1 Card=1)

20/07/2009, 17h20
laurentschneider

Citation:

Envoyé par mnitu

Ce paramètre devrait exister plutôt du coté de Crystal Report vu que c’est lui qui génère les requêtes.

oui, ça semble logique ça :ccool:
21/07/2009, 08h25
rgarnier

OK, merci pour les tuyaux.

P.S. : concernant C Report, il est bien évident qu'il pourrait mieux faire. A titre personnel et pour comprendre le phénomène, pouvez-vous me dire l'intéret d'une telle focntion, sachant que cela a pour effet de bord (énooorme en perte de perf) de ne pas utiliser les index ?

Citation:

Envoyé par rgarnier

...A titre personnel et pour comprendre le phénomène, pouvez-vous me dire l'intéret d'une telle focntion, sachant que cela a pour effet de bord (énooorme en perte de perf) de ne pas utiliser les index ?

C’est n’est pas la fonction mais, la coercition qui fait sauter l’index. Regardez les section FILTER/ACCES.

Code:

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
31
32
33
34
35
36
37
 
SQL> select * from dept where loc = N'BOSTON';
 
Plan d'exÚcution
----------------------------------------------------------
Plan hash value: 3383998547
 
--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |     1 |    20 |     3   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| DEPT |     1 |    20 |     3   (0)| 00:00:01 |
--------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   1 - filter(SYS_OP_C2C("LOC")=U'BOSTON')
 
SQL> select * from dept where loc = translate(N'BOSTON' using CHAR_CS);
 
Plan d'exÚcution
----------------------------------------------------------
Plan hash value: 1731615412
 
---------------------------------------------------------------------------------------
| Id  | Operation                   | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |         |     1 |    20 |     2   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| DEPT    |     1 |    20 |     2   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | IX_DEPT |     1 |       |     1   (0)| 00:00:01 |
---------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   2 - access("LOC"='BOSTON')

21/07/2009, 10h37
laurentschneider

Citation:

Envoyé par rgarnier

l'intéret d'une telle focntion

Unicode?
21/07/2009, 10h40
rgarnier

Non, pas d'unicode (utf16).

Merci pour vos infos.
21/07/2009, 11h09
laurentschneider

je dis, l'intérêt de cette fonction c'est d'avoir UNICODE...

Je te conseille de contacter le support de CR pour pouvoir générer du code sans N'