DB2 11 includes several new features such as global variables, the ability to alter partition keys online without impacting availability, selecting data from directory tables, dropping columns, auto-mapping of tables during reorganization, transparent archiving of data, enhancements to RUNSTATS utilities, and deprecated functionality. Some highlights include global variables that can be shared across SQL statements, altering partition limits online which sets partitions to AREOR status until reorganization, and dropping columns in tables without taking them offline.

1. #IDUG#IDUG
11 Tips for DB2 11 for z/OS
Cüneyt Göksu
IBM
Session Code: E04
Tue, May 13, 2014 (04:30 PM - 05:30 PM)| Platform: DB2 for z/OS

2. #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
 Deprecated stuff...
Highlights of my favorite V11 enhancements

3. #IDUG
Global Variables
• Long expected DB2 for z/OS feature
- Enable the sharing of data between SQL statements without 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.

4. #IDUG
Global Variables

5. #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 without
impacting 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

6. #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 adds
PREVENT_ALTERTB_LIMITKEY
PREVENT_NEW_IXCTRL_PART

7. #IDUG
Select from Directory
Historically, those tables were not accessible through SQL (SELECT ONLY)
V10 added SYSIBM.SYSLGRNX, SYSIBM.SYSUTIL, SYSIBM.SYSUTILX, SYSIBM.DBDR, SYSIBM.SPTR
V11 added SYSIBM.SCTR table to the list.
• 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.

8. #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_SECTIONS
FROM SYSIBM.DBDR A, SYSIBM.SYSDATABASE B
WHERE A.DBID = B.DBID
GROUP BY NAME
ORDER BY NUMBER_OF_SECTIONS DESC;
---------+---------+---------+---------+------
NAME NUMBER_OF_SECTIONS
---------+---------+---------+---------+------
DSNDB06 12
DGOLD107 8
DANLDBU 4
SEMTPDB1 2
DSNOPTDB 2
DSNRGFDB 1
MGBTEST 1
MGBMAP 1

9. #IDUG
Drop Column (R)evalution
• 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.

10. #IDUG
Drop Column
HOW DO YOU DROP A COLUMN BEFORE V11
Very preliminary procedure to do that task, which is very sensitive and open to human
errors.
• Schedule an outage
• Unload Data
• Drop Table
• Alter DDL
• Create Table
• Load Data
• Grant Authorities and Bind/Rebind Packages

11. #IDUG
Drop Column
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
UNDO Drop Column?
- After Materializition, NO!
- Before Materilaztion, YES
ALTER TABLESPACE DROP
PENDING CHANGES

12. #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)
- Scailibility Constraint (64 GB)
Automated Mapping Tables : in a PBG tablespace and mapping index maximum size
will be increased from 64GB to 16TB.

13. #IDUG
Auto Mapping Tables
Reorg Decision Process:
1. If mapping table specified & correct format then honour specification
2. Else if specified but incorrect format then create new in same DB as original
2.1 MAPPINGDATABASE overrides ZPARM / implicit database if specified
3. Else if not specified and ZPARM REORG_MAPPING_DATABASE specified then create
in ZPARM DB
4. Else create in implicit DB
5. 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

14. #IDUG
Auto Mapping Tables
REORG TABLESPACE GOLD123.TS1
SHRLEVEL CHANGE
COPYDDN(SCOPY)
MAXRO 240 LONGLOG CONTINUE DRAIN ALL DELAY 900
STATISTICS TABLE INDEX
PREFORMAT
FASTSWITCH YES
DSNU2902I -GTBG 170 06:19:36.77 DSNURMAP - MAPPING DATABASE REORGMD IS
INVALID
MAPPINGDATABASE keyword or REORG_MAPPING_DATABASE subsystem parameter
does not exist or cannot be used to implicitly create a mapping table.

15. #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 the row in the
associated archive table.
SYSIBMADM.GET_ARCHIVE ( Y/ N )
Y : when a table-reference is an archive-enabled table, the table reference includes rows in
the associated archive table.
- ARCHIVESENSITIVE(YES) Bind option
determines whether references to archive-enabled tables are affected by the value of the
SYSIBMADM.GET_ARCHIVE global variable.

16. #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 111
5 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 111
5 222
SELECT * FROM T1_ARC;
---------+---------+--------
C1 C2
---------+---------+--------
1 111

17. #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’
- not blocked and archive works as usual if SYSIBMADM.MOVE_TO_ARCHIVE = ‘E’
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.

18. #IDUG
Runstats Enhancements
Runstats is generally good for Access Paths.
It was costly before V10 for Distributes Stats
V10  Distribution Stats are zIIP Eligable - %99 with no additional parameters
V11  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

19. #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 utility
RUNSTATS TABLESPACE ... RESET ACCESSPATH
Access Path Stats are reset
RTS & Space Stats are NOT reset
SYSTABLESPACE / NACTIVE / -1
SYSCOLUMNS / COLCARDF / -1
SYSINDEXES / CLUSTERRATIO / 0

20. #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 as
ALTER DSSIZE
ALTER PAGESIZE
ALTER SEGSIZE
ALTER MEMBER CLUSTER
With restrictions... -  
- No CREATE, ALTER, RENAME, and DROP TABLE statements on the tablespace w/o subsequent REORG
- The only utilities that are allowed REORG, RECOVER, REPORT RECOVERY, REPAIR DBD

21. #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);
FIC of T1
ALTER TABLE T1 ADD COLUMN C2 INTEGER ;
INSERT INTO T1 VALUES (4,7);
INSERT INTO T1 VALUES (6,7);
RECOVER TO FIC
C1
------
4
6
C1 C2
-----+---------
4 ---------
6 ---------
4 7
6 7
C1 C2
-----+---------
4 ---------
6 ---------

22. #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!...

23. #IDUG
Pseudo deleted index key cleanup
- DB2 autonomically deletes pseudo-empty index pages and pseudo deleted index entries by scheduling
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 depends
the rate that the pseudo deleted entries are generated,
the number of threads allowed to run cleanup concurrently
the 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

24. #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 indexspace
2- Cleanup enabled or disabled
3- Day of week or day of month
4- Start time and end time

25. #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 CHANGE
DSNURPLL - TABLE SPACE WILL BE LOADED IN PARALLEL, NUMBER OF TASKS = XXX

26. #IDUG
Some Deprecated things in V11
Utility
- REORG SHRLEVEL NONE for LOBs  RC8
- REORG TABLESPACE UNLOAD ONLY  Use UNLOAD
- COPY CHANGELIMIT  Use DSNACCOX to determine if it needs to be copied
zParm
PRIVATE_PROTOCOL
Sysplex query parallelism  Turns into CPU Parallelism
NEWFUN(YES / NO) NEWFUN(11 / 10)

27. #IDUG#IDUG
11 Tips for DB2 11 for z/OS
IBM
CuneytG@tr.ibm.com
Session: E04
Please fill out your session
evaluation before leaving!