Discussion :

[DjinnS]

Bonjour,

Je déplace une table (9i) sur une nouvelle instance (10g).

La procédure est la suivante:

1/ création de la table
2/ copie des données via dblink

Sur cette table j'ai trois index.

Est-il plus interessant en terme de temps de générer les index une fois toutes les données présentent, ou bien de créer les index à la suite de la création de la table, avant l'insertion des données ?

Est ce qu'une méthode est plus avantageuse que l'autre ?

Merci d'avance.

[scheu]

ça sera sans doute plus rapide d'insérer les données et ensuite créer l'index que l'inverse

[mildiou51]

Carrement plus avantageux de créer l'index à la fin !
raisons :

• le temps de traitement total sera plus rapide (un seul tri à faire au global, et pas de vérification au fur et à mesure)
• l'index sera plus compact, et son arbre B-Tree sera propre (donc optimal)

[DjinnS]

Merci beaucoup pour vos retours.

Je vais tester ça ^^

[LeoAnderson]

Attention : si la table est grosse, le calcul de l'index en one-shot à la fin va être long et très consommateur de temp.
Si vous le créé au début, l'insertion unitaire sera plus lente, certes, mais vous n'aurez pas 20h de calcul d'index ni besoin d'allouer 30 Go de TEMP...

[DjinnS]

Je "ré-ouvre le post" à la suite de ta remarque.

Mes index sont partitionnés. Je pense reconstruire par partition, ça me parait plus logique. J'ai pu aussi voir qu'il y avait l'option PARALLEL de disponible, qui semble-t-il permet d'augmenter le nombre de processus qui collecte les informations pour la construction de l'index.

Certaines de mes tables sont relativement importantes (+300go) donc j'ai effectivement des problématiques de temps qui peuvent apparaître. Je recherche donc des optimisations permettant de gagner du temps ^^

J'ai vu qu'on pouvait jouer sur la taille de sort area size. Sur asktom j'ai pu récupérer l'info de 150% de la taille de l'index, mais dans mon cas ca peut faire beaucoup 150% ^^

[LeoAnderson]

les indexes sont-ils partitionnés ?
quelle est la taille maximale de l'index / partition d'index ?

Donc, vu les volumétrie, je pense que calculer les indexes après insertions sera TRES difficile !

[DjinnS]

Oui les index sont partitionnés.

Pour la taille je ne sais pas et je n'ai pas la possibilité de le savoir tout de suite ^^

Par contre (désolé mais je maîtrise vraiment pas les index) je ne comprends comment sont répartis les index via le partitionnement:

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
  CREATE INDEX "toto"."titi_idx" ON "toto"."titi" ("col1", "col2")
  PCTFREE 10 INITRANS 2 MAXTRANS 255
  STORAGE(INITIAL 10485760 NEXT 5242880
  PCTINCREASE 0 BUFFER_POOL DEFAULT)
  TABLESPACE "tbs" LOCAL
 (PARTITION "PARTX_titi_idx1"
  PCTFREE 10 INITRANS 2 MAXTRANS 255
  STORAGE(INITIAL 10485760 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
  PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
  TABLESPACE "tbs_1" ,
 PARTITION "PARTX_titi_idx1"
  PCTFREE 10 INITRANS 2 MAXTRANS 255
  STORAGE(INITIAL 10485760 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
  PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
  TABLESPACE "tbs_2" ,
 PARTITION "PARTX_titi_idx3"
  PCTFREE 10 INITRANS 2 MAXTRANS 255
  STORAGE(INITIAL 10485760 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
  PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
  TABLESPACE "tbs_3" ....

J'ai extrais les données avec dbms_metadata depuis la base source (j'ai remplacé le nom des cols, tbs, etc ... normal que ce soit pas forcement cohérent ...).

Donc j'ai pleins de partition ... mais le stockage se fait sur quel critère ? Est ce que je n'aurais pas oublié quelque chose avec dbms_metadata ?

[Michel SALAIS]

Attention : si la table est grosse, le calcul de l'index en one-shot à la fin va être long et très consommateur de temp.
Si vous le créé au début, l'insertion unitaire sera plus lente, certes, mais vous n'aurez pas 20h de calcul d'index ni besoin d'allouer 30 Go de TEMP...

Tu as raison sur ce point.
Maintenant si le choix est entre charger massivement les données en présence de l'index ou charger massivement les données puis créer l'index alors le deuxième choix est meilleur ...

[LeoAnderson]

Tu as raison sur ce point.
Maintenant si le choix est entre charger massivement les données en présence de l'index ou charger massivement les données puis créer les index alors le deuxième choix est meilleur ...

à condition d'avoir du CPU et du TEMP en pagaille
si on est serré niveau disque, l'option 1 s'impose

[Michel SALAIS]

à condition d'avoir du CPU et du TEMP en pagaille
si on est serré niveau disque, l'option 1 s'impose

A condition de ne pas être préssé

[LeoAnderson]

c'est clair que si on est pressé mais qu'on a pas de disque ni de CPU ni de RAM, ça va être dur !

[wondersonic]

Si je puis me permettre, considère également l'option du NOLOGGING / LOGGING sur tes segments.

[wondersonic]

Ah et puis il existe l'option

Code :

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

compute statistics

dans la commande de création d'index...

[DjinnS]

J'ai pas forcement du temps ... mais j'ai une grosse machine ^^

Je vais parralléliser par partition quand c'est possible et je vais jeter un coup d'oeil sur ce que propose wondersonic.

[DjinnS]

Apparemment c'est automatique sous la 10g, faudra que je vérifie lorsque l'index sera créé et rebuild ...

Par contre est ce que quelqu'un pourrait m'expliquer l'impact qu'a le paramètre PARALLEL dans ALTER INDEX idx REBUILD PARALLEL 5, par exemple. J'ai pu lire que ça permettait d'avoir plusieurs processus qui s'occupe du calcul de l'index mais qu'une valeur était modifiée dans l'index (la colonne degree) et que cela avait ensuite, si j'ai bien compris, une incidence sur les requêtes effectuées.

Mais je n'ai pas compris qu'elle était cet impact.

On peu par la suite, avec un ALTER INDEX, repasser en defaut, mais là aussi, quel est l'impact ?