Availability
This chapter introduces availability improvements by the following enhancements:
4.1 Improved availability for pending definition changes
DB2 12 introduces availability improvements for pending definition changes, allowing applications to access objects that in the previous DB2 releases had a restriction status that prevented the access. This section describes two enhancement improvements:
•Altering index compression attribute
•Altering column
4.1.1 Altering index compression attribute
Indexes with a page size greater than 4 KB can be compressed to 4K page on DB2, and as a result, DASD space is saved and achieves improved I/O efficiency.
However, when the compress attribute of an index in universal table space was altered, the index was marked as a rebuild pending (RBDP) status, preventing applications from using the index until the REORG TABLESPACE utility or the REBUILD INDEX utility completed.
DB2 12 introduces an improvement to the availability of indexes in universal table spaces, now alterations to index compression are a pending change, placing the index in advisory REORG-pending (AREOR) status, therefore applications can continue to access the indexes.
The updated value for the COMPRESS attribute in the ALTER INDEX statement is materialized by a subsequent online REORG INDEX or online REORG TABLESPACE at the table space level. With this improvement, database administrators can correct or remove a pending change to index compression without affecting the target index. Also, this improvement reduces the planning and costs that are associated with an application outage caused by the previous behavior in DB2 11.
A new record is inserted in the SYSIBM.SYSPENDINGDDL catalog table with the following information, when an ALTER INDEX COMPRESS is issued:
•OBJTYPE column = 'I'
•OPTION_KEYWORD = 'COMPRESS'
•OPTION_VALUE = 'xxx' ('YES' or 'NO')
 
