oui mais les incovenients sont les suivants:
- insertion après HWm donc les blocs vides sous le HWM ne seront jamais remplis sauf si on réorganise la table
- la table est lockée pendant l'insert...
Type: Messages; Utilisateur: farenheiit
oui mais les incovenients sont les suivants:
- insertion après HWm donc les blocs vides sous le HWM ne seront jamais remplis sauf si on réorganise la table
- la table est lockée pendant l'insert...
comment ça?
Effectivement j'ai lancé l'insert en rajoutant un order by sur NUBCR et NUFCR dans le select et la requête s'execute en 4 minutes.
C'est toi le plus fort Francky :ccool:
merci bcp de t'être...
Effectivement avec le append je suis à 2 minutes aussi.
Voici mon insert:
INSERT INTO ITPCRO...
t'as pas un exemple ? j'ai du mal...
comment vois tu l'ordre des enregistrements dans la table ?
Peux tu expliquer le principe du clustering_factor?
J'ai exécuté l'insertion en mode parallel 4 et l'insert passe à 2 minutes => extraordinaire :lol:
mais je veux comprendre pourquoi mon index 2 génère autant de logical reads...
:(
Finalement on m'a fourni un nouvelle base de test.
J'ai bien maintenant mes 3 indexes.
L'insert met plus de 30 minutes et j'ai toujours 14 fois plus logical reads sur l'index 2 que sur l'index 1 et...
Quand tu parles des stats de l'index ce sont les stats dans v$segment_statistics ?
Si oui les nombres que je t'ai donné correspondent au differentiel entre avant et après l'insert.
qu'entends tu...
Sur ma table j'ai actuellement 2 indexes sur 3 (l'indexe numero 2 et l'index numéro3).
J'ai essayé de recréer l'index numero1 mais j'obtiens une erreur ORA-00603 ORACLE server session terminated...
pas bête toi!!!!
bon comme la création des indexes dure énormément de temps je vais lancer ça ce soir et effectuer la requête lundi.
Bon week end
Ok ça m'a l'air pas mal comme idée mais le problème c'est que la valeur des logical reads va se cumuler avec sa valeur précédente. comment faire pour réinitialiser ces valeurs sans avoir à redémarrer...
Et tu crois que c'est ça qui explique qu'avec l'index numero 2 basé sur deux champs number(10) mettent 20 fois plus de temps qu'avec l'index numero 1 basé sur 2 champs également (une date et un...
Donc on ne peut pas avoir plus de 4 comme niveau de profondeur si seul le bloc racine peut spliter.
Qu'entends tu par taille des entrées d'indexes?
je viens d'essayer l'insert avec juste...
merci franck,
tes explications sont super par contre ton dernier paragraphe sur l'équilibre des indexes je n'ai pas trop compris ce que t'as voulu dire. pour moi un arbre B-TREE peut être...
Je ne sais pas si t'avais vu ce message alors je le remet.
Concernant l'arbre B-TREE. Comment est-il possible que sa taille peut être supérieur à 3? Est-ce lié à ce qu'on appelle le split des...
si j'ai 3 indexes sur la table avec une profondeur de 3.
ma requête insère 500 000 lignes.
Est-ce qu'on peut dire que chaque insert va mettre à jour les 3 indexes et donc chaque insert va engendrer...
Je répond à ta place: en fait le rebuild sert surtout pour les scan des indexes car en reconstruisant on a un arbre plus compact donc moins de blocks à parcourir. c'est ça?
Ba dans ce cas à quoi sert le rebuild alors?
T'as pas une preuve de ce que tu avances par hasard?
pas compris l'histoire des dizaines de block à aller voir par enregistrement.
Il me semblait que dans un index les feuilles vides n'étaient pas comblées et restaient toujours vides???
Bonjour,
Qu'est ce qui pourrait expliquer qu'un insert select dure très longtemps alors que le select s'execute très rapidement. Il n' y'a pas de trigger sur la table mais il y'a 3 indexes B-TREE....
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.