Answer to Philip's question
https://www.ibm.com/docs/en/db2-for-zos/12?topic=structures-rules-primary-secondary-space-allocation
James Campbell
On 25 Apr 2022 at 13:20, Roy Boxwell via International wrote:
> In Db2 12 the MGEXTSZ was dropped and is permanently set to YES this means that any non zero positive value for SECQTY is transferred into the Db2 sliding scale of getting upto around 500 Cylinders per extent for really big objects!
>
> Roy Boxwell
>
> SOFTWARE ENGINEERING GmbH and SEGUS Inc.
> -Product Development-
>
>
>
> Vagedesstrasse 19
> 40479 Dusseldorf/Germany
> Tel. +49 (0)211 96149-675
> Fax +49 (0)211 96149-32
> Email:
R.Boxwell@seg.de> Web
http://www.seg.de> Link zur Datenschutzerklärung
>
> Software Engineering GmbH
> Amtsgericht Düsseldorf, HRB 37894
> Geschäftsführung: Gerhard Schubert, Ulf Heinrich
>
> -------------------------------------------
> Original Message:
> Sent: 4/25/2022 9:11:00 AM
> From: Philip Sevetson
> Subject: RE: SSD Ramifications?
>
> Roy,
>
> Something's nagging at me about this post. Aging brain :-( won't serve it up, but it has to do with limits on secondary extents.
>
> Does anyone remember off-hand where the DB2 limit values are documented? Specifically, the maximum size of secondary extents and the maximum size which autonomic management (SECQTY -1) will grow to (and has that been fixed recently for the largest DSSIZE values)?
>
>
> Philip Sevetson
>
>
>
> -------------------------------------------
> Original Message:
> Sent: 4/25/2022 4:37:00 AM
> From: Roy Boxwell
> Subject: RE: SSD Ramifications?
>
> Just for completeness:
>
> Limit of 59 Volumes with 123 extents per volumes gives you the upper limit of 7,257 absolute maximum number of extents.
> The use of huge EAVs is always a little dangerous as people tend to forget the 123 per volume rule...
>
> Roy Boxwell
>
> SOFTWARE ENGINEERING GmbH and SEGUS Inc.
> -Product Development-
>
>
>
> Vagedesstrasse 19
> 40479 Dusseldorf/Germany
> Tel. +49 (0)211 96149-675
> Fax +49 (0)211 96149-32
> Email:
R.Boxwell@seg.de> Web
http://www.seg.de> Link zur Datenschutzerklärung
>
> Software Engineering GmbH
> Amtsgericht Düsseldorf, HRB 37894
> Geschäftsführung: Gerhard Schubert, Ulf Heinrich
>
> -------------------------------------------
> Original Message:
> Sent: 4/25/2022 4:30:00 AM
> From: Steven Lamb
> Subject: RE: SSD Ramifications?
>
> The limit of the total number of volumes that a dataset can exist on (59 / 60?) does still apply, so although things are faster there are still some basic checks to make.
>
> Regards,
> Steve
>
> ------------------------------
> Steven Lamb
> ------------------------------
> -------------------------------------------
> Original Message:
> Sent: Apr 21, 2022 04:23 PM
> From: Mark Wieczorkowski
> Subject: SSD Ramifications?
>
> Are you talking ACTUAL 3390 disks??
>
>
> I didn't know those were still in operation. I'm assuming you mean you're converting from rotating disks in your disk subsystems to SSDs. :)
>
> If you have a lot of random synchronous I/O it can only help. Might reduce your disconnect times. But with modern DSSes, most of the I/O is back and forth from cache anyway.
>
> Now if you ARE converting from ACTUAL 3390s...basically, your disk is about to jump from lightspeed to ludicrous speed. Also, all of that stuff, tracks, cylinders, etc...pretty much goes out the window. The 3390 device that z/OS sees is a logical emulation, an illusion fronted to it by the DSS controller. On the back-end, none of that matters, the DSS is going to manage the data the way it wants, and there's nothing really that a Db2 DBA can do to influence that...it's a matter for the storage admins.
>
> Even extents don't matter like they used to. We have many DBAs who still want to REORG the second they see a secondary extent. And there's still SOME merit to keeping as much data as possible in a single contiguous primary, just because it takes a while at dataset open to build the control-block structure for a dataset with multiple extents. But it doesn't affect the actual I/O process pretty much at all, whether you have 1 secondary or 100. That's why IBM pushes "-1, -1" so hard.
>
> IBM is really trying to let DBAs do DBA stuff and storage admins do storage stuff. The DBAs should be using SMS by now for Db2 data...they can explore things like SECQTY -1, UTS PBG using DSSIZE and MAXPARTITIONS to control space allocations instead of PRIQTY/SECQTY and manually managing extents. Those kinds of things. Cylinders and tracks are all virtual/logical at this point...something that the DSS emulates to z/OS.
>
> Otherwise...sit back and enjoy the performance.
>
> ------------------------------
> Mark Wieczorkowski
> ------------------
> Db2 Systems Programmer, SSA/DCS
> Principal - Solipsistic, LLC
> ------------------------------
>
> Original Message:
> Sent: Apr 21, 2022 03:23 PM
> From: David Lueck
> Subject: SSD Ramifications?
>
> We are in the process of converting our 3390 disk storage to SSD.
>
> Are there any ramifications that our DBA team should be aware of?
>
> How would this impact BLKSIZE or CYL?
>
> Is the CLUSTER index still important?
>
> I'm not finding much information on these questions.
>
> Thanks for any advice.
>
> ------------------------------
> David Lueck
> IT Manager, DBA
> Western Illinois University
> ------------------------------
>
Original Message:
Sent: 4/25/2022 9:21:00 AM
From: Roy Boxwell
Subject: RE: SSD Ramifications?
In Db2 12 the MGEXTSZ was dropped and is permanently set to YES this means that any non zero positive value for SECQTY is transferred into the Db2 sliding scale of getting upto around 500 Cylinders per extent for really big objects!
Roy Boxwell
SOFTWARE ENGINEERING GmbH and SEGUS Inc.
-Product Development-
Vagedesstrasse 19
40479 Dusseldorf/Germany
Tel. +49 (0)211 96149-675
Fax +49 (0)211 96149-32
Email: R.Boxwell@seg.de
Web http://www.seg.de
Link zur Datenschutzerklärung
Software Engineering GmbH
Amtsgericht Düsseldorf, HRB 37894
Geschäftsführung: Gerhard Schubert, Ulf Heinrich
Original Message:
Sent: 4/25/2022 9:11:00 AM
From: Philip Sevetson
Subject: RE: SSD Ramifications?
Roy,
Something's nagging at me about this post. Aging brain :-( won't serve it up, but it has to do with limits on secondary extents.
Does anyone remember off-hand where the DB2 limit values are documented? Specifically, the maximum size of secondary extents and the maximum size which autonomic management (SECQTY -1) will grow to (and has that been fixed recently for the largest DSSIZE values)?
Original Message:
Sent: 4/25/2022 4:37:00 AM
From: Roy Boxwell
Subject: RE: SSD Ramifications?
Just for completeness:
Limit of 59 Volumes with 123 extents per volumes gives you the upper limit of 7,257 absolute maximum number of extents.
The use of huge EAVs is always a little dangerous as people tend to forget the 123 per volume rule...
Roy Boxwell
SOFTWARE ENGINEERING GmbH and SEGUS Inc.
-Product Development-
Vagedesstrasse 19
40479 Dusseldorf/Germany
Tel. +49 (0)211 96149-675
Fax +49 (0)211 96149-32
Email: R.Boxwell@seg.de
Web http://www.seg.de
Link zur Datenschutzerklärung
Software Engineering GmbH
Amtsgericht Düsseldorf, HRB 37894
Geschäftsführung: Gerhard Schubert, Ulf Heinrich
Original Message:
Sent: 4/25/2022 4:30:00 AM
From: Steven Lamb
Subject: RE: SSD Ramifications?
The limit of the total number of volumes that a dataset can exist on (59 / 60?) does still apply, so although things are faster there are still some basic checks to make.
Regards,
Steve
------------------------------
Steven Lamb
------------------------------
Original Message:
Sent: Apr 21, 2022 04:23 PM
From: Mark Wieczorkowski
Subject: SSD Ramifications?
Are you talking ACTUAL 3390 disks??
If you have a lot of random synchronous I/O it can only help. Might reduce your disconnect times. But with modern DSSes, most of the I/O is back and forth from cache anyway.
Now if you ARE converting from ACTUAL 3390s...basically, your disk is about to jump from lightspeed to ludicrous speed. Also, all of that stuff, tracks, cylinders, etc...pretty much goes out the window. The 3390 device that z/OS sees is a logical emulation, an illusion fronted to it by the DSS controller. On the back-end, none of that matters, the DSS is going to manage the data the way it wants, and there's nothing really that a Db2 DBA can do to influence that...it's a matter for the storage admins.
Even extents don't matter like they used to. We have many DBAs who still want to REORG the second they see a secondary extent. And there's still SOME merit to keeping as much data as possible in a single contiguous primary, just because it takes a while at dataset open to build the control-block structure for a dataset with multiple extents. But it doesn't affect the actual I/O process pretty much at all, whether you have 1 secondary or 100. That's why IBM pushes "-1, -1" so hard.
IBM is really trying to let DBAs do DBA stuff and storage admins do storage stuff. The DBAs should be using SMS by now for Db2 data...they can explore things like SECQTY -1, UTS PBG using DSSIZE and MAXPARTITIONS to control space allocations instead of PRIQTY/SECQTY and manually managing extents. Those kinds of things. Cylinders and tracks are all virtual/logical at this point...something that the DSS emulates to z/OS.
Otherwise...sit back and enjoy the performance.
------------------------------
Mark Wieczorkowski
------------------
Db2 Systems Programmer, SSA/DCS
Principal - Solipsistic, LLC
Original Message:
Sent: Apr 21, 2022 03:23 PM
From: David Lueck
Subject: SSD Ramifications?
We are in the process of converting our 3390 disk storage to SSD.
Are there any ramifications that our DBA team should be aware of?
How would this impact BLKSIZE or CYL?
Is the CLUSTER index still important?
I'm not finding much information on these questions.
Thanks for any advice.
------------------------------
David Lueck
IT Manager, DBA
Western Illinois University
------------------------------