Db2 for z/OS and its ecosystem

Db2 for z/OS and its ecosystem

Connect with Db2, Informix, Netezza, open source, and other data experts to gain value from your data, share insights, and solve problems.

 View Only

Now available in Db2 11 for z/OS: Changes to address problems after Db2 for zOS table definition changes

By Paul McWilliams posted Mon December 09, 2019 02:06 PM

  

This Db2 for z/OS News from the Lab blog entry was originally published on 2018-02-13.

By Frances Villafuerte and Judy Tobias

Recently, we delivered changes to Db2 12 for z/OS to address issues like these:

  • Database administrators commonly use an offline utility, such as DSN1COPY, to copy tables from one subsystem to another. When the copied tables have recent definition changes, the table definitions in the target catalog can become out of sync with the table data.

  • Most table definition changes generate new table versions. A maximum of 255 table versions are available, and when table spaces contain a lot of tables, you are likely to make many table definition changes and use all those versions quickly. When all the versions are used, you cannot perform any more table definition changes until you run REORG and MODIFY RECOVERY to recycle some versions. However, if any tables are at version 0, you cannot release any versions. Database administrators have indicated that they need Db2 changes to resolve this situation.

We now provide similar changes to Db2 11 for z/OS for the problems listed above. All single-table or multiple-table table spaces can benefit from the changes, except work file table spaces, XML table spaces, and LOB table spaces.

  • To prevent problems due to a table’s data getting out of sync with the table’s catalog definition, Db2 writes information about the table structure in the table space's system pages. As a result, Db2 can determine a table’s structure without looking in the catalog. Db2 inserts this information automatically when you insert or update a row or run LOAD on an existing table, or run REORG on the table space that contains the table, even when the table definition has had no changes.

  • To make it possible to release versions when a table space has tables at version 0 and at version 255, the REPAIR utility has the new SETCURRENTVERSION option, which you specify with INSERTVERSIONPAGES. The SETCURRENTVERSION option changes the version number for any tables in the table space that are at version 0 to the current version of the table space. After this, you can run the REORG utility followed by the MODIFY RECOVERY utility to recycle unused table space versions.

To take advantage of these changes, apply the PTFs for these APARs: PI75145, PI76179, PI76461,PI76462, PI80006, and PI81005

Related information




#Db2forz/OS
#db2z/os
#Db2Znews
0 comments
6 views

Permalink