Tuesday, April 30, 2013

How to EXPLAIN your SQL query

Hi,

Here is the code for EXPLAIN. This will help you in your analysis of performance regarding SQL you are going to run.

Consideration:
1) You should have all the objects (Referenced in your SQL) created in the same env where you will Explain the SQL.
2) You tables must be runstated before running Explain
3) You can replace host variables with any Char/Int Literals in the SQL statements.
4) Make sure your PLAN_TABLE and DSN_STATEMNT_TABLE present in the same Env.Here is one example of SQL code regarding How to Explain your query.
DELETE FROM PLAN_TABLE WHERE QUERYNO = 99999;
COMMIT;

EXPLAIN PLAN SET QUERYNO = 99999 FOR

SELECT B.STORE_NO, B.STOCK_ITEM, B.DELIVERY_DATE
FROM V1FOGH01 B

WHERE DELIVERY_DATE = (SELECT MAX(DELIVERY_DATE)
FROM V1FOGH01 A
WHERE A.STORE_NO = B.STORE_NO
AND A.STOCK_ITEM = B.STOCK_ITEM
AND A.QTY_TYPE ='7'
AND A.DELIVERY_DATE <= CURRENT DATE)
AND B.QTY_TYPE ='7';

SELECT * FROM PLAN_TABLE
WHERE QUERYNO = 99999
ORDER BY TIMESTAMP,QUERYNO,QBLOCKNO,PLANNO,MIXOPSEQ;

SELECT * FROM DSN_STATEMNT_TABLE
WHERE QUERYNO = 99999;
========

followup...

How to display the key corresponding to RID Value

Hi,

When you run CHECK DATA utility to verify the violating the RI constraints, you may come across the following error message:

DSNUKERK - ROW (RID=X'0000000202') HAS NO PARENT FOR TSG10.TES3.CTES3A

Here the hexadecimal value X'0000000202' is the Row Identifier of the key of the child table which violates the RI constraint CTES3A.

If someone tell you to find out the record corresponding key to the RID value, then you can follow this approach.

There is one stand alone utility DSN1PRNT by the help of which you can print the VSAM file data.

RID value is always associated with the index of the table.

Hence by searching the RID value in underlying index dataset( for example DSN2.DSNDBD.DTSG10.X1TES300.I0001.A001)  of violating child table, we can get hold of the key.

Here is the sample JCL: Note: always search hexadecimal value in two double quotes.


//TSG10P JOB ,
// CLASS=L,MSGCLASS=O,NOTIFY=TSG10,MSGLEVEL=(1,1)
//****************************************************************
//*
//* JCL TO PRINT HEXADECIMAL DUMP OF DB2 IMAGE COPY
//*
//****************************************************************
//*
//STEP1    EXEC PGM=DSN1PRNT,
//         PARM='FORMAT,VALUE(''0000000202'')'
//SYSUT1   DD DSN=DSN2.DSNDBD.DTSG10.X1TES300.I0001.A001,DISP=SHR
//SYSPRINT DD SYSOUT=*
//*

The subset of the output looks like below:
===
UNIQUE KEYS FOLLOW:
KEY ENTRY:  IPKMAP(XI)='0038'X
KEY:
8001
RID:
0000000201
KEY ENTRY:  IPKMAP(XI)='003F'X
KEY:
8002
RID:
4000000202
KEY ENTRY:  IPKMAP(XI)='0046'X
KEY:
8005
RID:
4000000203

DSN1994I DSN1PRNT COMPLETED SUCCESSFULLY,  00000005 PAGES PROCESSED

Note:

1) To find out the violating rows you can create the exception table and track those and at the same time you can bring the table to RW mode from Check pending status.

2) Or you can use the REPAIR utility for DUMP/DELETE the violating rows By LOCATE TABLESPACE command.

So do not be afraid of seeing the RID hex values, just play with it by the available utilities..
.......


followup...

Repair

Know the power of REPAIR utility in DB2

Hello readers...

Now I am going to explain how you can utilize REPAIR utility.

Everybody know REPAIR utility is popularly used for resetting the pending states of Index and Tablespaces.



Example 1:
Everybody know REPAIR utility is popularly used for resetting the pending states of Index and Tablespaces.

//STEP3    EXEC DSNUPROC,UID='SSTRR',                            
//            UTPROC='',SYSTEM='DSN2'                                      
//SYSIN    DD *                                                            
  REPAIR OBJECT                                                            
  SET INDEX (ALL) TABLESPACE DTSG10.SSTRR NORBDPEND                  
  SET TABLESPACE DBTEST1.STEST PART 1 NOAUXCHKP                        
  SET TABLESPACE DBTEST1.STEST PART 4 NOCHECKPEND
