Discussion :

[laurentschneider]

pour les perf, ça dépend, utiliser une bind variable ou un curseur partagé peut avoir des effets négatifs, surtout en datawarehouse, par exemple tu faire

Code :

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

1
2
 
select * from emp where deptno=40;

et bien si 0% ou 99% des employés sont dans le departement 40, ça change tout. De bons histogrammes et des littérals, c'est parfois mieux. Il existe aussi dans les versions récentes une valeur de SIMILAR, qui peut profiter des histogrammes.

Pour les effets pervers, rien ne vaut une petite démo !

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
20
21
22
23
24
25
26
27
 
 
SQL> alter session set cursor_sharing='FORCE';
 
Session altered.
 
SQL> select substr(DNAME,1,1), substr(LOC,1,1) from dept;
 
SUBSTR(DNAME,1 SUBSTR(LOC,1,
-------------- -------------
A              N
R              D
S              C
O              B
 
SQL> alter session set cursor_sharing='EXACT';
 
Session altered.
 
SQL> select substr(DNAME,1,1), substr(LOC,1,1) from dept;
 
S S
- -
A N
R D
S C
O B

si la 2e requête retourne des colonnes de 1 caractère, ce n'est pas le cas dans la 1e. Bon, j'ai emprunté cet exemple à tom kyte.

Mais globalement, cursor_sharing est un remède (très efficace j'en conviens )contre une mauvais utilisation des binds, et pas un paramètre a utiliser dans toutes les situations.

Il y a sans doute d'autres effets pervers, avec d'autres interfaces que sqlplus.

A+
Laurent

[laurentschneider]

bon, j'ai peut-être eu un avis trop tranché.

Dans l'exemple, il n'y a que des INSERT, et Remy proposait seulement un ALTER SESSION (pas system). Donc je pense après relecture que c'est un bon conseil !

[laurentschneider]

petite demo pour montrer que l'exemple de Remy a l'air de fonctionner :

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
20
21
22
23
24
25
26
 
SQL> alter session set  cursor_sharing='FORCE';
 
Session altered.
 
SQL> alter system flush shared_pool;
 
System altered.
 
SQL> select sql_text from v$sql where sql_text like lower('% TESTCURSOR %');
 
no rows selected
 
SQL> insert /*+ testcursor */ into t values(1);
 
1 row created.
 
SQL> insert /*+ testcursor */ into t values(2);
 
1 row created.
 
SQL> select sql_text from v$sql where sql_text like lower('% TESTCURSOR %');
 
SQL_TEXT
-------------------------------------
insert /*+ testcursor */ into t values(:"SYS_B_0")

seulement un curseur ouvert et pas deux !

[remi4444]

ouuufff me voilà rassuré!

Je suis d'accord avec toi, si par défaut le paramètre système est toujours à EXACT, c'est bien qu'il doit y avoir une raison et que dans un cas général, il y a plus d'inconveniants que d'avantages. En particulier parceque ça va faire un pré-parsing sur toutes les requêtes qui n'a souvent pas lieu d'être et donc qui bouffe des ressources pour rien...

[Oraman]

j'ai bien aimé cette discussion ça à permis même de discuter à propos d'autres détails que je trouve trés interessant. j'éspère tout de même que ça va aider notre ami Justin. et surtout qu'il nous donne de ces nouvelles concernant la solution final qu'il a adopter et qu'est ce que ça a donné côté performance

[JUSTIN Loïc]

Moi, aussi j'ai énormément apprécié et appris dans cette discussion, je ne suis pas déçu de l'avoir posée. Je vous tiendrai au courant de l'avancé de mes « tergiversations ». Si cela ne vous dérange pas bien sure

[remi4444]

Si tu as la main sur ton fichier d'injection et ta machine oracle, et que tu es sûr de l'intégrité de tes données, le SQL*LOADER en mode DIRECT=TRUE sera d'une efficacité redoutable, tu n'en croieras pas tes yeux!

Dernière modification par laurentschneider Aujourd'hui à 16h01. Motif: je vais vraiment me souvenir de cette astuce, finalement ce partage de curseur peut se révéler bien utile pour charger des données !!!

Alors là si je t'ai appris quelque chose cet apres-midi, mon égo est tout revigoré pour le week-end!

[JUSTIN Loïc]

Bonjour,
Voila comme promis, j' ai effectué des tests de chargements sur ma base 10Gr2 avec sqlldr. Grace à l'excellent article sur le sujet de JAOUAD à cette adresse http://jaouad.developpez.com/sqlldr/

J'ai fait le test sur ma table qui mettait 27 min pour 104997 enregistrements avec la methode INSERT INTO . Ce test a été fait avec un echantillon de 31476 enregistrements qui represente 1/3 de la table .
Resultat:
Temps ecoulé : 00:00:04.65
Temps processeur : 00:00:00.54

Encore merci pour votre aide

[remi4444]

ça te va ou tu trouves ça encore trop long ?

[JUSTIN Loïc]

Bonjour,

Il faudrait etre difficile pour dire que c'est encore trop long .
Pour repondre à une question (virtuelle ) que tu avais posté, j'utilise bien le mode direct=y.

[remi4444]

oui je m'étais trompé dans la lecture des temps, je croyais que c'était 4 min, d'ou ma déception et la question qui allait avec...
Le sql-loader en mode direct est tellement puissant par rapport au reste que meme lorsqu'on veut transferer en masse des données vers une table avec pas mal d'index, il est plus efficace de faire un dump sur fichier plat + sql*loader que de faire un "insert into ... select ... ". La contre-partie est que:
- l'acces aux données de la table lève une erreur pendant le load
- si les données insérées ne sont pas conformes aux contraintes de la table, tout est cassé...

[free people]

Bonjour,

je n'ai pas lu tout le thread mais je voudrais réagir sur les bonnes interventions de Rémi :

Le sql-loader en mode direct est tellement puissant

La seule limitation de cette option est que l'insertion se fait au dessus du HWM. Pas le HWM de la table mais celle du fichier de données
Cette petite précision peut avoir parfois des conséquences importantes en termes de stockages et
de performances

[JUSTIN Loïc]

Bonjour,
petite precision, je site l'aticle de JAOUAD concernant le mode direct= y

Attention, L'option direct peut être également comporter quelques effets de bord. En effet lors de l'insertion par ce mode Oracle ne va pas chercher à déterminer quels sont les blocs libres mais va insérer les données au-dessus du High Water Mark (HWM). C'est pourquoi il faut, lorsque nous insérons les données dans une table de travail, utiliser l'option TRUNCATE.

Les tests ont été fait avec cette option.

[remi4444]

A propos de tes tests et bien que les perf n'ont rien à voir avec sql*loader, est-ce que tu as essayé le "CURSOR_SHARING = FORCE" ?

C'est juste pour faire avancer la science....

[JUSTIN Loïc]

Non, je suis désolé je n'ai pas encore testé.
Etant plongé corps et ame sur sqlload
Comme je pouvais encore me le permettre, je viens de lancer un test avec "CURSOR_SHARING= FORCE"
Resultat:
Le temps d'insertion avec cursor_sharing=FORCE est de 00:05:50 au lieu des 27 min. (je n'ai rien changé d'autres)

Voilà ...Voilà

[remi4444]

Merci beaucoup d'avoir pris du temps pour faire le test ! ton exemple était vraiment le cas type ou cette clause pouvait être efficace mais je ne m'attendais pas à un tel facteur d'amélioration, (j'aurais dit *2 et non *5) c'est extrèmement instructif...