#IDUG
11 Tips for DB2 11 for z/OS
Cüneyt Göksu
IBMSession Code: A07
Day, Date (Time) (15:15 - 16:15 on Tuesday 11th November). | Platform: DB2 for z/OS
#IDUG
Agenda
• Global Variables• ALTER Partition Key Limits Online• Select from Directory• Drop Column• Auto Mapping Tables• Transparent Archiving• Runstats Enhancements• Recovery Support for Deferred schema changes• Pseudo deleted index key cleanup• LOAD SHRLEVEL CHANGE with PARALLEL option• New zParms
Highlights of my favorite V11 enhancements
#IDUG
Global Variables
Long expected DB2 for z/OS feature
• Enable the sharing of data between SQL statements w/o the need for application logic.• Maintained by DB2, available throughout the entire application scope.• Have access controlled by GRANT and REVOKE statements.• New CREATE VARIABLE statement, saved in DB2 catalog• Associated with a specific application, value unique to the application• The content is shared among the SQL statements within the same connection,• Similar to DB2 special registers• Initiated upon the first reference.• If created with the DEFAULT clause, the default expression is evaluated during first access• If no DEFAULT is specified, NULL is used as the default value• Can appear in expression, predicates, and select list.• The content of the Global Variables persist across reusable threads.• A reused thread keeps all values recorded from the previous thread.
#IDUG
Global Variables
#IDUG
ALTER Partition Key Limits Online
REORG TABLESPACE REBALANCE or ALTER TABLE <limit keys>
• Online alter limit key = In Version 11, Change limit keys of a partitioned table space withoutimpacting the availability of the data.
In previous versions of DB2, when limit key values are changed
• Affected partitions are set to REORP.• These partitions could not be accessed until reorg.
In Version 11, when limit key values are changed
• Data remains available, applications can continue to access the data.• The limit key changes are not materialized until the next REORG & apps keep on working...• The affected partitions are placed in (AREOR) status.• Range-partitioned UTS and table spaces partitioned with table-controlled partitioning.• ALTER LIMIT KEY on index controlled partitioned table spaces would set them in REORP.• The limit key values for affected partitions are recorded in the SYSIBM.SYSPENDINGDDL
#IDUG
ALTER Partition Key Limits Online
ALTER LIMIT KEY IN DB2 11 – How does it work
• Alter limit key is a pending alter in NFM.• The affected partitions are set to AREOR.• Online REORG (REFERENCE or CHANGE) must be run to materialize the pending changes.• REORG SHRLEVEL NONE does not materialize the changes.• UTS or table controlled partitioning is a prerequisite for this feature.• The new limit keys are materialized in SYSTABLEPART in the SWITCH phase (new message
DSNU2916I)• If the table space is in a MQT relation, it is still possible to alter limit key online.• RECOVER PIT is allowed, requires a subsequent REORG due to setting of REORP after the recovery.
This is possible but needs attention because it is restrictive!...
ALTER TABLE <limit key> ; What if DBA channges the idea!...ALTER TABLESPACE .... DROP PENDING CHANGES / REORG ... REBALANCE ---
APAR PM89655 addsPREVENT_ALTERTB_LIMITKEYPREVENT_NEW_IXCTRL_PART
#IDUG
Select from Directory
Historically, those tables were not accessible through SQL (SELECT ONLY)
V10 : SYSIBM.SYSLGRNX, SYSIBM.SYSUTIL, SYSIBM.SYSUTILX, SYSIBM.DBDR, SYSIBM.SPTRV11 : SYSIBM.SCTR
• SYSIBM.DBDR: one row for each DBD section.• SYSIBM.SCTR: Skeleton Cursor Tables (SKCT) information• SYSIBM.SPTR: Skeleton Package Table (SKPT) information• SYSIBM.SYSLGRNX: recovery log ranges that record the time an indexspace defined with
COPY YES or a table space was open for updates.• SYSIBM.SYSUTIL: status information about DB2 utilities that are active or stopped.
#IDUG
Select from Directory
• Some of the data in those tables are still internal• Combining them to existing catalog tables, provides more information.
---------+---------+---------+---------+------SELECT NAME,COUNT(*) AS NUMBER_OF_SECTIONSFROM SYSIBM.DBDR A, SYSIBM.SYSDATABASE BWHERE A.DBID = B.DBIDGROUP BY NAMEORDER BY NUMBER_OF_SECTIONS DESC;---------+---------+---------+---------+------NAME NUMBER_OF_SECTIONS---------+---------+---------+---------+------DSNDB06 12DGOLD107 8DANLDBU 4SEMTPDB1 2DSNOPTDB 2DSNRGFDB 1MGBTEST 1MGBMAP 1
#IDUG
Drop Column (R)evolution
• Add column implemented in the very early versions. (V1)• Altering Column data type, renaming column name came up with V8 & V9.• Now we have Drop Column functionality in V11
WHY DO YOU NEED TO DROP COLUMN?
• Columns become obsolete as applications change.• Leaving a column has cost, Space in the table and in every Image Copy.• Potential space in the log records• Additional CPU, elapsed time costs accessing and maintaining the data.• DBA must spend time to remember that the column is redundant/obsolete• Developer must analyze the usage of the column.
#IDUG
Drop Column
HOW DO YOU DROP A COLUMN BEFORE V11
Very preliminary procedure to do that task, which is very sensitive and open tohuman errors.
• Schedule an outage• Unload Data• Drop Table• Alter DDL• Create Table• Load Data• Grant Authorities and Bind/Rebind Packages
#IDUG
Drop Column UNDO Drop Column?
- After Materializition, NO!- Before Materilaztion, YES
ALTER TABLESPACE DROPPENDING CHANGES
Such as:• The containing table space is NOT a Universal Table Space• The table is a GTT, a system-period temporal table, a history table, MQT,...• There are row permissions or column masks dependent on the table• There are triggers defined on the table• Column is part of index key
#IDUG
Auto Mapping Tables
Current Issues- Each Reorg Uses its own mapping table, can not be shared by other concurrent.- Manual operation (During REORG and/or DB2 Migration)- Scalibility Constraint (64 GB)
Automated Mapping Tables : in a PBG tablespace and mapping index maximumsize will be increased from 64GB to 16TB.
#IDUG
Auto Mapping Tables
Reorg Decision Process:
1. If mapping table specified & correct format then honour specification2. Else if specified but incorrect format then create new in same DB as original2.1 MAPPINGDATABASE overrides ZPARM / implicit database if specified3. Else if not specified and ZPARM REORG_MAPPING_DATABASE specified then
create in ZPARM DB4. Else create in implicit DB5. DROP at end of REORG or end of last REORG if multiple REORGs in job step
- No additional auth requirements necessary for creation of mapping tables
#IDUG
Auto Mapping Tables
REORG TABLESPACE GOLD123.TS1SHRLEVEL CHANGECOPYDDN(SCOPY)MAXRO 240 LONGLOG CONTINUE DRAIN ALL DELAY 900STATISTICS TABLE INDEXPREFORMATFASTSWITCH YES
DSNU2902I -GTBG 170 06:19:36.77 DSNURMAP - MAPPING DATABASE REORGMD ISINVALID
MAPPINGDATABASE keyword or REORG_MAPPING_DATABASE subsystem parameterdoes not exist or cannot be used to implicitly create a mapping table.
#IDUG
Transparent Archiving
• DB2 11 Transparent Archiving is built on the (bi) temporal support.• Not a complete Archive Solution!• 3 pieces : a table, the archive table and associate• What DB2 does : Move data from table to archive table & decides access between
tables• Global Variables
SYSIBMADM.MOVE_TO_ARCHIVE ( Y/ N / E )Y : delete of a row in an archive-enabled table will result in storing a copy of therow in the associated archive table.SYSIBMADM.GET_ARCHIVE ( Y/ N )Y : when a table-reference is an archive-enabled table, the table referenceincludes rows in the associated archive table.
• ARCHIVESENSITIVE(YES) Bind optiondetermines whether references to archive-enabled tables are affected by thevalue of the SYSIBMADM.GET_ARCHIVE global variable.
#IDUG
Transparent Archiving
Setup:CREATE TABLE T1(C1 SMALLINT, C2 INTEGER) ;CREATE TABLE T1_ARC LIKE T1;ALTER TABLE T1 ENABLE ARCHIVE USE T1_ARC;
SELECT * FROM T1;---------+---------+------
C1 C2---------+---------+------
1 1115 222
SET SYSIBMADM.MOVE_TO_ARCHIVE = 'Y';DELETE FROM T1 WHERE C1=1;
SELECT * FROM T1;SELECT * FROM T1_ARC;
SELECT * FROM T1;---------+---------+------
C1 C2---------+---------+------
5 222
SELECT * FROM T1_ARC;---------+---------+--------
C1 C2---------+---------+--------
1 111
SET SYSIBMADM.GET_ARCHIVE = 'Y';SELECT * FROM T1 ;SELECT * FROM T1_ARC;
SELECT * FROM T1;---------+---------+------
C1 C2---------+---------+------
1 1115 222
SELECT * FROM T1_ARC;---------+---------+--------
C1 C2---------+---------+--------
1 111
#IDUG
Transparent Archiving
ALTER TABLE T1 ADD COLUMN NEW_COL SMALLINT;-- NEW_COL is added to T1_ARC as well...
The INSERT, UPDATE, and MERGE statements to archive enable table are- all blocked in archive mode if SYSIBMADM.MOVE_TO_ARCHIVE = ‘Y’- not blocked and business as usual if SYSIBMADM.MOVE_TO_ARCHIVE = ‘N’
How to disable ARCHIVEing?
ALTER TABLE ... DISABLE ARCHIVE- the packages and statements in DSC that reference archive table are invalidated.- Cannot be disabled if there are any views, MQTs, or inline SQL table functions
that reference the table.
#IDUG
Runstats Enhancements
Runstats is generally good for Access Paths.It was costly before V10 for Distributed StatsV10 Distribution Stats are zIIP Eligable - %99 with no additional parametersV11 Inline Stats are zIIP Eligable - %30
Inline Stats even become more powerful:- Part Level Reorg can collect NPI Stats (SORTNPSI YES|AUTO) (based on internal threashold)- Collect COLGROUP and HISTOGRAM information
#IDUG
Runstats Enhancements
- RESET ACCESSPATH does NOT reset the statistics currently in the _HIST tables for that object- HISTORY ACCESSPATH option, provides the possibility to write out to the _HIST tables(SYSIBM.SYSTABLES_HIST for tables, SYSIBM.SYSINDEXES_HIST for indexes)
reset the existing statistics during a RUNSTATS utilityRUNSTATS TABLESPACE ... RESET ACCESSPATHAccess Path Stats are resetRTS & Space Stats are NOT reset
SYSTABLESPACE / NACTIVE / -1SYSCOLUMNS / COLCARDF / -1SYSINDEXES / CLUSTERRATIO / 0
#IDUG
Recovery Support for Deferred schema changes
- Deferred schema change / Online Schema Change allows to make schema changes at any time -- Defer the materialization of those changes until a REORG -
- V10 included a significant restriction relating to PIT recoveries. -- Once the REORG had been run, it was not possible to perform a PIT recovery -- V11 NFM removes this restriction, allowing PIT recovery -Such asALTER DSSIZEALTER PAGESIZEALTER SEGSIZEALTER MEMBER CLUSTER
With restrictions... -- It's in REORG Pending mode so no SQL until the Reorg happens- The only utilities that are allowed REORG, RECOVER, REPORT RECOVERY, REPAIR DBD
#IDUG
Recovery Support for Deferred schema changes
CREATE TABLE T1 (C1 SMALLINT) IN GOLD123.TS1;INSERT INTO T1 VALUES (4);INSERT INTO T1 VALUES (6);
ALTER TABLE T1 ADD COLUMN C2 INTEGER ;INSERT INTO T1 VALUES (4,7);INSERT INTO T1 VALUES (6,7);
RECOVER TO FIC
C1------
46
C1 C2-----+---------4 ---------6 ---------4 76 7
C1 C2-----+---------4 ---------6 ---------
FIC of T1
RECOVER TO FIC
#IDUG
Pseudo deleted index key cleanup
Definition- When a data row is deleted, the index entry for the key to that row must be removed.- DB2 sets a bit in the index to mark the index entry as being pseudo-deleted- Pseudo-deleted entries occupy space. The more you have, The more SQL performance gets weaker.- Pseudo-empty index pages = pages that contain only pseudo-deleted index entries.
Issues- Performance Impact for maintaining for entries- More getpages- Concurrency issues for INSERT, UPDATE and DELETE- RID reuse by an INSERT statement following a DELETE statement could cause a deadlock.
Before V11 : REORG, REORG, REORG!...
#IDUG
Pseudo deleted index key cleanup
• DB2 autonomically deletes pseudo-empty index pages and pseudo deleted index entries byscheduling asynchronous service tasks.
• committed pseudo-deleted index entries!• Service task overhead is not associated with any DELETE or UPDATE activity and have low CPU
overhead.• zIIP Eligible• by Default in V11 CM• Performed only on the indexes that have been opened for INSERT/DELETE/UPDATE• There can be large number of pseudo deleted entries, but if index is not opened for
INSERT/DELETE/UPDATE, the cleanup does not happen.• The cleanup rate dependsthe rate that the pseudo deleted entries are generated,the number of threads allowed to run cleanup concurrentlythe commit frequency of the unit of work which generates the pseudo deleted index entries.
Control Options- INDEX_CLEANUP_THREADS subsystem parameter- SYSIBM.SYSINDEXCLEANUP catalog table
#IDUG
Pseudo deleted index key cleanup
INDEX_CLEANUP_THREADS subsystem parameter- #threads for the cleanup of pseudo deleted index entries.- Between 0-128 & default 10- 0 disables clean up process- Checks RTS table (SYSIBM.SYSINDEXSPACESTATS(REORGPSEUDODELETES))- Reduces the need for REORG INDEX
SYSIBM.SYSINDEXCLEANUP catalog table is checked 10 min intervals- Process is enabled for ALL Indexes by default- Specify time window for the process- The catalog table includes
1- Name of databases and indexspace2- Cleanup enabled or disabled3- Day of week or day of month4- Start time and end time
#IDUG
LOAD SHRLEVEL CHANGE with PARALLEL option
- LOAD SHRLEVEL CHANGE option higher CPU than SHRLEVEL NONE- SHRLEVEL CHANGE stores the rows in cluster sequence (INSERTs...)- Performance is crucial to space search algorithms & contention between parallel inserts.- If the TS has enough free space, less time for searching for space and less contention.- Parallelism provides more value for SHRLEVEL CHANGE- Parallelism may significantly reduce the ET- If there is contention, more significant increase in the CPU time and more CPU increase
LOAD DATA INDDN SYSREC RESUME YES PARALLEL SHRLEVEL CHANGEDSNURPLL - TABLE SPACE WILL BE LOADED IN PARALLEL, NUMBER OF TASKS = XXX
#IDUG
New zParms in V11
LIKE_BLANK_INSIGNIFICANT = YES / NO- all of the blanks at the end of a fixed-length string are ignored, DB2 strips trailing blanks from the
data before performing the comparison.- Needs rebind/prepare
SELECT c1 FROM T WHERE <Filter>
C1 LIKE ’%123’; predicate will matchthe following fixed-length strings
xyz123xyz123bxyz123bb
C1 LIKE ’%123 ’; predicate will NOT matchthe following fixed-length strings
xyz123xyz123bxyz123bb
#IDUG
New zParms in V11
PCTFREE_UPD
The cost of overflow records is noticeable when DB2 builds a RID list for usewith list prefetch because DB2 never overtly prefetches an overflow record.AUTO: DB2 uses RTS to calculate
- default free space to reserve on each page for UPDATE operations- no effect on table spaces that have fixed length rows
CREATE/ALTER TABLESPACE PCTFREE x FOR UPDATE y
x = % of free space to leave in each data page by LOAD or REORGy = % of free space to leave in each data page by INSERT, LOAD, or REORG
Top Related