tag:blogger.com,1999:blog-4516533711330247058.post1165565436769146212..comments2024-03-28T07:32:09.246-07:00Comments on Robert's Db2 blog: Db2 12 for z/OS RPN Table Spaces: New Possibilities for Range-Partitioned TablesRoberthttp://www.blogger.com/profile/02058625981006623480noreply@blogger.comBlogger39125tag:blogger.com,1999:blog-4516533711330247058.post-54504357448847617952022-10-31T08:27:13.717-07:002022-10-31T08:27:13.717-07:00Understood. Keep in mind that if an online REORG f...Understood. Keep in mind that if an online REORG fails for some reason, the "original" objects (i.e., the target table space and associated objects such as indexes) are still available for use, because they have not been affected by the online REORG that failed to complete (that is one of the great things about online REORG, versus execution of REORG with SHRLEVEL NONE). In that case, older image copies (associated with absolute page numbering for the table space) are of course still usable. The new image copy (the inline image copy generated during the REORG that is executed to implement relative page numbering) will only be needed if the online REORG completes successfully, and those image copies (assuming you have REORG generate both a primary and a backup inline image copy) will be available following successful execution of REORG, because they are generated well before the final phase of REORG (the SWITCH phase).<br /><br />RobertRoberthttps://www.blogger.com/profile/02058625981006623480noreply@blogger.comtag:blogger.com,1999:blog-4516533711330247058.post-54698524098074733022022-10-31T02:31:19.029-07:002022-10-31T02:31:19.029-07:00Robert, thanks for your reply. The risk is indeed ...Robert, thanks for your reply. The risk is indeed not in taking the inline IC, but the fact that all previous IC's are invalidated because of the change to RPN. The actual reorg will take about 3-4 days to complete for the whole table.Guusnoreply@blogger.comtag:blogger.com,1999:blog-4516533711330247058.post-28810870096051801592022-10-27T14:37:21.107-07:002022-10-27T14:37:21.107-07:00Actually, it's an "inline" - not an ...Actually, it's an "inline" - not an "online" - image copy that is taken when you run an online REORG. I do not see taking an inline image copy of a table space as being a risky thing. You HAVE to take an inline image copy when REORG TABLESPACE is executed with SHRLEVEL CHANGE or SHRLEVEL REFERENCE.<br /><br />RobertRoberthttps://www.blogger.com/profile/02058625981006623480noreply@blogger.comtag:blogger.com,1999:blog-4516533711330247058.post-25046565439778931362022-10-27T07:14:48.419-07:002022-10-27T07:14:48.419-07:00Hi Robert,
we are planning to go from a huge PBR ...Hi Robert, <br />we are planning to go from a huge PBR table into a RPN table, by altering to relative page numbering and do a full reorg. I understood that the earlier ImageCopies are invalidated once the Reorg has finished, but we can create an online IC during REORG. Are there any risks in doing it by this sequence of actions, whereas I am a bit afraid of having no fall-back scenario ..Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4516533711330247058.post-58111906468963720832022-10-04T14:15:44.699-07:002022-10-04T14:15:44.699-07:00There really aren't any "gotchas" to...There really aren't any "gotchas" to speak of with regard to going from absolute to relative page numbering for a universal range-partitioned table space. In a Db2 13 for z/OS environment, the default value for the PAGESET_PAGENUM parameter in ZPARM goes from ABSOLUTE to RELATIVE - that makes RPN the default page numbering scheme for new PBR table spaces in a Db2 13 system. Additionally, when you take advantage of online conversion of a PBG table space to PBR in a Db2 13 system (an enhancement available when function level V13R1M500 is activated), the new PBR table space will use relative page numbering.<br /><br />I would not expect a difference in table space size as a result of going from absolute to relative page numbering. Indexes on a PBR table space would get a little larger as a result of changing to RPN for the table space, as a result of row IDs (RIDs) going to 7 bytes apiece from 5 bytes apiece.<br /><br />RobertRoberthttps://www.blogger.com/profile/02058625981006623480noreply@blogger.comtag:blogger.com,1999:blog-4516533711330247058.post-76441180224460393042022-10-04T07:45:57.847-07:002022-10-04T07:45:57.847-07:00Hi. We have several candidates for conversion to R...Hi. We have several candidates for conversion to RPN. I was wondering what the gotchas are. For example, do you know how much additional space the new RPN tablespace would use initially? Is there any difference in the amount of logging generated by the RPN? Is it worth it to convert smaller PBRs to RPN as maybe eventually all PBR tablespaces will be RPN by default in the future? Any other gotchas that we should be aware of before embarking on this journey?<br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4516533711330247058.post-37657897111787272952022-08-18T08:12:05.416-07:002022-08-18T08:12:05.416-07:00Robert,
Thanks for the quick reply and the great i...Robert,<br />Thanks for the quick reply and the great information. I had not seen that APAR but that is great news and appears to alleviate my concerns. <br /><br />Thank you!<br />SteveAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-4516533711330247058.post-40159460817143246112022-08-18T07:21:26.398-07:002022-08-18T07:21:26.398-07:00Hello, Steve. Apologies for the delay in respondin...Hello, Steve. Apologies for the delay in responding.<br /><br />The situation of concern that you've brought up was addressed by Db2 for z/OS APAR PI75518 (see https://www.ibm.com/support/pages/apar/PI75518). This APAR removed the requirement that each partition of a table space being converted to RPN be image copied to its own data set, and introduced two new ZPARMs (and associated REORG keywords that can be used to override the ZPARM-specified values) that serve to limit the number of disk or tape image copy data sets that REORG can allocate.<br /><br />The fix for APAR PI75518 came out around the end of June in 2021.<br /><br />RobertRoberthttps://www.blogger.com/profile/02058625981006623480noreply@blogger.comtag:blogger.com,1999:blog-4516533711330247058.post-382540252639875352022-08-17T15:04:17.066-07:002022-08-17T15:04:17.066-07:00Hi Robert. To convert to RPN we have to reorg the ...Hi Robert. To convert to RPN we have to reorg the entire tablespace at once, and there is an image copy created for each partition. Many of our tablespaces have 254 partitions. We don't have 254 tape drives, and 254 image copy files on DASD would be a lot of DASD (and how long to keep those for recovery)... I see the new parms for the REORG TABLESPACE utility called ICLIMIT_DASD and ICLIMIT_TAPE. Would those parms help in this situation? Any other hints/tips you can suggest?<br />Thanks in advance,<br />SteveAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-4516533711330247058.post-46734117795374707192022-06-06T20:09:12.582-07:002022-06-06T20:09:12.582-07:00You cannot increase the DSSIZE of a LOB table spac...You cannot increase the DSSIZE of a LOB table space through an alter of the associated base table space - you have to directly alter the LOB table space in question. And yes, that ALTER of the LOB table space will be a pending change, and will be materialized (i.e., put into effect) through an online REORG of the LOB table space following execution of the DSSIZE-changing ALTER of the LOB table space.Roberthttps://www.blogger.com/profile/02058625981006623480noreply@blogger.comtag:blogger.com,1999:blog-4516533711330247058.post-75540792686857384592022-06-06T07:29:02.818-07:002022-06-06T07:29:02.818-07:00Thank you for your prompt reply. I tried altering ...Thank you for your prompt reply. I tried altering (increasing) DSSIZE at the partition level of the base tablespace (type=R) of a LOB Table but it would not. Is that an anomaly or maybe I am doing something wrong. It lets me do it as pending change at the base tablespace level.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4516533711330247058.post-89246173393636417632022-06-04T06:27:11.670-07:002022-06-04T06:27:11.670-07:00There is no such thing as a LOB PBR RPN table spac...There is no such thing as a LOB PBR RPN table space. There are LOB table spaces, and there are PBR RPN table spaces. A PBR RPN table space can have a LOB column (or columns), and if it does then there will be a LOB table space for each LOB column of each partition of the PBR RPN table space, but the PBR RPN table space and its associated LOB table spaces are physically distinct and different database objects. A DSSIZE change will be an immediate change only if the target table space is PBR RPN and the new DSSIZE is larger than the previous DSSIZE. For a LOB table space a DSSIZE change will be a pending change, materialized by way of a subsequent online REORG of the LOB table space.<br /><br />Robert Roberthttps://www.blogger.com/profile/02058625981006623480noreply@blogger.comtag:blogger.com,1999:blog-4516533711330247058.post-40237169514838327052022-06-02T11:05:47.292-07:002022-06-02T11:05:47.292-07:00Is DSSIZE is an immediate change for LOB PBR RPN ?...Is DSSIZE is an immediate change for LOB PBR RPN ?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4516533711330247058.post-62166976811110638202021-12-30T09:16:59.194-08:002021-12-30T09:16:59.194-08:00Yes, when absolute page numbering is in effect, a ...Yes, when absolute page numbering is in effect, a RID value will be a 5-byte field. The first 4 bytes are used for the page number, and the last byte holds the page ID map entry number associated with the particular row.<br /><br />RobertRoberthttps://www.blogger.com/profile/02058625981006623480noreply@blogger.comtag:blogger.com,1999:blog-4516533711330247058.post-75180162967843934352021-12-30T08:02:32.017-08:002021-12-30T08:02:32.017-08:00Thanks Robert,
I have one question.
In the absolut...Thanks Robert,<br />I have one question.<br />In the absolute page numbering scheme , can you please elaborate how big is the RID, is it 5 bytes(4bytes for the page number and 1 byte for the row number with in the page) ?<br />Thanks for ur time.Chhttps://www.blogger.com/profile/03040327371358982166noreply@blogger.comtag:blogger.com,1999:blog-4516533711330247058.post-21979498235253366872021-10-21T14:24:26.638-07:002021-10-21T14:24:26.638-07:00I'm glad that the information has been helpful...I'm glad that the information has been helpful for you.<br /><br />Robert Roberthttps://www.blogger.com/profile/02058625981006623480noreply@blogger.comtag:blogger.com,1999:blog-4516533711330247058.post-59022688764948240622021-10-20T08:45:29.141-07:002021-10-20T08:45:29.141-07:00Thanks a lot Robert for sharing more Technical inf...Thanks a lot Robert for sharing more Technical information. That really helped a lot !!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4516533711330247058.post-63734785622900939982021-09-10T19:02:49.068-07:002021-09-10T19:02:49.068-07:00Yes, for an RPN table space an enlargement of a pa...Yes, for an RPN table space an enlargement of a partition's DSSIZE value must be done explicitly via ALTER TABLESPACE with ALTER PARTITION. Max DSSIZE value for an RPN table space is 1024G (equal to 1 TB). Max size for an RPN table space as a whole is 4096 TB.<br /><br />Yes, when an online REORG is executed to materialize a change to RPN for a table space, dependent packages will be invalidated at the conclusion of the REORG.<br /><br />RobertRoberthttps://www.blogger.com/profile/02058625981006623480noreply@blogger.comtag:blogger.com,1999:blog-4516533711330247058.post-86887108873104896482021-09-10T08:25:41.392-07:002021-09-10T08:25:41.392-07:00Thanks Rob... Iniitial misunderstanding for us was...Thanks Rob... Iniitial misunderstanding for us was ,PAGENUM RELATIVE changes will implicitly allow the growth of the tablespace upto 1 TB. Then realized explicit DSSIZE changes are required.<br /><br />We considered REBIND also post the above changes .Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4516533711330247058.post-82538480711800644802021-09-09T19:54:45.045-07:002021-09-09T19:54:45.045-07:00To go from an existing PBR table space that uses a...To go from an existing PBR table space that uses absolute page numbering to an RPN table space, two actions are required: 1) ALTER TABLESPACE with PAGENUM RELATIVE, and 2) and online REORG to materialize the pending change.<br /><br />After the table space has been changed to use RPN, an individual partition's DSSIZE can be enlarged with an ALTER, and that will be an immediate change - the partition can grow beyond its former DSSIZE with no need to REORG the partition.<br /><br />RobertRoberthttps://www.blogger.com/profile/02058625981006623480noreply@blogger.comtag:blogger.com,1999:blog-4516533711330247058.post-73446852158664118972021-09-09T02:40:35.963-07:002021-09-09T02:40:35.963-07:00Hi Rob,
For changing the Existing PBR Tablespaces ...Hi Rob,<br />For changing the Existing PBR Tablespaces its three step approach <br />1. ALTER TABLE SPACE with PAGENUM RELATIVE attribute <br />2.Reorg<br />3.Alter DSSIZE for required partition alone WITHOUT reorg.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4516533711330247058.post-17006154614645930432021-05-21T08:34:02.138-07:002021-05-21T08:34:02.138-07:00Sorry about the delay in responding.
Are you requ...Sorry about the delay in responding.<br /><br />Are you requesting that I post an entry to this blog on the topic of recovering a table space? Db2 for z/OS data backup and recovery is covered quite thoroughly in the product documentation - see https://www.ibm.com/docs/en/db2-for-zos/12?topic=recovery-backing-up-recovering-your-data.<br /><br />More specific information on table space recovery can be found on this page in the product documentation: https://www.ibm.com/docs/en/db2-for-zos/12?topic=data-preparation-recovery-scenario.<br /><br />Robert<br /><br />Roberthttps://www.blogger.com/profile/02058625981006623480noreply@blogger.comtag:blogger.com,1999:blog-4516533711330247058.post-31819692892537356182021-05-13T03:06:23.709-07:002021-05-13T03:06:23.709-07:00Hi Robert
good topics are covered.
I request to ha...Hi Robert<br />good topics are covered.<br />I request to have db2 recovery topic on table space level which is having much deletes/updates happened after a full image copyworldtechnolologyexperthttps://www.blogger.com/profile/10198287438723995615noreply@blogger.comtag:blogger.com,1999:blog-4516533711330247058.post-85447792022384990282021-04-12T00:22:40.954-07:002021-04-12T00:22:40.954-07:00Thanks Rob!Thanks Rob!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4516533711330247058.post-48601727732692687452021-04-10T10:27:51.767-07:002021-04-10T10:27:51.767-07:00A partitioned index is one that id defined with a ...A partitioned index is one that id defined with a PARTITIONED specification. A partitioning index is one whose key either is the underlying table's partitioning key, or whose key begins with the underlying table's partitioning key; thus, the only difference between a partitioned partitioning index and a non-partitioned partitioning index is the PARTITIONED specification. Frankly, I do not see why a partitioning index would not also be defined as PARTITIONED.<br /><br />RobertRoberthttps://www.blogger.com/profile/02058625981006623480noreply@blogger.com