Chargement d'une table de faits

[JoeLF]

Bonjour,

Je dois charger une table de faits. Cette table contient aujourd'hui environ 20 millions de lignes.
La table est constituée de 23 colonnes.
Parmis ces colonnes, j'ai 14 clé étrangères vers des tables de dimensions (et pour chacune un index rattaché), les 9 colonnes restantes sont des attributs ou des indicateurs.
Ma clé primaire est la suivante : PK_TAB(VERSION, JOUR, ID)
Chaque jour je charge environ 1.5-2 millions d'enregistrement pour les 2 versions en cours. Je dois donc au préalable supprimer les enregistrements concernant ces versions.

Ma question est la suivante :
Quel est le moyen le plus performant pour supprimer ces données?

1. Code :

   DELETE FOM TAB WHERE VERSION=:1;

2. Code :

   DELETE FROM TAB WHERE VERSION IN ('version1', 'version2');

3. Code :

   1
   2
   3
   4
   CREATE TAB_T AS SELECT * FROM TAB WHERE VERSION NOT IN ('version1', 'version2');
   DROP TABLE TAB;
   ALTER TABLE TAB_T RENAME TO TAB;
   <reconstruction des index>

Comment organiser mes index?
Faut il que j'utilise la clé primaire pour supprimer la version?
Ou faut-il que j'utilise la clé étrangère de la version?
Quelle type d'index dans ce cas? B-tree ou bitmap?
Le B-tree ferait presque 900 Mo, le bitmap 4-5 Mo.
Et pour les autres clés étrangères?

Dois-je utiliser le partitionnement par version?

[pifor]

Le moyen le plus performant parmi ceux cités doit être le n°3 qui doit minimiser à la fois le redo et le undo généré.

[JoeLF]

Le fait de copier 18 millions de ligne ne sera donc pas trop pénalisant?
La base est en mode noarchivelog et les tablespaces en nologging.
J'avais déjà fait les tests avec une volumétrie moindre (~3 millions de lignes) sur la méthode que tu recommandes et c'était effectivement la plus rapide. Par contre ça implique un espace temporaire assez important.

Pour les index, quel serait le type à utiliser?
Y a-t-il une différence à la génération des index bitmap? Je n'ai pas réussi à mesurer correctement un écart part rapport aux index b-tree, mais les bitmap ont l'avantage pour ma table d'être de très petite taille (100x inférieure aux index b-tree)

[pifor]

Il est difficile de conseiller un type d'index plutôt qu'un autre lorsqu'on ne connait ni les requêtes qui seront utilisées, ni la répartion des données.

Si la base est à usage décisionnel (écriture uniquement pendant les changements et ensuite uniquement lecture des données), les index bitmap peuvent être une bonne solution. Voir ce que dit le Data Warehousing Guide.