/*

Example 2:
Suppose you want to delete a row corresponding to a ROWID mentioned in the referential violation constraint.


REPAIR
  LOCATE TABLESPACE DTSG10.TS1 RID (X'0000000503')
    DELETE




Example 3:
Replacing damaged data and verifying replacement.

* Repair the specified page of table space DTSG10.STEST1, as indicated by the LOCATE clause.
* Verify that, at the specified offset (50), the damaged data (0A00) is found, as indicated by the VERIFY clause.
* Replace the damaged data with the desired data (0D11), as indicated by the REPLACE clause.
* Initiate a dump beginning at offset 50, for 4 bytes, as indicated by the DUMP clause. You can use the generated dump to verify the replacement.

//STEP1    EXEC  DSNUPROC,UID='IUIQU1UH',UTPROC='',SYSTEM='DSN'
//SYSIN DD *
REPAIR OBJECT
  LOCATE TABLESPACE DSN8D81A.DSN8S81D PAGE X'02'
    VERIFY OFFSET 50 DATA X'0A00'
    REPLACE OFFSET 50 DATA X'0D11'
    DUMP OFFSET 50 LENGTH 4

Example 4:
Reporting whether catalog and directory DBDs differ. The following control statement specifies that REPAIR is to compare the DBD for DTSG10 in the catalog with the DBD for DTSG10 in the directory.

REPAIR DBD TEST DATABASE DTSG10


Example 5:
Reporting differences between catalog and directory DBDs. The following control statement specifies that the REPAIR utility is to report information about the inconsistencies between the catalog and directory DBDs for DTSG10. Run this job after you run a REPAIR job with the TEST option (as shown in example 4), and the condition code is not 0. In this example, SYSREC is the output data set, as indicated by the OUTDDN option.

REPAIR DBD DIAGNOSE DATABASE DSN8D2AP OUTDDN SYSREC

Example 6:
Repairing a table space with an orphan row. After running DSN1CHKR on table space SYSDBASE, assume that you receive the following message:

DSN1812I ORPHAN ID = 20 ID ENTRY = 0190 FOUND IN
         PAGE = 0000000024

From a DSN1PRNT of page X'0000000024' and X'0000002541', you identify that RID X'0000002420' has a forward pointer of X'0000002521'.

Repair the table space by taking the following actions:

1. Submit the following control statement, which specifies that REPAIR is to set the orphan's backward pointer to zeros:

      REPAIR OBJECT LOG YES
       LOCATE TABLESPACE DSNDB06.SYSDBASE RID X'0000002420'
        VERIFY OFFSET X'0A' DATA X'0000002422'
        REPLACE OFFSET X'0A' DATA X'0000000000'

Setting the pointer to zeros prevents the next step from updating link pointers while deleting the orphan. Updating the link pointers can cause DB2 to abnormally terminate if the orphan's pointers are incorrect.

2. Submit the following control statement, which deletes the orphan:

      REPAIR OBJECT LOG YES
       LOCATE TABLESPACE DSNDB06.SYSDBASE RID X'00002420'
        VERIFY OFFSET X'06' DATA X'00002521'
        DELETE


Example 7:
Updating version information. The control statement specifies that REPAIR is to update the version information in the catalog and directory for table spaces STEST1, STEST2, and STEST3.

REPAIR VERSIONS example control statement

//STEP1    EXEC DSNUPROC,UID='JUKQU3AS.REPAIR',TIME=1440,        
//         UTPROC='',                                            
//         SYSTEM='SSTR',DB2LEV=DB2A                             
//SYSIN    DD *                                                       
 REPAIR VERSIONS TABLESPACE DTSG10.STEST1                   
  REPAIR VERSIONS TABLESPACE DTSG10.STEST1 2                   
  REPAIR VERSIONS TABLESPACE DTSG10.STEST1 3  

So arm the knowledge of REPAIR Utility and set for the adventure.
........

followup .. 

Restrict users to create implicit databases like DSN00001 ...

Problem Definition: Application developer can create their own tables taking away controls from DBA.

Explanation: Recently while analyzing the Catalog table space we found many tables and databases created by application developers for their testing purpose. They are sitting on the space pool that the DB2 catalog is using. This is a wired situation from a DBA point of View.

We will discuss how to prevent application users to create a table/database in DB2 environment.

How it is possible: In DB2 V9, IBM introduced a new feature of implicit Database creation. It means if you try to create a table in DB2 without mentioning table space and database, DB2 will take care of that by implicitly creating them.

On a CREATE TABLE statement, if you do not specify a database name, DB2 will use an existing implicitly created database. If an implicitly created database does not exist, DB2 creates one using the naming convention of DSNxxxxx. The DSNxxxxx values can range from DSN00001 to DSNnnnnn, where nnnnn is the maximum value of the sequence SYSIBM.DSNSEQ_IMPLICITDB, with a default of 10000.

To remind you that in Pre-V9, the database is default to DSNDB04 while creating the new table.

Just imagine one Database of each table. It's really difficult task for DBA to relate the objects logically and maintain them. More over they will take the space from the storage group where DB2 catalog resides.

IBM has taken this steps for future to simplify the object creation without providing table space and database name which are not familiar to users other than DBAs. it may be beneficial for certain tools or SAP environment where lots tables to be created while setting up the environment.

Resolutions:
How to prevent the users to create the implicit databases:

Revoke the Create object privilege on database DSNDB04 from PUBLIC. You can't restrict SYSADM users in this case.
or
Restrict the cataloging of high level qualifier containing DSNxxxxx to register the dataset in VTOC
or
Alter the default maximum value of the sequence SYSIBM.DSNSEQ_IMPLICITDB to 1
.........

followup ..

How to bring down DB2 forcefully

At times there are some held threads which prevents DB2 subsystem down for maintenance purpose. We can follow these if we require:

These are some console commands which can be tried:

/MODIFY DSN1IRLM,ABEND,NODUMP

OR
/F DSN1IRLM,ABEND


THEN IF NECESSARY

/C DBM1

/FORCE DBM1 (LAST RESORT)

OR

/C MSTR

/FORCE MSTR (LAST RESORT)




followup...

Friday, April 19, 2013

WLM stored procedure

Know More about WLM Stored Procedure

1) HOW TO KNOW THAT WLM IS AVAILABLE OR NOT?
IN S OF SPOOL COMMAND:

/D WLM,APPLENV=DSN1PRCH

OR

/%WLMDISP DSN1PRCH - IF YOU EXECUTE THIS COMMAND, THEN LOOK AT ULOG.


2) HOW TO RECOVER IF IT IS IN DIFF STATE OTHER THAN AVAILABLE STATE
WE CAN RECOVER THE DSN1PRCH STARTED TASK BY EXECUTING:

/%WLMRECOV DSN1PRCH

OR

IF WE NEED TO REFRESH THE WLM ENV: THIS COMMAND NEED TO BE EXECUTED

CONNECT TO DSN1 USER TSGDBP1 THEN SOR TERMINAL.


CALL SYSPROC.WLM_REFRESH('DSN1PRCH','DSN1',?,?)


TO DISPLAY THE STATUS OF THE PROCEDURE YOU CAN ISSUE A DB2:-

-DIS PROCEDURE(DB2CONN.ABG529P)


Simillarly You can stop and start the Stored Procedure by

-STA PROCEDURE(DB2CONN.ABG529P)

-STOP PROCEDURE(DB2CONN.ABG529P.


followup...

Access the commands of DB2 from command line prompt

Do you know, we can access the commands of DB2 from command line prompt.

Just type following command on command line of Mainframe:

TSO DSN S(subsystem_Name) then press enter.

After that you will a DSN prompt at page below.
You can type commands like:
-DIS THREAD(*)

and when you want to exit just type END ..

followup...

Creating New Index on BIG Table

Hi,

Task: You are asked to create an Index in an existing table which is very huge.

Problem: You might face this issue. When you fired this SQL through batch spufi, it will run for minutes and at last it will abend with -904 return code saying 4K page is not available.
Investigation: You will find many messages in DSN?MSTR and DSN?DBM1 whcih says the temporary tablespace DSNDB07. unable to extend itself as it might reached it's limit of 2GB.

Solution: There are some fact you must know while creating index in a big table.
When you are creating the index, by default it will try to build the index instantly. CREATE INDEX statement uses RDS Sort to sort the keys. RDS Sort is very efficient for smaller tables. But when there is a huge table you must defer the creation of index by specifying DEFER YES in CREATE INDEX statement so that index for the table is registered in the DB2 catalog but the new index is in Rebuild pending status giving warning while creation of index.
REBUILD INDEX uses the the EXTERNAL SORT which outperforms the RDS Sort if the table size is significant. Even the performance of REBUILD INDEX is improved with parallel partition key extract and parallel index build.

By deferring the index creation and rebuilding the index, your index creation is over in few minutes and you will not get any extend failure message in MSTR started task.


followup...

To know the z/OS version and last IPL info

As a DBA, sometimes we need to check the oprating system version for compatability of some of the DB2 related software while installation and upgrade.

To find this there is spool/console command:

/D IPLINFO
The output is like below:

RESPONSE=MVS1
IEE254I 05.39.50 IPLINFO DISPLAY 651

SYSTEM IPLED AT 18.36.54 ON 10/25/2008
RELEASE z/OS 01.07.00 LICENSE = z/OS
USED LOAD00 IN SYS1.IPLPARM ON 8326
ARCHLVL = 2 MTLSHARE = N
IEASYM LIST = 00
IEASYS LIST = 00
IODF DEVICE 8326


followup...

How to Revoke SYSADM previlege without cascading effect

Installation system admin have given SYSADM authority to a userid (USR10). Through that userid, the user created many objects, had bind many packages and given many privileges.
Now when
Installation system admin tried to revoke the SYSADM auth from that user, the mainframe screen seems to be hanged and locked for hours. Even the subsystem might be crashed.

How to Approach this problem..
We made the Userid(USR10) as Installation SYSADM id through one job which make the change in Z-Parm of DB2 subsystem.
Here is the member:
D710.DSN4.SDSNSAMP(DSNTIJUZ) -- second qualifier is the subsystem name.
and parameters are
SYSADM=USR10, -- put userid over here from which you want to revoke the SYSADM auth.
SYSADM2=USR10,

you need to stop/start the subsystem to make it effect. After that Shoot the REVOKE statement. This will be executed in a second. After this do not forgot to change the SYSADM to it's initial value.

Catch is When you revoke SYSADM from a installation sysadm, you won't have cascading effect.



followup...

How to read PLAN_TABLE after EXPLAIN

Hi,

Here are some information you should be looking at various columns of the PLAN_TABLE. This will help you analysing the SQL queries and it's various attributes.

1) QUERYNO: A number identifying the statement being explained.

2) METHOD:
0 - First table accessed, continuation of previous table accessed or not used
1 - Nested Loop Join
2 - Merge Scan Join
3 - Sorts required by ORDER BY, GROUP BY, SELECT DISTINCT, uNION
4 - Hybrid Join

3) ACCESSTYPE:
I - By an Index
I1 - One fetch Index Scan
M - Multiple index scan
MX - By Index mentioned in ACCESSNAME
MI - Intersection of Multiple indexes
MU - Union of multiple indexes
N - Index scan when matching predicated in IN keyword
R - Tablespace scan
RW - Work file scan of a materialized user defined table funtion
T - By a spare index - Star join work files
V - By buffers for an INSERT statement within a SELECT
Blank - NA

4) INDEXONLY:
Whether access to an Index alone is enough to carry out the step

5) TSLOCKMODE:
IS - Intent Share Lock
IX - Intent Exclusive lock
S - Share Lock
U - Update Lock
X - Exclusive Lock
SIX - Share with Intent Exclusive lock
N - UR Isolation: No Lock
NS - For CS, RS, RR an S Lock
NIS - For CS, RS, RR an IS Lock
NSS - For CS, RS an IS Lock and for RR an S Lock
SS - For UR, CS, RS an IS Lock and for RR an S Lock

6) PREFETCH:
S - Pure Sequential
L - thru a page List
D - Optimizer expects dynamic prefetch
Blank - Unknown at bind time or NA

7)ACCESS_DEGREE:
Number of Parallel tasks or operations activated by a Query
0 - if there is a host variable

8) PARALLELISM_MODE:
I - Query I/O parallelism
C - Query CP parallelism
X - Sysplex query parallelism

9) PAGE_RANGE:
Whether the table qualifies for page-range(scan only the partitions those are needed)
Y - Yes
Blank - No

10) JOIN_TYPE:
F - Full Outer Join
L - Left Outer Join
S - Star Join
Blank - Inner Join or No join
Note: Right Outer Join always converted to Left Outer Join

11) WHEN_OPTIMIZE:
Blank: At bind time, using a default filter factor for any host variables, parameter markers or special registers
B - Above facts + Bind option REOPT (ALWAYS) or REOPT (ONCE) must be specified.
R - At Runtime, using input variables, parameter markers or special registers. Bind option REOPT (ALWAYS) or REOPT (ONCE) must be specified.

12) QBLOCK_TYPE:
SELECT - Select
INSERT - Insert
UPDATE - Update
DELETE - Delete
SELUPD - Select with FOR UPDATE OF
DELCUR - DELETE WHERE CURRENT OF CURSOR
UPDCUR - UPDATE WHERE CURRENT OF CURSOR
CORSUB - Correlated Subquery
NCOSUB - NonCorrelated Subquery
TABLEX - Table Expression
TRIGGER - WHEN caluse on CREATE TRIGGER
UNION - Union
UNIONA - Union All

13) PRIMRY-ACCESSTYPE:
D - Direct Row access
Blank - No Direct Row access

14) TABLE_TYPE:
B - Buffers for an INSERT stament within a SELECT
C - Common Table Expression
F - Table Function
M - Materialized Qery Table
Q - Temp intermediate table(Not Materialized), name of the viewor nested table expression, Contains a UNION ALL where materialization was vertual not actual.
RB - Recursive Common Table Expression
T - Table
W - Work file (Materialized)

15) TABLE_ENCODE:
A - ASCII
E - EBCDIC
U - Unicode
M - when multiple CCSID is in one table.


followup...