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.
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.
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
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).
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
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
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
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager