DB2 z/OS: DSSIZE for UTS PBG TS

Manabendra Datta

DB2 z/OS: DSSIZE for UTS PBG TS

Hi,

We are in DB2 V10.1 NFM.

I have a typical space issue. I have converted one segmented TS into UTS PBG TS with DSSIZE 2G.
It seems UTS PBG tablespace is blocking more spaces even it is not using those spaces.

Now, if I follow DSSIZE 2G, I might get more number of datasets but the over allocation of space is less in comparison with DSSIZE 4G or 8G, and when it is required to grow for another partition, the space allocation is more which I don't want.


So, What is the best practice for DSSIZE you are following to allocate UTS PBG tablespaces and why?

DDL of the TS I used:

CREATE TABLESPACE XXXXX IN XXXXXXX
DSSIZE 2G MAXPARTITIONS 32
USING STOGROUP XXXXX
PRIQTY 2097360
SECQTY 132000
ERASE NO
FREEPAGE 0
PCTFREE 0
TRACKMOD YES
COMPRESS YES
SEGSIZE 32
BUFFERPOOL BP2
LOCKSIZE ANY
LOCKMAX SYSTEM
CLOSE NO
CCSID EBCDIC;


Dataset allocation in 3.4:

Enter "/" to select action                         Tracks
---------------------------------------------------------
XXXX.DSNDBD.XXXXXXX.I0001.A001 43695
XXXX.DSNDBD.XXXXXXX.I0001.A002 43695
XXXX.DSNDBD.XXXXXXX.I0001.A003 43695
XXXX.DSNDBD.XXXXXXX.I0001.A004 43695
XXXX.DSNDBD.XXXXXXX.I0001.A005 43695
XXXX.DSNDBD.XXXXXXX.I0001.A006 43695


This is I got from RTS:

SPACE_MB PARTITION TOTALROWS NACTIVE NPAGES EXTENTS
-------- --------- --------- ------- ------ -------
2048 1 11918244 524271 524128 1
2048 2 10914603 524271 524128 1
2048 3 11102810 524271 524128 1
2048 4 11332748 524271 524128 1
2048 5 34233 1611 1577 1
2048 6 0 34 0 1


LISTCAT for the 6th dataset

HI-A-RBA------2147696640
HI-U-RBA----------139264


Thanks,
Manabendra

Larry Jardine

DB2 z/OS: DSSIZE for UTS PBG TS
(in response to Manabendra Datta)
You are getting 2 gig allocations because of: PRIQTY 2097360.

Use DSSIZE to define the maximum size that you want each partition to be.

Use PRIQTY to determine the initial size that you want each partition to be. Then let DB2 allocate extents (as needed) of the size SECQTY until it reaches the DSSIZE and goes to the next partition. That will minimize your “blocking” space that is not yet needed.

If you are at DB2 11 or higher, I believe a REORG will delete the 6th partition if it is not being used yet. There may be some tricks to doing this in your version. At the minimum, you can consider altering PRIQTY small and SECQTY large (then REORG) to keep that unused 6th partition small until needed. For example (PRIQTY 720 SECQTY 720000).

Larry Jardine
Aetna

