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

DB2 Discussion :

Tables DB2 partitionnées


Sujet :

DB2

  1. #1
    Nouveau Candidat au Club
    Homme Profil pro
    Développeur COBOL
    Inscrit en
    Décembre 2014
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur COBOL

    Informations forums :
    Inscription : Décembre 2014
    Messages : 1
    Points : 1
    Points
    1
    Par défaut Tables DB2 partitionnées
    Bonjour à tous,

    Pour une nouvelle application DB2 Mainframe, je vais créer une centaine de tables.

    Quels critères utilisez-vous pour décider si une table DB2 devra être partitionnée ?

    Merci d'avance.

    Christophe.

  2. #2
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 059
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 059
    Points : 38 268
    Points
    38 268
    Billets dans le blog
    9
    Par défaut
    Bonjour,

    Chaque partition d'une table est stockée dans un ou des fichiers spécifiques à la partition, ce qui permet par exemple de faire un utilitaire sur une partition (sauvegarde, restaure, réorg...), pendant que d'autres partitions sont ouvertes aux applications

    On utilise essentiellement le partitionnement sur des tables à très forte volumétrie

    J'ai utilisé cette architecture pour des bases stockant la traçabilité de renumérotation d'identifiants (traitement de convergence et/ou migration de S.I.) avec de très fortes volumétries et concernant des chantiers successifs.
    Les tables étaient partitionnées sur l'identifiant du chantier de renumérotation, ce qui permettait d'archiver les partitions de chantiers anciens, mettre à disposition les données des chantiers récents, et alimenter par load les nouveaux éléments issus de traitements de masse en cours

  3. #3
    Membre actif
    Profil pro
    Inscrit en
    Mars 2009
    Messages
    65
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2009
    Messages : 65
    Points : 230
    Points
    230
    Par défaut
    Bonjour

    Il existe aussi une autre cause pour "partitionnée" une table DB2 : si celle-ci doit stocker du XML dans des colonnes dédiées XML. La DB2V10 permet entre autre de pouvoir modifier directement des flux XML stockés, mais uniquement sur des tables partitionnées (By Range ou By Growth).

  4. #4
    Membre régulier
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Décembre 2007
    Messages
    53
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val d'Oise (Île de France)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Industrie

    Informations forums :
    Inscription : Décembre 2007
    Messages : 53
    Points : 100
    Points
    100
    Par défaut
    Bonjour

    chez nous aussi on utilise le partitionnement sur des tables à très forte volumétrie.

    Il faut veiller à avoir des partitions équilibrées en terme de nombre d'enregistrements

    Les critères de partiellement peuvent être :
    - des id d'applications
    - des dates (mois par exemple ) avec des tables d'historiques
    - Pour effectuer une purge d'historique il est ainsi aisé d'utiliser le "rotate partition"
    - attention dans les select à bien accéder aux données par numéro de partition

  5. #5
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 059
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 059
    Points : 38 268
    Points
    38 268
    Billets dans le blog
    9
    Par défaut
    Citation Envoyé par Macmini95 Voir le message
    Bonjour

    chez nous aussi on utilise le partitionnement sur des tables à très forte volumétrie.

    Il faut veiller à avoir des partitions équilibrées en terme de nombre d'enregistrements
    Cette contrainte existe peut être chez vous, mais ce n'est pas une règle, on peut avoir au contraire des partitions de tailles très différentes sans aucun souci, il faut bien sur surveiller les tablespace respectifs et les redimensionner si besoin, comme sur une table non partitionnée d'ailleurs


    Citation Envoyé par Macmini95 Voir le message
    - attention dans les select à bien accéder aux données par numéro de partition
    Pas forcément, ca dépend de ce que l'on veut faire.
    Si l'on reprend l'exemple de partitionnement sur 12 mois, un traitement de consolidation annuel pourra faire des select sans le critère mois pour consolider les résultats

    Attention aussi pour ceux qui n'ont jamais utilisé les load sur une table partitionnée, à l'emplacement du mot clef "replace"
    si on utilise la syntaxe 1 avec une table partitionnée, alors toutes les partitions seront rechargées. Du coup, si le fichier de load ne contient que les données de la partition 16 (dans mon exemple), toutes les autres partitions sont vidées.
    Petit détail à ne pas oublier si une table non partitionnée le devient

    -- Exemple de syntaxe avec un TS segmenté
    LOAD DATA REPLACE INDDN SYSREC00 LOG NO STATISTICS
    TABLE ALL INDEX ALL KEYCARD INTO TABLE ....

    -- Exemple de syntaxe avec un TS partitionné (rechargement de la partition 16)
    LOAD DATA INDDN SYSREC00 LOG NO STATISTICS
    INTO TABLE .... PART 16 REPLACE

Discussions similaires

  1. Erreur Openrecordset sur une table DB2
    Par Aränel dans le forum Access
    Réponses: 7
    Dernier message: 17/01/2007, 14h35
  2. Insertion dans une table DB2 a partir de ACCESS
    Par machipot dans le forum Access
    Réponses: 4
    Dernier message: 23/11/2006, 21h34
  3. PB lecture ou import table DB2 dans ACCESS
    Par Invité dans le forum Access
    Réponses: 2
    Dernier message: 22/06/2006, 15h54
  4. Ordre de sélection des lignes sur une table DB2
    Par Pierre Formosa dans le forum DB2
    Réponses: 1
    Dernier message: 26/04/2006, 21h03
  5. Réponses: 1
    Dernier message: 27/03/2006, 17h58

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