IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Oracle Discussion :

Chargement d'une table de faits


Sujet :

Oracle

  1. #1
    Nouveau Candidat au Club
    Inscrit en
    Octobre 2007
    Messages
    2
    Détails du profil
    Informations forums :
    Inscription : Octobre 2007
    Messages : 2
    Points : 1
    Points
    1
    Par défaut Chargement d'une table de faits
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
      DELETE FOM TAB WHERE VERSION=:1;
    2. Code : Sélectionner tout - Visualiser dans une fenêtre à part
      DELETE FROM TAB WHERE VERSION IN ('version1', 'version2');
    3. Code : Sélectionner tout - Visualiser dans une fenêtre à part
      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?

  2. #2
    Membre expert

    Profil pro
    Inscrit en
    Février 2006
    Messages
    3 437
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 3 437
    Points : 3 597
    Points
    3 597
    Par défaut
    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é.

  3. #3
    Nouveau Candidat au Club
    Inscrit en
    Octobre 2007
    Messages
    2
    Détails du profil
    Informations forums :
    Inscription : Octobre 2007
    Messages : 2
    Points : 1
    Points
    1
    Par défaut
    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)

  4. #4
    Membre expert

    Profil pro
    Inscrit en
    Février 2006
    Messages
    3 437
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 3 437
    Points : 3 597
    Points
    3 597
    Par défaut
    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.

Discussions similaires

  1. Réponses: 2
    Dernier message: 03/02/2008, 23h31
  2. Réponses: 4
    Dernier message: 15/11/2007, 11h43
  3. création d'une table de fait sous sql server 2005
    Par kev0631 dans le forum MS SQL Server
    Réponses: 10
    Dernier message: 19/07/2007, 14h45
  4. Chargement d'une table avec de très nombreux champs
    Par Davou dans le forum Débuter
    Réponses: 4
    Dernier message: 04/07/2007, 15h59
  5. nologging pour chargement d'une table temporaire
    Par psafp dans le forum MS SQL Server
    Réponses: 5
    Dernier message: 26/06/2007, 09h16

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo