import des index

[pat29]

Bonjour,

lors d'un import avec les index ceux-ci sont ils chargés directement comme pour les tables ou bien sont ils complètement recréés ?

En résumé les 2 durées seraient elles équivalentes ?

1. import (données + index)
2. import (données) + création index

Merci.

[LeoAnderson]

non, l'import recalcule l'index au fur et à mesure

[scheu]

tu as le paramètre skip_unusable_indexes=y qui reconstruit les indexes après l'insertion des données et non pas au fur et à mesure des insertions

[pat29]

donc en conclusion le dump ne stocke que les définitions d'index et l'option skip_unusable_indexes=y est équivalent (en durée d'exécution) à importer sans les index et lancer les créations après.
Merci.

[orafrance]

euh... non

skip_unusable_indexes permet d'éviter qu'un message d'erreur interrompt l'import si des indexes sont au status UNUSABLE. Dans ton cas, le mieux serait probablement d'importer dans un premier temps sans les indexes (INDEXES=N) et ensuite sans les données (INDEXES=Y ROWS=N).

[pifor]

Le paramètre SKIP_UNUSABLE_INDEXES pour l'import n'est pris en compte que pour les index marqués "unusable" et non pour tous les index:

A value of y means that Import will skip building indexes that were set to the Index Unusable state (by either system or user). Other indexes (not previously set to Index Unusable) continue to be updated as rows are inserted

.

[pat29]

Envoyé par orafrance

Dans ton cas, le mieux serait probablement d'importer dans un premier temps sans les indexes (INDEXES=N) et ensuite sans les données (INDEXES=Y ROWS=N).

C'est ce que j'ai fait, et après un import de 3h1/2 j'ai la création des index (partitionnés) qui dure 6h1/2... Y a-t-il un moyen de réduire ça à part répartir les datafiles index sur différents disques ? (j'ai 1 seul disque en intégration mais il y aura une baie en prod) Est-ce que SORT_AREA_SIZE peut améliorer ?

[orafrance]

SORT_AREA_SIZE ? J'ose espérer que tu utilises la PGA plutôt

[pat29]

Ce paramètre est bien utilisé pour les tris ? Et Oracle doit bien faire des tris lors de la création d'index, non ?

[orafrance]

Envoyé par pat29

Ce paramètre est bien utilisé pour les tris ?

pas si tu utilises la PGA parametre PGA_AGGREGATE_TARGET de toute façon, les indexes ont peu de chance de pouvoir faire le tri en mémoire, il sera plutôt fait sur disque (dans le TEMP)

[Pomalaix]

Envoyé par orafrance

SORT_AREA_SIZE ? J'ose espérer que tu utilises la PGA plutôt

Cette formulation est très ambigüe !
Un tri en mémoire se fait quoi qu'il en soit dans la PGA.
Après, il y effectivement deux options pour dimensionner la zone de tri : soit SORT_AREA_SIZE au niveau individuel, soit PGA_AGGREGATE_TARGET au niveau global.

[orafrance]

Envoyé par Pomalaix

Un tri en mémoire se fait quoi qu'il en soit dans la PGA.

si on veut être tout à fait rigoureux, le tri est fait dans la SQL Work Area qui est un sous-ensemble de la PGA. PGA_AGGREGATE_TARGET permet de définir automatiquement la taille de la SWA dans la PGA.

Voila voila... quand je parlais de PGA, je voulais donc penser à la gestion automatique, au temps pour moi

[scheu]

Envoyé par pifor

Le paramètre SKIP_UNUSABLE_INDEXES pour l'import n'est pris en compte que pour les index marqués "unusable" et non pour tous les index:

autant pour moi ...