Discussion :

[Peut-êtreUneRéponse]

Bonjour,

Petite question pour un DBA de passage.

J'ai un tablespace de 27 partitions, le partionnement est fait par un index cluster unique selon sa première colonne qui se trouve être le numéro de partition. Dans chaque partition on a une 20aine de million d'enreg. Le numéro de partition change chaque semaine.

On fait 5 à 6 LOAD quotidiens de 500 000 enreg avec un DISCARDDN afin de récupérer les doublons et les retraiter (c'est une des fonctions de la table).

Le problème est que les doublons doivent être contrôlés et dédoublonnés dans le DISCARDDN sur plus d'une semaine.

Nous souhaitons donc rajouter un index unique identique à l'index cluster unique sans la colonne "numéro de partition" afin que le dédoublonnage en DISCARDDN soit fait sur les autres partitions que celle loadée.

Bien sûr il y a un problème de conception, bien sûr un LOAD avec DISCARDDN n'est pas la meilleure solution pour gérer des doublons, mais j'ai peu de chance de pouvoir faire modifier ces aspects, alors, en tant que DBA, pour des raisons de performance, est-ce que vous laisseriez passer cette solution (ajout de l'IX unique) en production ?

.

[bernard59139]

Bonjour

Je pense que tu dois faire un "load resume part xx".
tu peux très bien te passer du "part xx", mais il y a risque de ne pas constituer le dictionnaire de compression pour la partition chargée.

EN créant un nouvel index "non partitionné", tu risques d'avoir pas mal de problèmes de performance lors du LOAD.
Si l'index est identique à l'index de partitionnement, cela sera complètement inutile.

Si il y a risque de doublons dans le fichier en entrée, je conseillerai très fortement de les détecter et éliminer avec un tri. ICETOOL fait cela très bien.
Insiste pour modifier les jcl de chargement si il faut. En plus, le tri est beaucoup plus efficace que db2.

[Peut-êtreUneRéponse]

@bernard59139

Merci pour ta réponse, Oui c'est un LOAD RESUME mais sans précision de partition.

Le nouvel index unique a juste pour utilité de mettre en DISCARDDN les enregistrements identiques des autres partitions (modulo la partition).

Pour ce qui est du tri en amont du load cela revient à décharger 20M d'enreg * 27 partitions et les traiter par DFSORT avec les nouveaux enreg à loader et ce, 6 fois par jour (je vais éditer mon 1er message, le traitement est multiquotidien). C'est ce que j'avais préconisé au début mais vu la volumétrie j'avais un doute...

Tu me confirmes qu'avec cette volumétrie il vaut donc mieux passer par un SELECT... DISCARD ICETOOL que rajouter un index unique ? Rajouter cet index unique va vraiment dégrader les performances ?

.

[bernard59139]

Ajouter un index "non partitionné" va vous dégrader les performances, surtout en maj (load , update, insert). Reste à savoir si ca en vaut le coup. Perso, je serais contre.

A la 1ere lecture, j'ai pensé que les doublons étaient exclusivement dans le fichier en entrée. Pour ton problème, c'est la combinaison fichier+table.

Pour ce sujet précis, je pense que tu peux remplacer "load part xx resume" par un "load resume" (sans part xx). L'index actuel étant "UNIQUE", le discard se fera si il y a besoin. DB2 va ranger les données dans la (les) bonne(s) partition(s).

en général, je n'utilise pas les astuces techniques pour pallier un défaut d'analyse. Sauf urgence, ou pression des responsables.

[Luc Orient]

...
Le problème est que les doublons doivent être contrôlés et dédoublonnés dans le DISCARDDN sur plus d'une semaine.

Nous souhaitons donc rajouter un index unique identique à l'index cluster unique sans la colonne "numéro de partition" afin que le dédoublonnage en DISCARDDN soit fait sur les autres partitions que celle loadée.

Puisque l'index unique actuel porte à la fois sur le numèro de partition et le(les) autre(s) colonne(s) comment est faite la détection des doubles actuellement ?

[Peut-êtreUneRéponse]

@bernard59139
Effectivement les doublons sont dans le fichier à loader et en table

L'index unique cluster actuel fonctionne très bien pour dédoublonner en DISCARDDN les enregs à loader déjà présent dans la partition en cours de load, ce nouvel index unique permettrait aussi de dédoublonner sur les autres partitions.

en général, je n'utilise pas les astuces techniques pour pallier un défaut d'analyse. Sauf urgence, ou pression des responsables.

Hum... CQFD

@Luc Orient
Actuellement la détection se fait uniquement sur la partition en cours de load, malheureusement le doublon (modulo la donnée "numéro de partition") peut être aussi dans une autre partiton.



Peut-être devrions nous créer un index simple de partitionnement contenant uniquement la donneé "numéro de partition" et un index unique cluster du reste...??

.

[Luc Orient]

... Peut-être devrions nous créer un index simple de partitionnement contenant uniquement la donneé "numéro de partition" et un index unique cluster du reste...??

C'est inutile ... Une des grandes nouveautés de la V8 justement c'est que le partitionnement peut se faire par la table. On a plus besoin que l'index cluster soit l'index de partitionnement.

Dans ton cas on aurait :

= un partionnement défini dans la table et portant sur le numéro de partition

= un index unique et cluster portant sur l'autre colonne

La moins bonne nouvelle c'est qu'il faudra sans doute détruire puis recréer l'objet Tablespace associé d'où :
Unload / Drop / Create / Load

Et que faire des doubles déjà présents dans la table mais dans des partitions différentes ?

[alex.]

Je pense qu'il faut prendre en considération le volume de doublons à chaque chargement. S'il en a 10, le load fonctionnera correctement. S'il y'en a 100000, c'est plus la même histoire. Le dédoublonnage se fait à la fin du load, ça coûte un bras (qui plus est avec un index supplémentaire) et ça enlève l'interêt à utiliser un load. Dans ce cas, un programme me semblerait plus adapté, justifiable et plus propre.

[Luc Orient]

En fait c'est un LOAD RESUME à la partition avec possibilité de doubles ...

Effectivement c'est assez curieux comme façon de travailler ...

Et qu'est ce que vous faites si le LOAD plante ? ... parfois sur un LOAD RESUME "planté" le reprise peut s'avérer délicate et même nécessiter un RECOVER ...

Question subsidiaire : c'est un LOAD IBM ou d'un autre fournisseur ?

[Peut-êtreUneRéponse]

C'est inutile ... Une des grandes nouveautés de la V8 justement c'est que le partitionnement peut se faire par la table. On a plus besoin que l'index cluster soit l'index de partitionnement.

Dans ton cas on aurait :

= un partionnement défini dans la table et portant sur le numéro de partition

= un index unique et cluster portant sur l'autre colonne

La moins bonne nouvelle c'est qu'il faudra sans doute détruire puis recréer l'objet Tablespace associé d'où :
Unload / Drop / Create / Load

Et que faire des doubles déjà présents dans la table mais dans des partitions différentes ?

Merci Luc Orient

Je viens de relire la doc v8 on aurait donc :

- Toujours le Tablespace avec le NUMPARTS,
- la table défini avec une partitioning-clause :

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
CREATE TABLE AAAA.TABLE_PART
    (NUMPART           INT
    ,COL2              CHAR(5)
    ,COL3              CHAR(12)
    ,[...])
IN AAAA.TS_PART
PARTITION BY (NUMPART)
    (PARTION 1 ENDING AT (1)
    ,PARTION 2 ENDING AT (2)
    ,[...])

- et l'index unique cluster qu'on voulait rajouter (donc sans "numéro de partition" et sans notion de partitionnement).

Merci aussi pour ton point d'attention sur les problèmes éventuels de DROP/CREATE et de doublon pré-existants en table. Pour l'instant les DDL n'ont pas été soumis en PROD, nous avons tiré la sonnette d'alarme à temps.

Demain, aujourd'hui, je teste la mise en oeuvre du DDL, et si c'est bon et bien ça partira en prod comme ça.

Luc Orient, si tu avais à valider ça sur ton site avec les volumétries annoncées, ça passerait ??

NB : Précision pour ceux qui me connaissent, l'ouverture de ce sujet n'est pas lié à ma mission actuelle

.

[Peut-êtreUneRéponse]

En fait c'est un LOAD RESUME à la partition avec possibilité de doubles ...

Effectivement c'est assez curieux comme façon de travailler ...

Oui c'est curieux

Et qu'est ce que vous faites si le LOAD plante ? ... parfois sur un LOAD RESUME "planté" le reprise peut s'avérer délicate et même nécessiter un RECOVER ...

Y a un point de synchro avant, un RECOVER TORBA.

Question subsidiaire : c'est un LOAD IBM ou d'un autre fournisseur ?

IBM

.

[Peut-êtreUneRéponse]

Je pense qu'il faut prendre en considération le volume de doublons à chaque chargement. S'il en a 10, le load fonctionnera correctement. S'il y'en a 100000, c'est plus la même histoire. Le dédoublonnage se fait à la fin du load, ça coûte un bras (qui plus est avec un index supplémentaire) et ça enlève l'interêt à utiliser un load. Dans ce cas, un programme me semblerait plus adapté, justifiable et plus propre.

Le nombre de doublon est en effet limité, en plus d'après la proposition de Luc Orient on aurait qu'un seul index unique.
Si nous devons nous séparer de la solution via LOAD DB2, donc décaler le planing de la MEP et donc faire sauter des têtes , nous envisagerions plutôt qu'un programme un utilitaire comme préconisé par bernard59139

.

[pdz74]

Bonjour,

Je confime les propos de Luc Orient : il faut passer au partitionnement table. Cela n'a que des avantages, les anciens index de partitionnement ne servant souvent à rien d'autre que gérer le partitionnement. Souvent DB2 décide de prendre quand même ces index comme clé d'accès avec des prédicats du type "WHERE PARTITION = :HV". Résultat : scan de 20 millions de RIDs dans l'index qui le renvoie sur toutes les lignes de la partition, donc double scans. Alors que sans l'index, DB2 décide de faire du "partition scan", ce qui est la bonne solution (ACCESSTYPE = 'R' avec PAGE_RANGE = 'Y').

Pour passer du partitionnement index au partitionnement table, rien de plus simple : il suffit par exemple de dropper l'index de partitionnement ou faire un alter de l'index en le mettant 'NOT CLUSTER'. Cela rendra une warning précisant que le partitionnement est maintenant au niveau table, DB2 s'occupe de la mise à jour du catalogue. Pas de drop/create à prévoir.

Donc tu pourrais faire :
- CREATE du nouvel index (+ runstats),
- DROP de l'index de partitionnement (-> le partitionnement table est OK),
- BIND des packages invalidés.

Pour le reste : solution programme ou solution utilitaire, chacune à ses avantages et inconvénients. Le programme durera plus longtemps mais tout planton sera plus simple à gérer et tu restes maitre de la gestion des doublons. L'utilitaire sera plus rapide mais les doublons sont juste éliminés et non gérés. Et si planton, c'est plus complexe.

Bonne utilisation.

[Peut-êtreUneRéponse]

J'ai testé la mise en oeuvre du DDL, ça fonctionne parfaitement comme l'avait indiqué Luc Orient.

pdz74 Merci pour ce mode opératoire, ça fonctionne parfaitement : après le DROP de l'index de partionnement on a bien le warning que le partitionnement sera porté par la table.

On se retrouve maintenant avec une table partitionnée "correctement" et un seul index unique cluster qui ne porte plus sur le numéro de partition.

J'aimerais maintenant savoir si quelqu'un a un retour d'expérience côté performance sur un LOAD avec DISCARDDN sur de telles volumétries ??

@pdz74 par ta réponse (extrait ci-dessous) j'ai l'impression que tu ne serais pas chaud pour le contrôle des doublons via ce LOAD avec DISCARDDN. C'est le cas ? C'est juste par rapport au modalité de gestion des doublons ou bien par rapport aux performances ?

Pour le reste : solution programme ou solution utilitaire, chacune à ses avantages et inconvénients. Le programme durera plus longtemps mais tout planton sera plus simple à gérer et tu restes maitre de la gestion des doublons. L'utilitaire sera plus rapide mais les doublons sont juste éliminés et non gérés. Et si planton, c'est plus complexe.

.

[pdz74]

Bonjour,

Pas vraiment de retour d'expérience sur le DISCARDDN, on ne réalise pas trop ce type de traitement. Ce qui ne veut, en aucun cas, dire que cela ne fonctionne pas. Et quoi qu'il en soit, un utilitaire sera toujours plus rapide qu'un programme.

Si LOAD RESUME YES, gaffe à un truc, DB2 peut détecter des doublons entre une nouvelle ligne à insérer et une ligne déjà existante. Dans ce cas, DB2 ne charge pas la nouvelle ligne et la met en discard. Mais DB2 peut également détecter des doublons entre 2 lignes à insérer. Dans ce cas, DB2 ne charge aucune des 2 lignes et les mets également en discard. Si cela se produit, il faut être capable de faire la différence entre les 2 cas.

Si tu partais de zéro, mon conseil serait le suivant : faire en sorte de réaliser tous les contrôles en amont du LOAD, de manière que le LOAD soit toujours OK. Après rien n'empêche qu'un jour, le LOAD plante pour une raison x ou y, mais ce planton ne sert pas à gérer un cas fonctionnel, c'est un vrai planton qu'il faut gérer tel quel. C'est un peu comme quand des gens me demandent s'ils peuvent tester en dur le sqlcode -803 (doublons) lors d'un INSERT. Sur le principe, pourquoi pas, mais ce n'est pas normal que ce soit au moment de l'INSERT qu'on se rende compte d'un doublon. Tous les contrôles auraient du être réalisés avant.

En espérant que ces "grands" principes puissent te servir.

[Peut-êtreUneRéponse]

Bonjour,
Si LOAD RESUME YES, gaffe à un truc, DB2 peut détecter des doublons entre une nouvelle ligne à insérer et une ligne déjà existante. Dans ce cas, DB2 ne charge pas la nouvelle ligne et la met en discard. Mais DB2 peut également détecter des doublons entre 2 lignes à insérer. Dans ce cas, DB2 ne charge aucune des 2 lignes et les mets également en discard. Si cela se produit, il faut être capable de faire la différence entre les 2 cas.

Merci pour la précision, une piqûre de rappel ne fait jamais de mal.

Si tu partais de zéro, mon conseil serait le suivant : faire en sorte de réaliser tous les contrôles en amont du LOAD, de manière que le LOAD soit toujours OK. Après rien n'empêche qu'un jour, le LOAD plante pour une raison x ou y, mais ce planton ne sert pas à gérer un cas fonctionnel, c'est un vrai planton qu'il faut gérer tel quel. C'est un peu comme quand des gens me demandent s'ils peuvent tester en dur le sqlcode -803 (doublons) lors d'un INSERT. Sur le principe, pourquoi pas, mais ce n'est pas normal que ce soit au moment de l'INSERT qu'on se rende compte d'un doublon. Tous les contrôles auraient du être réalisés avant.

Merci pour ces conseils, c'est ce que j'aurais fait si j'avais eu la main sur l'intégralité des process, il est bon de rappeler les bonnes pratiques.

.