Le tri de l' insert append ?

Bonjour
Le mode direct-path bypasse la mémoire.
Alors comment et où se fait le tri ? Dans le TEMP ?

Code:

---

insert /*+ append */ select ...order by...

---

Sinon l insert prends toujours 20 min pour s'exécuter avec ou sans append !!!
Est ce normal ?
Merci pour votre précision.

Exécutez votre requête avec autotrace et vous allez avoir la réponse concernant le tri. Mais le tri est inutile dans ce cas.
Le hint Append est ignoré dans certains situations (exemple présence des clés étrangères). Pour une vérification rapide si vous pouvez interroger la table sans faire le commit le hint a été ignoré.

Bonjour,

C'est uniquement lors de l'écriture que la mémoire est bypassée: écriture directe dans les fichiers, sans passer par le cache.
Le select lui va lire via le cache (cas du serial direct path read) et trier en utilisant la mémoire de la session.

Citation:

---

Envoyé par mnitu

Mais le tri est inutile dans ce cas.

---

Non ! C'est même une très bonne idée de réfléchir au tri des données lorsqu'on charge une table. L'ordre physique va être déterminant pour l'efficacité des accès par index.

Cordialement,
Franck.

Citation:

---

Envoyé par pachot

C'est même une très bonne idée de réfléchir au tri des données lorsqu'on charge une table. L'ordre physique va être déterminant pour l'efficacité des accès par index.

---

Oui c'est vrai. Mais malheureusement cela ne peut être valable que pour un seul index. En effet on ne peut trier une table que d'une seule manière si bien que l'on ne peut pas avoir plusieurs indexes sur la même table avec un bon clustering factor. Il est parfois même possible que le clustering factor d'un index i1(a,b) soit catastrophique alors que celui de l'index i2(a) est très bon.

Mais, c'est vrai aussi qu'en mode d'insertion conventionnel si vous avez un index i1(a) et un index i2(b) et si vous utilisez insert/select order by a alors l'insertion dans l'index i1 générera moins de logical I/O que celle sur b. Et vice versa si vous inversez l'order by.

Mais en mode direct path load, les indexes étant maintenus en bulk collect à la fin, l'order by a moins d'éffet sur les logical I/O lors de l'insert.

Vous trouverez ici un exemple illustrant ce qui précède

Comment vous expliquer que je gagne rien en temps avec le mode direct-path alors que je vois bien LOAD AS SELECT dans le plan ? Conditions manquantes pour ce mode ?

Une explication possible serait que l'ORDER BY soit beaucoup plus coûteux que le temps l'insertion.
Que raconte la trace ?

Citation:

---

Envoyé par Waldar

Une explication possible serait que l'ORDER BY soit beaucoup plus coûteux que le temps l'insertion.
Que raconte la trace ?

---

Le plan est "presque" le même avec et sans APPEND (avec append le LOAD AS SELECT apparaît dans le plan).
Je me dis qu'il y a quelque chose qui freine cette technique dans mon cas ????

Avez vous faite une trace sql étendue ?