Notes:
•If the index is defined with the DEFINE NO attribute and data sets are not created yet, the alteration is still immediate.
•Also, for an index that is not in a universal table space, an alteration to index compression can be a pending change if other pending changes exist at the index, table, or table space level when the ALTER INDEX COMPRESS statement runs.
4.1.2 Altering column
In the previous DB2 releases, DB2 provided the capability to alter column attributes such as data type, length, precision, or scale of columns for a table through ALTER TABLE statement with the ALTER COLUMN clause, but these alterations impact the availability or extra performance overhead is required.
For example, in DB2 11, some column definition changes are immediate changes. That means the affected indexes on the table are put in a restricted status. These indexes are not available to be used in an access path optimization process. If a unique index is placed in restrictive status, it results in an outage to the table.
DB2 12 enables ALTER COLUMN statements that change the data type, length, precision, or scale of columns in pending alterations.
For more information about columns be pending alteration, see 9.3, “Column level deferred alter (pending alter column)” on page 154.
4.2 Catalog availability improvements
This section describes the following catalog availability improvements in DB2 12:
•Handling dynamic SQL statement
•Single phase catalog migration
4.2.1 Handling dynamic SQL statement
When a transaction issues dynamic SQL statements, DB2 dynamically prepares the SQL statements for execution. During preparation of dynamic SQL, DB2 acquires read claims on several catalog table spaces and related indexes, and acquired a DBD lock on the catalog. The DBD lock is needed to serialize catalog operations with CATMAINT and other DDL that can execute against the catalog.
In previous releases of DB2, the transaction released the DBD lock and the read claims at commit points. If transactions with dynamic SQL statements did not issue commit operations for a long period of time, CATMAINT and online REORG on the catalog were blocked during that long period.
DB2 12 manages releases DBD locks on the catalog and read claims against catalog objects, as soon as PREPARE statement execution is complete, so this change improves availability for CATMAINT utility and online REORG on catalog objects.
4.2.2 Single phase catalog migration
In DB2 11, the catalog is converted to DB2 11 format during migration to conversion mode. Then, it is converted again during the enable new function mode. Each time the catalog is updated, that can impact applications that access the catalog and other internal DB2 activities such as real-time statistics, which also updates certain catalog tables. These contentions can result in an unavailable resource condition and failed application or catalog update processes.
DB2 12 improves availability on the catalog resource by having only a single-phase migration. There is only one CATMAINT job to convert the catalog to DB2 12 level. The V12R1M500 catalog level can be used for new function activation (to get to new-function mode) and handled by the coexistence of fallback DB2 11 also. For more information, see Chapter 12, “Installation and migration” on page 199.
4.3 Removal of point-in-time recovery restrictions for PBG table spaces
In DB2 12, the following restrictions were removed for point-in-time (PIT) recovery for partition-by-growth (PBG) table spaces:
•Alteration of SEGSIZE
•Alteration of DSSIZE
•Alteration of Buffer Pool
•Alteration of MEMBER CLUSTER
With these restrictions removed, DB2 enables the data to be available for recovery even after any of those alterations were performed. In this way, running an additional REORG to materialize the data and then recover to the required recovery point is unnecessary.
4.4 PBR RPN DSSIZE increase
DB2 12 introduces a solution for the scenario described above described in 4.3, “Removal of point-in-time recovery restrictions for PBG table spaces” on page 46. A new type of partition-by-range (PBR) structure called partition-by-range relative page numbering (PBR RPN) allows DSSIZE to grow up to 1 TB for a partition. Also, the maximum table size has increased from 16 TB (4K page) to 4 PB, and designed to grow even larger.
PBR RPN improves application availability when is necessary to change the DSSIZE because up to DB2 11 a REORG execution was required and now an immediate ALTER is allowed, this way, not preventing the access to the related objects.
For more information about PBR RPN structure characteristics and more considerations, see Chapter 3, “Scalability” on page 33.
4.5 Insert partition
DB2 12 allows a partition be added in the middle of the table dynamically through the ALTER statement. With this enhancement, the availability of the objects is much better because the objects do not have to be dropped, re-created, and populated with data.
4.6 REORG enhancements for PBGs, FlashCopy and LOBs
This section describes the following REORG enhancements:
4.6.1 Partition-by-growth (PBG)
In DB2 12, the REORG utility is improved to support the creation of a new PBG partition for overflow rows during a partition-level REORG, thereby improving the availability of data.
For more detailed information about REORG enhancements related to PBG table space, see Chapter 11, “Utilities” on page 177.
4.6.2 FlashCopy
DB2 12 avoids leaving the page set in COPY-pending when the REORG utility is run to create an inline FlashCopy with no sequential inline image copy and FlashCopy fails. If FlashCopy runs unsuccessfully, the REORG completes with a return code of 8.
For more detailed information about REORG enhancements related to improve FlashCopy management, see Chapter 11, “Utilities” on page 177.
4.6.3 Large object (LOB)
A new feature in DB2 12 prevents the COPY-pending restriction status on a LOB table space during REORG of partition-by-growth (PBG). An inline image copy is allocated for the new LOB table space that is created.
For more detailed information about REORG enhancements that are related to prevention of COPY-pending on a LOB table space, see Chapter 11, “Utilities” on page 177.
4.7 LOAD RESUME YES BACKOUT YES option
The LOAD utility applying the RESUME YES BACKOUT YES function was retrofitted to DB2 11 and is now available in DB2 12.
DB2 availability is improved because when the RESUME YES BACKOUT YES function is specified, all rows loaded by the current LOAD should be deleted if any input record has violations. The table space is available at the completion of the LOAD.
BACKOUT or BACKOUT YES is allowed with only SHRLEVEL NONE. BACKOUT or BACKOUT YES is not allowed with INCURSOR.
Figure 4-1 shows the syntax diagram for LOAD RESUME YES BACKOUT YES.
Figure 4-1 Syntax diagram for LOAD RESUME YES BACKOUT YES
4.8 Faster point-in-time recovery
Point-in-time recovery can run faster with the following enhancements that are described in this section, improving the availability of the related objects in the recovery:
4.8.1 Single object by defaulting to the PARALLEL(1) option
This option indicates that the RECOVER utility should perform parallel restoring of image copies when processing multiple objects. However, the PARALLEL(1) option can also improve performance for recovery of a single object. In DB2 12, the RECOVER utility defaults to use the PARALLEL(1) option even for recovery of a single object, thereby improving the performance of data recovery. 
4.8.2 SCOPE UPDATED keyword
DB2 12 introduces the SCOPE UPDATED keyword, applied when the RECOVER utility uses the TORBA option or the TOLOGPOINT option. As a result, the RECOVER utility runs faster because the objects that are specified in LISTDEFlist that have not changed since the recovery point are not recovered. DB2 12 does not waste time recovering unnecessary data sets.
For more information about SCOPE UPDATE keyword, see Chapter 11, “Utilities” on page 177.
4.9 TRANSFER OWNERSHIP SQL statement
DB2 12 introduces the TRANSFER OWNERSHIP SQL statement, providing support for changing ownership of an object while keeping the object available. Up through DB2 11, the object must be dropped and re-created, which affects availability.
More detailed information related to TRANSFER OWNERSHIP SQL statement is in Chapter 10, “Security” on page 167.
4.10 Auto-retry of GRECP and LPL recovery
DB2 12 implements retry logic for the logical page list (LPL) and group buffer pool recovery pending (GRECP) recovery works. This logic is applied when automatic recovery of GRECP and LPL fail, so the object becomes available faster.
For more information about how auto-retry of GREPC and LPL recovery works, see Chapter 5, “Data sharing” on page 49.
 
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset