db2 data aging

10 October 1998 (c) Copyright 1998 Cogito Ltd . All Rights Reservedhttp://www.tact.com NASDAQ: TACX

DB2 Physical and Logical Aging

2TACT Software, INC.

Objectives

Understand how...– DB2 physical ager ...can be used to create physically

aged DB2 tables for use in “time-travel” application testing

– DB2 logical ager ...can be used to create logically aged DB2 test databases for use in “time-travel” application testing


Overview...

Y2k testing demands that applications be tested in “time-travel” conditions– Requires date simulation functionality to make

current date appear to be future date(s)– EZTEST DATE– Other 3rd party tools


Overview...

Co-requirement of date simulation in “time-travel” environment is meaningful test data– Regression testing - achieve same results only

at different point in time– Generation of test data not trivial without

automatic data aging tools– Physical / logical


Highlights...

Physical Ager– Adjust all applicable dates in DB2 database in step

with required assumed (simulated) run date– Allows highly flexible definition of the

tables/columns to be aged, and the aging criteria– Supports all meaningful DB2 data types (not just

DATE) and supports all possible date formats


Highlights...

Physical ager (cont.)– Data is aged in-place. There is no requirement to

copy DB2 tables to intermediate files– Multiple or single DB2 tables can be aged in single

execution– User specification of table locking option and

COMMIT strategy– Simple to install and run


Highlights...

Logical Ager– Test DB2 applications against aged data without

physically aging database– Database aged virtually, in step with users assumed

(simulated) run-date– Different users may execute with different assumed

run-dates against same database at same time


Highlights...

Logical Ager (Cont.)– No changes to application code or databases– Logical aging by post-processing DBRM– Increased flexibility and productivity– Saves time and physical DASD space


Physical Ager...

– Add consistent date difference to every applicable date column in every row, in applicable DB2 tables

– Definition of date difference to be added and eligible tables/columns specified through user generated tables

– Supports all possible column data types and date formats


Physical Ager...

CTLTAB definition– date difference derived from RUNDATE-BASEDAT

CTLDB2 #CTLTAB ENTRY=FIRST,TYPE=DB2, #CTLTAB ENTRY=DBEZ2000, RUNDATE=20000115, BASEDAT=19970929 #CTLTAB CLASS=JOB,NAME=ASOXGB*

‘‘

#CTLTAB ENTRY=LAST


Physical Ager...

TDETAB definition

DB2KTDE #TDETAB ENTRY=FIRST,SYSTEM=DB2P10,DEFPIC=DATE,DEFDFC=ISODATE

*#TDETAB ENTRY=TABLE,NAME=T0348_KERN_PERS#TDETAB ENTRY=COL,NAME=DAT_GEB

*#TDETAB ENTRY=TABLE,NAME=T1060_TERM_STAT#TDETAB ENTRY=COL,NAME=LOESCH_DATE*#TDETAB ENTRY=TABLE,NAME=T2012_AL_TERM_STAM#TDETAB ENTRY=COL,NAME=DAT_VORLAGE,PIC=CHAR,DFC=AY@M@D#TDETAB ENTRY=COL,NAME=DATE_ERF

*#TDETAB ENTRY=TABLE,NAME=T2014_AL_TERM_MAHN#TDETAB ENTRY=COL,NAME=DAT_MAHN,PIC=DEC.DFC=PCCYYDDD

*#TDETAB ENTRY=LAST


Physical Ager...

TDETAB definition– Define tables/columns which must be aged– Define PIC for column

– Supports DATE / TIMESTAMP / CHAR / DECIMAL / INTEGER / SMALLINT

– Define date format code for column from supplied table of date format codes

– May define defaults, for example, PIC=DATE, DFC=ISODATE (1998-12-25)


Physical Ager...

TCOTAB definition (optional)– Standard action is to add date difference to every

applicable date column– Non-standard aging may be specified for particular

tables/columns through TCOTAB (override table). For example,

– Additional adjustment ( + / - days)– YYMM=ONLY– BIZDAYS=YES


Physical Ager...

Running DB2Ager– Executes as batch job or through TSOMON– Specify run-time parameters -

– CTLTAB = table-name (default CTLDB2)– TDETAB = table-name (default DB2KTDE)– COMMIT = TABLE / END– LOCK = NO / SHARED / EXCLUSIVE – UPDATE = YES / NO– DEBUG = YES / NO


Physical Ager...

Running DB2Ager– Optionally may specify one or more DB2 table names

in SYSIN file– Otherwise process all tables in TDETAB

– May specify UPDATE=NO and DEBUG=YES to see what updates would be applied without physically changing data


Physical Ager...

