Oracle insensible à la casse<pourquoi?>

[spring.time]

Salut

On dit que le SGBD Oracle est insensible à la casse, par exemple si on écrit une requête avec des noms des tables et des mots clés SQL en minuscule ou majuscule, ça revient à la même chose, puisque Oracle les mets tous en Majuscule au niveau de dictionnaire de données.

Qu'est ce que cela veut dire? sachant bien que chaque requête exécutée a son propre plan d’exécution, et une requête en majuscule a un plan d’exécution différent d'une requête écrite en minuscule?


je serais reconnaissante si vous m'éclaircissiez ce point!

[mnitu]

Ce n’est pas toute à fait vrai. L’utilisation des guillemets permet de préserver la case!

Ce n’est pas parce que la requête est écrite en majuscule qu’elle aurait un plan d’exécution différente d’une requête écrite avec des minuscules. Ce que vous devez comprendre c’est que chaque requête envoyée au serveur est recherchée d’abord dans le shared pool, une zone de mémoire partagée et que cette recherche se fait en calculant une clé hash à partir du texte de la requête. Si la requête est trouvée et si l’environnement d’exécution est identique alors Oracle réutilise son plan d’exécution : c’est un « soft parse ». Si non il y aura le calcul complet du plan d’exécution, un hard parse, ce qui est une opération assez coûteuse en termes des ressources nécessaires.

[Mohamed.Houri]

En plus de ce qui a été écrit par Marius, j'ajouterai ceci

Dans ce qu’on appelle communément en anglais ‘Shared Cursors’ il convient d’en distinguer deux types de curseur (a) parent cursor (b) child cursor
Le résultat d’un parse est la présence de ces deux curseurs dans le shared pool (dans le library cache plus précisément). Le premier curseur concerne le partage du sql texte. C’est pourquoi, pour qu’un code SQL puisse réutiliser un ‘parent cursor’ disponible dans le ‘shared pool’ il faut que le texte de cet SQL soit exactement identique à celui déjà présent dans le shared pool. Voici un exemple du premier cas (parent cursor):

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
mhouri> SELECT * FROM emp WHERE ename ='Mohamed';
 
no rows selected
 
mhouri> SELECT * FROM emp WHERE ename ='Mohamed';
 
no rows selected
 
mhouri> SELECT * FROM Emp WHERE Ename ='Mohamed';
 
no rows selected
 
mhouri> SELECT sql_id, substr(sql_text,1,50), executions
  2  FROM v$sql
  3  WHERE sql_text LIKE '%Moh%';
 
SQL_ID        SUBSTR(SQL_TEXT,1,50)                              EXECUTIONS     
------------- -------------------------------------------------- ----------     
9pbvb190ds89k SELECT * FROM Emp WHERE Ename ='Mohamed'                    1     
c65atck5bnzuc SELECT * FROM emp WHERE ename ='Mohamed'                    2

Où l’on voit bien que les deux premiers sql ont bien été partagés et réutilisés (executions = 2) alors que le denier n’a pas pu réutiliser le curseur qui se trouve dans le cache à cause de la différence dans le SQL texte (Emp au lieu de emp et Ename au lieu de ename).

Le deuxième cas (child cursor) concerne le partage du plan d’exécution. Voici un exemple:

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
 
mhouri> SELECT count(1) FROM emp;
 
  COUNT(1)                                                                      
----------                                                                      
        15                                                                      
 
mhouri> ALTER session SET optimizer_mode =ALL_ROWS;
 
Session altered.
 
mhouri> SELECT count(1) FROM emp;
 
  COUNT(1)                                                                      
----------                                                                      
        15                                                                      
 
 
mhouri> SELECT sql_id, child_number, substr(sql_text,1,30), optimizer_mode
  2  FROM v$sql
  3  WHERE sql_text LIKE '%count(1)%';
 
SQL_ID        CHILD_NUMBER SUBSTR(SQL_TEXT,1,30)          OPTIMIZER_            
------------- ------------ ------------------------------ ----------            
1t385yygmyypw            0 SELECT count(1) FROM emp       FIRST_ROWS            
1t385yygmyypw            1 SELECT count(1) FROM emp       ALL_ROWS

Où l’on voit bien que deux sql identiques ont été exécutes deux fois l’un avec le mode FIRST_ROWS et l’autre avec le mode ALL_ROWS. A cause de ce changement de paramètre de l’optimisateur, les deux selects identiques dans le texte partage le même curseur père (1t385yygmyypw) mais ont deux curseur fils différent (child_number 0 et 1).

C'est pourquoi il faut s'assurer d'utiliser le même texte afin de ne pas remplir le shared pool par du texte non réutilisable. En pratique c'est le même texte que l'on utilise toujours car nous ne développons pas une application où nous tapons constamment notre code à la main, par contre ce sont les variables qui changent entre les différences exécutions, et c'est là où intervient l'importance de l’utilisation des bind variables surtout dans un environnement OLTP.