Discussion :

[sam01]

Bonjour,

existe t'il une règle pour diminuer le nombre d'extent d'un fichier DB2 lors d'un create table?

J'ai le create table suivant qui est généré par DB2 en fonction de la place disponible

Code :

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

1
2
3
4
5
6
CREATE TABLESPACE TABLEOS   
       IN DBRL               
       USING STOGROUP FGRX
           PRIQTY 1000       
          SECQTY 100

ceci me génère un fichier de 907375 TRACKS avec 165 extents.

Est-il possible qu'il y ait une meilleure optimisation de l'alloaction secondaire DB2 afin de diminuer ce nombre d'extent.
En effet à cause du nombre, on effectue à chaque des reorg de cette table....Et malgré les reorg, on a toujours le même nombre d'extent...

[bernard59139]

Bonjour
mes conseils pour comprendre la situation.

1. vérifier si une DAtACLASS est utilisée pour modifier le space du tablespace, sinon modifier la définition du tablespace PRIQTY, SECQTY
2. lire le redbook VSAM demystified (une bible de trucs)
3. relire la doc DFSMS using dataset

sans connaitre ton environnement, je ne peux rien dire de plus

[Luc Orient]

Bonjour,

Je dirais bien naïvement que si on veut moins d'EXTENTs sur un fichier TABLESPACE DB2, il faut augmenter l'allocation secondaire lors de la création de celui-ici ...

Maintenant, est ce si gênant que cela d'avoir des EXTENTs ?

[sam01]

Salut à vous deux, ben au début j’ai pensé comme toi Luc. Je leur ai dit d’augmentater l’allocation secondaire mais ils m’ont répondu que ce n’était pas eux qui choisissaient l’allocation mais c’est DB2 tout seul ( comme s’ils n’avaient pas la main dessus). Du coup j’ai fait une recherche sur le net et je suis tombé sur le lien suivant :
https://www.ibm.com/support/knowledg...daryspace.html

Quia l’air d’expliquer qu’il est possible de jouer sur la Dataclass et le paramètre :

Extent Constraint Removal en le mettant à Yes ce qui permettrait à DB2 d,optimiser l’allocation secondaire.
Est ce vous confirmez? Connaissez vous cette option ?

Pour répondre à Bernard, le fichier vsam en question n’a pas de dataclass.

Est ce que le grand nombre d’extent est problématique ? C’est une excellente question Luc.
Les DBA se basent ( entre autres) sur ce critère pour faire des réorg. Et comme ce fichier a de nombreux extents, ils font à chaque fois des reorgs sur cette table mais le nombre d’extent est toujours élevé.
A priori un grand nombre d’extent ferait baisser les performances Dd2, mais est ce vraiment le cas ?...

[Luc Orient]

Je trouve la réponse de tes DBA pour le moins curieuse ...

Pour moi, afin de diminuer le nombre d'EXTENT, ce qu'il faudrait faire :

1) passer une instruction ALTER Tablespace SECQTY avec la bonne quantité secondaire,

2) passer un utilitaire de REORG avec le bon paramètre. Pour l'utilitaire Db2, c'est, me semble-t-il, l'absence de l'option REUSE qui lui permet de re créer le fichier VSAM.

[bernard59139]

1) passer une instruction ALTER Tablespace SECQTY avec la bonne quantité secondaire,.

Sauf si la DataClass prend la main sur le space.

reste que la réponse des DBA me laisse aussi pantois.

[Luc Orient]

Sauf si la DataClass prend la main sur le space.

Certes, mais notre ami nous précise que le fichier VSAM en question n'a pas de DATACLASS.

[sam01]

Affecter une Dataclass peut être la solution mais que dois je mettre dans la dataclass pour que l’allocation secondaire génëre un minimum d’extent ?

[Luc Orient]

Affecter une Dataclass peut être la solution mais que dois je mettre dans la dataclass pour que l’allocation secondaire génëre un minimum d’extent ?

Déjà ça dépend de la taille de ta table logée dans le TS.

Mais il y a d'autres paramètres Db2 au niveau du TS qui peuvent intervenir et là il faut travailler impérativement avec tes DBA.

Et puis, ta DATACLASS tu la feras connaître à Db2 via la STOGROUP ou pas ?

[sam01]

Salut. Il y a déjà un Storage group mais par contre pas de Dataclass.
Enfin je me rends compte que le problème n'est pas si simple.
Et le paramètre de la Dataclass qui ignore sur le lien que je vous ai envoyé, tu penses que ça peut fonctionner ?
C'est le paramètre Extent Constraint Removal qu'il faut passer à Yes.

[Luc Orient]

Tu veux créer ta DATACLASS à quel niveau et comment ?

[sam01]

Heu je ne comprends pas trop ta question.
La dataclass ben La créé sous ISMF. Ensuite en fonction du nom du fichier ou de sa taille je lui affecte la bonne dataclass dans les ACS routines. Et je lui colle à Yes le fameux paramètre "Extent Constraint Removal "
Si j'ai bien compris la doc en anglais ça devrait gérer tout seul l'espace secondaire.

[Luc Orient]

Ensuite en fonction du nom du fichier ou de sa taille je lui affecte la bonne dataclass dans les ACS routines. s la doc en anglais ça devrait gérer tout seul l'espace secondaire.

Et si le STOGROUP DB2 a déjà une DATACLASS ?

Que se passe-t-il ?

[sam01]