From: Manabendra Datta [mailto:[login to unmask email]
Sent: Friday, February 16, 2018 3:22 PM
To: [login to unmask email]
Subject: [EXTERNAL] [DB2-L] - DB2 z/OS: DSSIZE for UTS PBG TS

**** External Email - Use Caution ****

Hi,

We are in DB2 V10.1 NFM.

I have a typical space issue. I have converted one segmented TS into UTS PBG TS with DSSIZE 2G.
It seems UTS PBG tablespace is blocking more spaces even it is not using those spaces.

Now, if I follow DSSIZE 2G, I might get more number of datasets but the over allocation of space is less in comparison with DSSIZE 4G or 8G, and when it is required to grow for another partition, the space allocation is more which I don't want.

So, What is the best practice for DSSIZE you are following to allocate UTS PBG tablespaces and why?

DDL of the TS I used:

CREATE TABLESPACE XXXXX IN XXXXXXX
DSSIZE 2G MAXPARTITIONS 32
USING STOGROUP XXXXX
PRIQTY 2097360
SECQTY 132000
ERASE NO
FREEPAGE 0
PCTFREE 0
TRACKMOD YES
COMPRESS YES
SEGSIZE 32
BUFFERPOOL BP2
LOCKSIZE ANY
LOCKMAX SYSTEM
CLOSE NO
CCSID EBCDIC;

Dataset allocation in 3.4:

Enter "/" to select action Tracks
---------------------------------------------------------
XXXX.DSNDBD.XXXXXXX.I0001.A001 43695
XXXX.DSNDBD.XXXXXXX.I0001.A002 43695
XXXX.DSNDBD.XXXXXXX.I0001.A003 43695
XXXX.DSNDBD.XXXXXXX.I0001.A004 43695
XXXX.DSNDBD.XXXXXXX.I0001.A005 43695
XXXX.DSNDBD.XXXXXXX.I0001.A006 43695

This is I got from RTS:

SPACE_MB PARTITION TOTALROWS NACTIVE NPAGES EXTENTS
-------- --------- --------- ------- ------ -------
2048 1 11918244 524271 524128 1
2048 2 10914603 524271 524128 1
2048 3 11102810 524271 524128 1
2048 4 11332748 524271 524128 1
2048 5 34233 1611 1577 1
2048 6 0 34 0 1

LISTCAT for the 6th dataset

HI-A-RBA------2147696640
HI-U-RBA----------139264

Thanks,
Manabendra

-----End Original Message-----

This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna

Manabendra Datta

RE: DB2 z/OS: DSSIZE for UTS PBG TS
(in response to Larry Jardine)

Thank you Larry. 
Let me try this with PRIQTY 720.

But for SECQTY, should I specify any number or keep it as SECQTY -1, please let me know. 

 

Thanks,

Manabendra

Horacio Villa

DB2 z/OS: DSSIZE for UTS PBG TS
(in response to Manabendra Datta)
Hi Manabendra,

SECQTY -1 makes DB2 manage secondary allocations following an algorithm
explained in the manuals.
With any other positive number you manage it.
I've been using -1 on SECQTY without problems.
It's up to you.
Kind regards,
Horacio

Walter Janißen

AW: DB2 z/OS: DSSIZE for UTS PBG TS
(in response to Horacio Villa)
Hi

We even work with PROQTY and SECQTY = -1 with any known problems.

Kind regards
Walter Janißen [standard_IBM+Champ+7+Yr+Analytics]

ITERGO Informationstechnologie GmbH
Anwendungsentwicklung
Technische Anwendungsarchitektur
Victoriaplatz 2
D-40198 Düsseldorf
[login to unmask email]<mailto:[login to unmask email]>

ITERGO Informationstechnologie GmbH
Vorsitzender des Aufsichtsrats: Christian Diedrich
Geschäftsführung: Dr. Bettina Anders (Vorsitzende),
Lothar Engelke, Ina Kirchhof, Dr. Michael Regauer
Sitz: Düsseldorf, Handelsregister: Amtsgericht Düsseldorf HRB 37996

Von: Horacio Villa [mailto:[login to unmask email]
Gesendet: Sonntag, 18. Februar 2018 13:15
An: [login to unmask email]
Betreff: [DB2-L] - RE: DB2 z/OS: DSSIZE for UTS PBG TS


Hi Manabendra,

SECQTY -1 makes DB2 manage secondary allocations following an algorithm explained in the manuals.
With any other positive number you manage it.
I've been using -1 on SECQTY without problems.
It's up to you.
Kind regards,
Horacio

-----End Original Message-----
Attachments

  • image001.png (2.6k)

Ruediger Kurtz

AW: DB2 z/OS: DSSIZE for UTS PBG TS
(in response to Walter Janißen)
So do we, apart from „without any known problems“. ☺

Rüdiger


Rüdiger Kurtz
Abteilung Informatik – Betrieb

HUK-COBURG
Bahnhofsplatz
96444 Coburg
Telefon: 09561 96-44148
Telefax: 09561 96-44104
E-Mail: [login to unmask email]
Internet: www.huk.de
________________________________
HUK-COBURG Haftpflicht-Unterstützungs-Kasse kraftfahrender Beamter Deutschlands a. G. in Coburg
Reg.-Gericht Coburg HRB 100; St.-Nr. 9212/101/00021
Sitz der Gesellschaft: Bahnhofsplatz, 96444 Coburg
Vorsitzender des Aufsichtsrats: Prof. Dr. Heinrich R. Schradin.
Vorstand: Klaus-Jürgen Heitmann (Sprecher), Stefan Gronbach, Dr. Hans Olav Herøy, Dr. Jörg Rheinländer (stv.), Sarah Rössler, Daniel Thomas (stv.).
________________________________
Diese Nachricht enthält vertrauliche und/oder rechtlich geschützte Informationen.
Wenn Sie nicht der richtige Adressat sind oder diese Nachricht irrtümlich erhalten haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese Nachricht.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Nachricht ist nicht gestattet.

This information may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this information in error) please notify the
sender immediately and destroy this information.
Any unauthorized copying, disclosure or distribution of the material in this information is strictly forbidden.
________________________________
Von: Walter Janißen [mailto:[login to unmask email]
Gesendet: Montag, 19. Februar 2018 10:29
An: [login to unmask email]
Betreff: [DB2-L] - AW: DB2 z/OS: DSSIZE for UTS PBG TS

Hi

We even work with PROQTY and SECQTY = -1 with any known problems.

Kind regards
Walter Janißen [standard_IBM+Champ+7+Yr+Analytics]

ITERGO Informationstechnologie GmbH
Anwendungsentwicklung
Technische Anwendungsarchitektur
Victoriaplatz 2
D-40198 Düsseldorf
[login to unmask email]<mailto:[login to unmask email]>

ITERGO Informationstechnologie GmbH
Vorsitzender des Aufsichtsrats: Christian Diedrich
Geschäftsführung: Dr. Bettina Anders (Vorsitzende),
Lothar Engelke, Ina Kirchhof, Dr. Michael Regauer
Sitz: Düsseldorf, Handelsregister: Amtsgericht Düsseldorf HRB 37996

Von: Horacio Villa [mailto:[login to unmask email]
Gesendet: Sonntag, 18. Februar 2018 13:15
An: [login to unmask email]<mailto:[login to unmask email]>
Betreff: [DB2-L] - RE: DB2 z/OS: DSSIZE for UTS PBG TS


Hi Manabendra,

SECQTY -1 makes DB2 manage secondary allocations following an algorithm explained in the manuals.
With any other positive number you manage it.
I've been using -1 on SECQTY without problems.
It's up to you.
Kind regards,
Horacio
-----End Original Message-----

-----End Original Message-----

Myron Miller

DB2 z/OS: DSSIZE for UTS PBG TS
(in response to Walter Janißen)
PRIQTY of -1 is fine unless you are doing DSN1COPY to the table. Then it can and usually is a disaster. with -1,-1 and DSN1COPY, the priqty is also used (1 track) as the secondary. More than a few times, I've had DSN1COPY processes fail with space issues when we used to have -1,-1 for our targets for DSN1COPY. for tablespaces that are not DSN1COPIED, then -1,-1 works great. Use it almost everywhere except for any of our DSN1COPY targets and those always have real values specified.


Thanks Myron W. Miller


________________________________
From: Walter Jani&#223;en <[login to unmask email]>
Sent: Monday, February 19, 2018 4:29 AM
To: [login to unmask email]: [DB2-L] - AW: DB2 z/OS: DSSIZE for UTS PBG TS


Hi



We even work with PROQTY and SECQTY = -1 with any known problems.



Kind regards
Walter Janißen [standard_IBM+Champ+7+Yr+Analytics]

ITERGO Informationstechnologie GmbH
Anwendungsentwicklung
Technische Anwendungsarchitektur
Victoriaplatz 2
D-40198 Düsseldorf
[login to unmask email]<mailto:[login to unmask email]>

ITERGO Informationstechnologie GmbH
Vorsitzender des Aufsichtsrats: Christian Diedrich
Geschäftsführung: Dr. Bettina Anders (Vorsitzende),
Lothar Engelke, Ina Kirchhof, Dr. Michael Regauer
Sitz: Düsseldorf, Handelsregister: Amtsgericht Düsseldorf HRB 37996



Von: Horacio Villa [mailto:[login to unmask email]
Gesendet: Sonntag, 18. Februar 2018 13:15
An: [login to unmask email]
Betreff: [DB2-L] - RE: DB2 z/OS: DSSIZE for UTS PBG TS



Hi Manabendra,

SECQTY -1 makes DB2 manage secondary allocations following an algorithm explained in the manuals.
With any other positive number you manage it.
I've been using -1 on SECQTY without problems.
It's up to you.
Kind regards,
Horacio

-----End Original Message-----

-----End Original Message-----
Attachments

  • image001.png (2.6k)

Kai Stroh

RE: DB2 z/OS: DSSIZE for UTS PBG TS
(in response to Myron Miller)

Myron,

DSN1COPY has trouble populating a page set that was created with -1, -1 because it cannot mimic the way Db2 adds new extents to a data set. Db2 will make each new secondary extent larger than the previous one, except for the extent that will make the page set reach the DSSIZE (this extent will be sized so that the total resulting size is exactly the DSSIZE).

With DSN1COPY, every secondary extent will have the same small size - it will be whatever Db2 used as secondary allocation quantity when it cataloged the data set. For larger page sets, you will get a lot of small extents quickly, and the chance of getting a B37/D37/E37 is pretty high.

You can delete and redefine the target VSAM cluster with IDCAMS. Try to use the full size of the source VSAM as PRI if you can (use LISTCAT and look at the HI-U-RBA of the source data set). You can configure your SMS data class so that the system will split the data set into multiple extents, but it will still give you the requested size (look at "Space Constraint Relief", "Reduce Space Up To (%)", and maybe also "Dynamic Volume Count". After that, you will not run out of space during the DSN1COPY.

Best regards

Kai

 

In Reply to Myron Miller:

PRIQTY of -1 is fine unless you are doing DSN1COPY to the table. Then it can and usually is a disaster. with -1,-1 and DSN1COPY, the priqty is also used (1 track) as the secondary. More than a few times, I've had DSN1COPY processes fail with space issues when we used to have -1,-1 for our targets for DSN1COPY. for tablespaces that are not DSN1COPIED, then -1,-1 works great. Use it almost everywhere except for any of our DSN1COPY targets and those always have real values specified.

Myron Miller

DB2 z/OS: DSSIZE for UTS PBG TS
(in response to Kai Stroh)
thanks. but I know all the issues and how to fix them with DSN1COPY. i was just pointing out that -1 cannot and SHOULD NOT be used with DSN1COPY. We've been using DSN1COPY at my client's shop for well over 12 years and have run into just about anything you can imagine with it. But we copy about 700 tables a day and another 700 each weekend with it. And about 50% more indexes. Works great and our longest set is about 20 minutes.


Copya lot of production to prod-copy every day.


Thanks Myron W. Miller


________________________________
From: Kai Stroh <[login to unmask email]>
Sent: Tuesday, February 20, 2018 9:01 AM
To: [login to unmask email]
Subject: [DB2-L] - RE: DB2 z/OS: DSSIZE for UTS PBG TS


Myron,

DSN1COPY has trouble populating a page set that was created with -1, -1 because it cannot mimic the way Db2 adds new extents to a data set. Db2 will make each new secondary extent larger than the previous one, except for the extent that will make the page set reach the DSSIZE (this extent will be sized so that the total resulting size is exactly the DSSIZE).

With DSN1COPY, every secondary extent will have the same small size - it will be whatever Db2 used as secondary allocation quantity when it cataloged the data set. For larger page sets, you will get a lot of small extents quickly, and the chance of getting a B37/D37/E37 is pretty high.

You can delete and redefine the target VSAM cluster with IDCAMS. Try to use the full size of the source VSAM as PRI if you can (use LISTCAT and look at the HI-U-RBA of the source data set). You can configure your SMS data class so that the system will split the data set into multiple extents, but it will still give you the requested size (look at "Space Constraint Relief", "Reduce Space Up To (%)", and maybe also "Dynamic Volume Count". After that, you will not run out of space during the DSN1COPY.

Best regards

Kai



In Reply to Myron Miller:

PRIQTY of -1 is fine unless you are doing DSN1COPY to the table. Then it can and usually is a disaster. with -1,-1 and DSN1COPY, the priqty is also used (1 track) as the secondary. More than a few times, I've had DSN1COPY processes fail with space issues when we used to have -1,-1 for our targets for DSN1COPY. for tablespaces that are not DSN1COPIED, then -1,-1 works great. Use it almost everywhere except for any of our DSN1COPY targets and those always have real values specified.


-----End Original Message-----

Manabendra Datta

RE: DB2 z/OS: DSSIZE for UTS PBG TS
(in response to Myron Miller)

Thanks all for all the inputs.

Myron, we are also doing lots of Production to test data refresh, but, after V10, using unload with Internal format. 

DSN1COPY is good and lot more faster as long as the VSAM datasets are same in all respect. Still, it looks scary sometimes. That's why using unload load utilities only

Thanks,

Manabendra