idug na 2014 / 11 tips for db2 11 for z/os

#IDUG#IDUG

11 Tips for DB2 11 for z/OS

Cüneyt GöksuIBMSession Code: E04Tue, May 13, 2014 (04:30 PM - 05:30 PM)| 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

Deprecated stuff...

Highlights of my favorite V11 enhancements

#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 DB2special 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 OnlineREORG 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


Historically, those tables were not accessible through SQL (SELECT ONLY)

V10 added SYSIBM.SYSLGRNX, SYSIBM.SYSUTIL, SYSIBM.SYSUTILX, SYSIBM.DBDR, SYSIBM.SPTRV11 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.

#IDUG


• 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)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.

#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 humanerrors.

• Schedule an outage• Unload Data• Drop Table• Alter DDL• Create Table• Load Data• Grant Authorities and Bind/Rebind Packages

#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 DROPPENDING CHANGES

#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 sizewill 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


- 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 theassociated archive table.SYSIBMADM.GET_ARCHIVE ( Y/ N )Y : when a table-reference is an archive-enabled table, the table reference includes rows inthe associated archive table.

- ARCHIVESENSITIVE(YES) Bind optiondetermines whether references to archive-enabled tables are affected by the value of theSYSIBMADM.GET_ARCHIVE global variable.

#IDUG

Transparent ArchivingSetup: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


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.

#IDUG


Runstats is generally good for Access Paths.It was costly before V10 for Distributes 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


- 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 ACCESSPATHAccess Path Stats are resetRTS & Space Stats are NOT reset

SYSTABLESPACE / NACTIVE / -1SYSCOLUMNS / COLCARDF / -1SYSINDEXES / CLUSTERRATIO / 0

#IDUG


- 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... -- 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

#IDUG


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------

46

C1 C2-----+---------4 ---------6 ---------4 76 7

C1 C2-----+---------4 ---------6 ---------

#IDUG

Pseudo deleted index key cleanupDefinition- 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 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 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

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

zParmPRIVATE_PROTOCOLSysplex query parallelism Turns into CPU ParallelismNEWFUN(YES / NO)NEWFUN(11 / 10)

#IDUG#IDUG

11 Tips for DB2 11 for z/[email protected]

Session: E04Please fill out your sessionevaluation before leaving!

idug na 2014 / 11 tips for db2 11 for z/os

Data & Analytics