Non j'ai vérifié. Le stogroup n'a aucune DATACLAS.

[Luc Orient]

Non j'ai vérifié. Le stogroup n'a aucune DATACLAS.

Bon, c'est déjà un point de traité.

Mais entre le PRIQTY et le SECQTY du CREATE TS, inscrit au catalogue Db2, et la DATACLASS SMS qui va gagner ?

[bernard59139]

Maintenant, est ce si gênant que cela d'avoir des EXTENTs ?

pas vraiment avec les techno modernes. C'est surtout impactant au moment du LOAD.

Mais entre le PRIQTY et le SECQTY du CREATE TS, inscrit au catalogue Db2, et la DATACLASS SMS qui va gagner ?

Ca depend du paramètrage de la DC, je ne me souviens plus duquel il sagit, mais ce n'est pas "Extent Constraint Removal " (qui ne concerne que le nbre d'ext par disque).

Vous avez de la chance que vsam utilise automatiquement la facilité "extents consolidation"

Sauf cas particulier, nous ne gérions pas le SPACE par une DC, surtout pour un fichier unique, simple à la mise en place; galère pour les maintenances.

Le seul moyen efficace est d'agir sur le space du tablespace, et si possible (et si pas déjà fait) utiliser le COMPRESS YES.

SI la table n'est pas "désorganisée", la tablespace devrait faire partie des exclusions possibles.

[sam01]

Salut Bernard, d'après ce que m'explique les DBA, peu importe ce que l'on met dans le create table, c'est de toute façon DB2 qui choisit tout seul la taille des extents.
Et toujours d'après ce qu'ils me disent, si DB2 ne trouve pas d'extent, il agrandi encore l'espace secondaire . et ainsi de suite...
ce qui me paraît une aberration car si l'allocation secondaire est trop grande, DB2 devrait au contraire la diminuer...Je n'y comprends plus rien.
D'après ce qu'ils disent, en ajoutant des volumes dans le Storage Group, ça fera de la place et il pourra trouver son espace secondaire....

Apparemment on utilise déjà l'option qui est dans le lien suivant :

https://www.ibm.com/support/knowledg...daryspace.html

C'est à dire :

Db2 can calculate the amount of space to allocate to secondary extents by using a sliding scale algorithm.

The first 127 extents are allocated in increasing size, and the remaining extents are allocated based on the initial size of the data set:
•For 32 GB, 64 GB, 128 GB, and 256 GB data sets, each extent is allocated with a size of 559 cylinders.
•For data sets that range in size from less than 1 GB to 16 GB, each extent is allocated with a size of 127 cylinders.

Mais ça n'a pas l'air de suffire.

Dans notre cas, il aurait dû prendre des extents de 127 Cylindres comme c'est indiqué puisque le fichier est compris en 1 Gigas et 16 Gigas ==> 87375 TRACKS

[bernard59139]

Je ne suis pas d'accord avec cette interprétation (je n'ai jamais eu l'occasion de profiter de cette facilité et je répond avant d'aller au dodo)

1) déjà, au début, il est écrit "Db2 can calculate", et pas "Db2 calculate"

2) ensuite, le gupi précise

Db2 uses a sliding scale for secondary extent allocations of table spaces and indexes when:
You do not specify a value for the SECQTY option of a CREATE TABLESPACE or CREATE INDEX statement
You specify a value of -1 for the SECQTY option of an ALTER TABLESPACE or ALTER INDEX statement.

Otherwise, Db2 always uses a SECQTY value for secondary extent allocations, if one is explicitly specified.

au vu de la définition (du tablespace) donnée au début, je pense que tu n'es pas concerné.

3) à vérifier le paramètre de la zparm "MGEXTSZ—Manage extent size" qui devrait être positionné à "YES" chez vous

Et je confirme, " extent constraint removal" ne concerne que le nombre d'extents / disque (pour dépasser les 255 exts/dsk)

Et pour info, pour gérer le space dans la DC, le paramètre est "Override Space" .

[Luc Orient]

Je ne suis pas d'accord avec cette interprétation (je n'ai jamais eu l'occasion de profiter de cette facilité et je répond avant d'aller au dodo)

Je penche plutôt pour l'avis de bernard59139. Et on revient bien à la définition du TABLESPACE avec PRIQTY et SECQTY.

[sam01]

Merci Bernard pour ton interprétation.
Du coup, il serait peut-être possible d'utiliser la DataClass pour overrider le Space secondaire.
Mais ça veut dire que l'on ne laisse plus DB2 choisir et c'est potentiellement risqué pour un problème qui n'est n'est peut-être pas un.

Voici une réponse 'en Anglais', que j'ai eu sur un forum sur la performance :
Je cite steve myers:

Back in the days before RAID type DASD, multiple extents had a potential performance impact because they often required unproductive movement of the the disk's access mechanism.

With RAID type DASD, in a technical sense, this is no longer true. The RAID mechanism scatters your data all over the physical media in ways you cannot control regardless of the extent definition. In any event, opening the data usually loads the data into the RAID controller's cache memory, so no additional I/O to the RAID device's physical media is required.
The primary advantage of reducing DASD extents is it forces the logical data into contiguous logical space, which looks better on reports. There is little, if any, performance impact from consolidating extents.

This appears to be something dreamed up by a more ignorant than usual PHB type.

J'ai a peu près compris, qu'avec la nouvelle technologie et les nouveau types d'accès disque le nombre d'extent n'a qu'un très faible impact sur les performances.