Différence entre le conventional path et le direct path

**Francky44003** · 06/11/2011, 12h47

Bonjour à tous, je fais appelle a vous car j’apprends à utiliser l’exécutable SQL Loader . Je sais a quoi il sert , comment celui fonctionne.
Mais il y a 2 notions qui me restent en travers de la gorge.
J'ai appris qu'il existait 2 maniérés de charger les données situés dans un fichier plat : le conventional path et le direct path.

Je n'arrive pas a comprendre ces 2 notions, quelles sont les différences il y a entre eux et lequel est le plus recommandé lors du chargement d'enregistrement.

J'aimerai que vous m'aidiez à comprendre ces 2 méthodes de chargement.

J'ai également un autre probleme.
J'ai un fichier STREAMIN.CTL qui contient les informations pour les besoins du chargement. Mais lorsque je lance la commande
sqlldr userid=xxxx/xxxx control=STREAMIN.CTL
Oracle me dit qu'il y a une erreur à la ligne 6 et je ne comprend pas pourquoi il me dit qu'il y a une erreur.
Cette erreur pour etre precis :

SQL*LOADER-350 : Synthax error at line 6
Expecting Keywoard INTO, found "".

Voici le contenu de ce controlfile :

Code :

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

1
2
3
4
5
6
load data
infile 'STREAMIN.DAT' "str '\n'"
append
into table dtp_test 
fields terminated by ','
(username, user_id)

Je vous remercie d'avance pour avoir prit le temps de me répondre

**IndianaAngus** · 10/11/2011, 14h07

conventional path: utilise du sql standard pour insérer les données

direct path: tes données en data block oracle et les écrit directement dans les fichiers de base de données. Un direct load peut écrire à une vitesse très proche de celle des disque dur puisq'il ne prend pas en compte les autres users pour les ressources dispo.

Il me semble également que le conventionnal path écrit dans l'undo tablespace et que donc tu peux faire un rollback. Le direct load ne permet pas cela.

**pachot** · 10/11/2011, 21h59

Bonjour,

L'idée du direct-path, c'est que le process lié à ta session va directement écrire dans les datafiles au lieu d'écrire en mémoire dans le buffer cache pour qu'ensuite db writer écrive en background dans les datafiles.

Du coup, il n'y a pas la même gestion de la concurrence d'accès puisqu'on ne passe pas par une structure partagée par tous les process.
-> inconvénient: Oracle doit verrouiller tout le segment (table ou partition) pour qu'il n'y ait pas de modifications concurrentes.
-> avantage: plus rapide

Et il n'y a pas non plus la même génération d'undo.
-> inconvénient: Oracle écrit uniquement dans des tous nouveaux blocs pas encore formatés, qui sont au bout de toutes les données existantes: ceux qui sont au-dessus du High Water Mark. Et donc pas de réutilisation de l'espace libre qu'il peut y avoir en dessous.
-> avantage: plus rapide car presque plus d'undo et un peu moins de redo (voire presque plus sil la table est en NOLOGGING ou l'instance en NOARCHIVELOG).

Envoyé par IndianaAngus

Il me semble également que le conventionnal path écrit dans l'undo tablespace et que donc tu peux faire un rollback. Le direct load ne permet pas cela.

Si, bien sûr on peut faire un rollback. Vu qu'on écrit au bout du fichier, pour rollbacker il suffit de revenir au High Water Mark d'avant. C'est un autre avantage: le rollback est trés rapide. Le commit fait juste avancer le High Water Mark pour que les nouveaux blocks soient pris en compte.

L'idée de Direct-Path, c'est un peu: je charge un gros volume et je suis tout seul à faire des modifications dans cette table, du coup je ne m'encombre pas avec la gestion de la concurrence et la réutilisation de l'espace libre. Et je sais qu'il n'y a pas d'espace libéré par des delete parce que pour vider la table je fais des truncate (qui eux baissent le High Water Mark).

Une analogie à 2 balles: un groupe de 50 personnes doivent voyager en train. En conventional path chacun va se chercher une place libre dans une voiture. On allonge le train que lorsqu'il n'y a plus de place libre. Alors qu'en direct-path on va tout de suite rajouter une voiture au bout du train et ils montent tous dedans.

Cordialement,
Franck.