Testing applications– Applications may be tested directly against physically

aged database– Applications also require time-travel functionality eg.,

– EZTEST DATE or other equivalent 3rd party product

– Set assumed run date as required by CTLTAB used in generating aged database


Logical Ager...

– Provides applications appearance data is aged without physically changing database

– Implemented by creating new logical DBRMs– DBRM version created for each required

assumed run date– Different applications/users may test at the same

against different assumed run dates by using different versions of DBRM


Logical Ager…

– Increases productivity and saves DASD resource as no need to create (multiple) test databases

– Following data types supported– DB2 DATE / CHAR / TIMESTAMP


Logical Ager...

Examples– SELECT statement

All columns in the result set and WHERE/HAVING criteria (if any) containing supported date types will be incremented by the date difference. eg.,

SELECT(D1+365 DAYS) FROM T1 WHERE (D2+365 DAYS) = :H


Logical Ager...

Examples– UPDATE statement

All values for columns (host variables/expressions) containing supported date types will be decremented by the date difference

All columns in WHERE criteria (if any) containing supported date types will be incremented by the date difference. eg.,

UPDATE T1 SET D1 = (DATE (:H - 365 DAYS)) WHERE (D2 + 365 DAYS) = :H


Logical Ager...

Examples– INSERT statement

All values for columns (host variables/expressions) containing supported date types will be decremented by the date difference eg.,

INSERT INTO T1 (D1,D2) VALUES (:H, :H)

The VALUES clause will be changed to a sub-select to allow date arithmetic

INSERT INTO T1 (D1,D2) SELECT (DATE (:H) - 365 DAYS), (DATE(:H) - 365 DAYS) FROM AGVDUMMY


Logical Ager...

Examples– DELETE statement

All columns in WHERE criteria (if any) containing supported date types will be incremented by the date difference. eg.,

DELETE FROM T1 WHERE (D2 + 365 DAYS) = :H

(extra parenthesis are added where applicable to ensure the proper order of incrementing/decrementing)


Logical Ager...

Examples– If the column list is missing, DB2ager will dynamically

prepare the 'SELECT * FROM T1' to get the column list

– All columns in WHERE/HAVING criteria (if any) of a sub-query containing supported date types will be incremented or decremented by the date difference


Logical Ager...

Using the logical ager

– Generate required control tables– Execute the virtual ager against required DBRMs– Test the applications using logical DBRMs


Logical Ager...

Generate required control tables– CTLTAB

– date difference derived from RUNDATE-BASEDAT

CTLDB2 #CTLTAB ENTRY=FIRST,TYPE=DB2,#CTLTAB ENTRY=DBEZ2000, RUNDATE=20000115, BASEDAT=19970929#CTLTAB CLASS=JOB,NAME=ASOXGB*

‘‘

#CTLTAB ENTRY=LAST


Logical Ager...

Generate required control tables– TDETAB - define relevant DB2 tables / columns

DB2KTDE #TDETAB ENTRY=FIRST,SYSTEM=DB2P10,DEFPIC=DATE,DEFDFC=IBMEURDT

*#TDETAB ENTRY=TABLE,NAME=T0348_KERN_PERS#TDETAB ENTRY=COL,NAME=DAT_GEB,PIC=CHAR

*#TDETAB ENTRY=TABLE,NAME=T1060_TERM_STAT#TDETAB ENTRY=COL,NAME=LOESCH_DATE#TDETAB ENTRY=COL,NAME=VORLAGE_DATE#TDETAB ENTRY=COL,NAME=MAHN_DATE,PIC=TIMESTAMP

‘‘

#TDETAB ENTRY=LAST


Logical Ager...

TDETAB– DB2AGERV parses the RCM looking for references to

columns defined in the TDETAB– Where appropriate (e.g. if SELECT * is used, or a

column list is not specified), DB2AGERV will dynamically prepare the SELECT statement to get the column list


Logical Ager...

Running DB2AGERV– Executes as batch job– Specify run-time parameters

– CTLTAB = table-name (default CTLDB2)– TDETAB = table-name (default DB2KTDE)– DBRMIN = input DBRM name– DBRMOUT= output DBRM name – DEBUG = YES / NO


Logical Ager...

Testing applications– Applications to be tested must be bound using the new

DBRM– Applications also require time-travel functionality eg.,

– EZTEST DATE or other equivalent 3rd party product

– Set assumed run date as required by CTLTAB used in generating logical DBRM


Contact TACT Software….

TACT Software

84 West Park Place

Stamford, CT 06901

Tel: 800-433-TACT

203-967-8228

Fax: 203-967-1122

Email: [email protected]

URL: http://www.tact.com

db2 data aging

Documents