Comment Optimiser Une Application DB2 ZOS Sans Modifier Les Ordres SQL Ni Les Programmes

Comment optimiser une application DB2 pour z/OS
sans modifier les ordres SQL, ni les programmes ?
Marcel Lvy
Natixis
Guide DB2A
Le jeudi 5 dcembre 2013
Click to edit Master title style
Agenda
Identify potential targets

Size does matter
Filtering means efficiency
Decreasing wait times
Go further
Disclaimer: Information provided without any warranty or liability and use of this
information is at the sole risk of the user. The author and his company are not
responsible or liable for the availability of these resources and for any content.
Identify potential targets 1

Why no SQL or Application Change?
Urgent (duty call for a critical process)
No source of program available (outsourced, vendor package)
Expensive cost of software maintenance (2 releases per year)
Limitations
Dont always expect to improve this way
Fix the consequences and never the original causes
Application change usually gives better results
Development thinks the problem is fixed for good
Bypass might not work anymore after a change:
DB2 level, DB2 configuration, program, data, access pattern
People might consider youre responsible if not working anymore

Pros
Buy time for a more stable solution including application change
Dont let think that DB2 is slow and inefficient
Bypass might be non disruptive and quick to implement
DB2 as a camera
Automatic mode: DB2 defaults and no new features.
Minimal knowledge required. Are you afraid of changes?
Manual mode: choose adapted values for DB2 options and new
features if you know what you are doing. Results should be better
or worse if you dont understand business rules.
Professional photographers use manual mode for better pictures.

Your objective is to identify applications that use a lot of
system resources in a non efficient manner:
CPU
I/O
Memory
A DB2 Accounting report is a good starting point. Then

you might need a DB2 Performance trace to identify
costly SQL statements. Use your DB2 monitor product to
display information online.
Find out if your application is CPU or I/O bound, spent
more time in DB2 than in program logic, which packages
consume most of CPU time, .

Create your Performance History database:
DB2 Accounting data located in SMF 101 records
Split data by plan, package
and by plan-package (ideal for cross-reference)
Aggregate data by hour, day, week, month
Load data into DB2 tables.
Your DB2 monitor usually provides a set of ETL tools.

Consider DB2 Statistics Data to detect System issues.
Recommended DSNZPARM values: SMFACCT=1,2,3,7,8
SMFSTAT=YES STATIME=1 SMFCOMP=ON
Use the power of SQL to isolate non efficient applications.

Create your list of potential targets
List packages by month sorted by CPU desc
Define SQL metric for each package:
number of SQL statements processed per DB2 CPU second.
Investigate packages with low SQL metric value.
Numbers between 0 and 1,000 are considered as low values.
These packages should easier to optimize because average DB2
CPU time per SQL statement is greater than 1 ms.
Later, start to optimize packages with SQL metric > 1000.
CPU time is important because it contributes to IBM and

ISV annual cost and internal chargeback.
z/OS Performance analysts use Service Units
(see DB2 field QWACSUCV: CPU service unit conversion factor)

Main contributors to DB2 CPU time
#SQL calls
#getpages
#locks
#pages read
#rows processed
#rows sorted
Look for big numbers and make sure these numbers are
appropriate. Compare with similar efficient processes.
Reduce large values in order to decrease CPU time.
Following example will show you some opportunities.

Found package P102DTE with low SQL metric :
MONTH
#EXEC
CPU_DB2
01.2013 5300
901
02.2013 4883
834
03.2013 4910
850
04.2013 4531
829
05.2013 5146
939
06.2013 4854
895
07.2013 4808
885
Note: units are seconds.
ELAP_DB2
1458
1283
1381
1319
1415
1446
1380
SQL/CPU
637
640
626
596
576
589
582
NB_SQL
574477
534510
533468
494400
542112
527485
515600
Found plan using this package with plan-package table.

Next slide displays online DB2 Accounting report.
10

Observe and Analyze DB2 Accounting report (OLTP)
RUNTIME ANALYSIS
ELAPSED TIME
CPU TIME
DB2 WAIT TIME
NOT ACCOUNTED
IN DB2
274 ms
198 ms
12 ms
64 ms
IN APPL.
20 ms
4,574 us
TOTAL
294 ms
202 ms
DB2 is waiting for CPU resource.

Check other factors: http://tinyurl.com/DB2zOSnotaccounted
TOTAL SQL.....................205
GETPAGES....................7,169
SYNC READS (PRLL=00)...........15
PREFETCH PAGES READ...........150
PACKAGE
P093DTE
P102DTE
P732DTE
NO. SQL
4
116
85
CPU TIME
534 us
194 ms
2,750 us
SQL metric: 1035
WAIT TIME ELAPSED

969 us
580 us
11 ms
268 ms
n/a 5,578 us
SQL metric: 598
GETPAGES FROM BP1 (index) : 6,959 with 235 dynamic prefetch events
11

Run DB2 Performance trace to identify SQL statements:
STMT
TYPE
STMT
------- ----OPEN
5082
FETCH
5087
CLOSE
5097
SELECT
5668
SELECT
5457
SELECT
5482
OPEN
5309
FETCH
5314
/...
COUNT
----1
1
1
1
2
1
1
1
AVG.
%
ELAPSED ELAP
-------- ----13 us
0.0
469 us
0.2
6 us
0.0
192 us
0.1
89 ms 60.7
1,471 us
0.6
85 ms 32.1
76 us
0.0
AVG.
%
CPU
CPU
-------- ----12 us
0.0
95 us
0.0
6 us
0.0
170 us
0.1
62 ms 63.5
183 us
0.1
63 ms 32.7
41 us
0.0
SORT
RECS
---0
0
0
0
0
0
60
0
PAGES SCANNED
INDX DATA WORK+
---- ---- ---6
4
0
2
1
0
0
0
0
4
1
0
4550
83
0
2
1
0
2277
41
0
0
0
0
Investigate SELECT #5457 and OPEN cursor #5309

(99% of CPU time and 93% of elapsed time)
12

Why this access path is not efficient?
STMT
TYPE
STMT
------- ----SELECT
5457
SELECT
FROM
WHERE
AND
AND
AND
AND
COUNT
----2
COUNT(*)
TBAD043
COL1 = :H
COL2 = :H
COL5 = :H
COL6 = :H
COL9 = :H
AVG.
%
ELAPSED ELAP
-------- ----89 ms 60.7
AVG.
%
CPU
CPU
-------- ----62 ms 63.5
SORT
RECS
---0
PAGES SCANNED
INDX DATA WORK+
---- ---- ---4550
83
0
Matching 2 columns index IXAD043B with dynamic prefetch.

Usually, 5 getpages per SQL statement (OLTP):
4 getpages for index and 1 getpage for tablespace.
Here, we have about 2300 getpages per SQL statement.
screening predicate
Table TBAD043 contains about 1 million rows with 2 index:

IXAD043A (COL1, COL2, COL3, COL4, COL5, COL6 desc) CLUSTER unique
IXAD043B (COL1, COL2, COL3, COL6 desc) non unique

Understand data and index filtering
SELECT
FROM
WHERE
AND
AND
AND
AND
COUNT(*)
TBAD043
Performance trace shows value of host-variables
COL1 = 20
COL2 = RETB
COL5 = A
COL6 = '2013-06-18-00:00:00.000000
COL9 = 1
Results: 60
SELECT
FROM
WHERE
AND
COUNT(*)
TBAD043
COL1 = 20
COL2 = 'RETB
Results: 270257
SELECT COUNT(*)
FROM TBAD043
WHERE COL1 = 20
AND COL2 = 'RETB
AND COL6 = '2013-06-18-00:00:00.000000
Results: 60
Create new index?: IXAD043C (COL1, COL2, COL6 desc) non unique
Modify existing index?: IXAD043B (COL1, COL2, COL6 desc, COL3) non unique
Opportunity for index only?: if really necessary.
13
14

STMT
TYPE
STMT
------- ----OPEN
5309
COUNT
----1
AVG.
%
ELAPSED ELAP
-------- ----85 ms 32.1
AVG.
%
CPU
CPU
-------- ----63 ms 32.7
SORT
RECS
---60
PAGES SCANNED
INDX DATA WORK+
---- ---- ---2277
41
0
DECLARE C1 CURSOR FOR

SELECT COL15, COL17, COL18, , COL20
FROM TBAD043
WHERE COL1 = :H
Matching 2 columns index IXAD043B with sort and dynamic prefetch.
AND COL2 = :H
Goal: improve filtering and get rid of sort.
AND COL5 = :H
New access path: matching 3 columns without sort.
AND COL6 = :H
ORDER BY COL17 DESC, COL18 DESC
Create new index?: IXAD043C (COL1, COL2, COL6 desc, COL17 desc, COL18 desc)
Modifiy existing index?:
IXAD043B (COL1, COL2, COL6 desc, COL17 desc, COL18 desc, COL3)
because no matching 3 columns IXAD043B access path found in PLAN_TABLE.

Review of history DB2 RTS shows:
80,000 inserts
22,300 updates
No deletes
Ask Development about data activity:

Why no deleted rows within 6 months?
What is the expected number of rows for the next 5 years?
Why only 1 row fetched for cursor C1?
Different ways to improve performance

Decrease size
Increase filtering
15
Size does matter 1

Size of DB2 objects impacts CPU time, number of I/Os
and buffer pool hit usage.
Goal: less data and more number of entries per page
How to reduce size:
Delete unused rows

Add or remove data compression
Reduce freespace
Increase page size
Remove obsolete columns
Most options available without SQL or program change.
16
Size does matter 2

Monitor growth with history of DB2 Real Time Statistics:
sysibm.systablespacestats
sysibm.sysindexspacestats
Development should know business rules to delete rows

How to delete rows:
Run program with SQL delete statements

Unload, remove records, sort, LOAD replace
REORG with DISCARD option
ALTER TABLE ROTATE integer TO LAST
Alternative: application logic uses active and inactive

tables. First table contains less rows, but more accessed.
17
Size does matter 3
Check tablespace compression opportunity

Goal: increase number of rows per data page up to 255
How: alter tablespace COMPRESS YES + REORG
DB2 uses hardware microcode and built-in dictionary per
partition including for UTS PBG (<> classic segmented)
Beware of not really compressed partitions: check with
dsn1comp utility. DB2 10: compress on insert.
Pagesave from SYSTABLEPART indicates compress
ratio if statistics were collected. If not, check messages in
last LOAD or REORG utilities report.
18
Size does matter 4

Negative or low value means not worth it. High value
means maybe redundant data and opportunity to remove
unneeded rows and columns. Looks for columns filled
with blanks, zeroes or same values.
Beware of keepdictionary option that saves CPU during
utility execution maybe at the price of a lower comp. ratio.
Tablespace scan: add CPU because of decoding cost.
Improved in DB2 11. Compression is helpful for most
OLTP transactions.
Index compression more valuable for BI Queries.
In some cases, combine with bufferpool size change.
19
Size does matter 5

Freespace is used for new and updated rows between
two REORGs.
Options that control freespace (tablespace + index):
PCTFREE at partition level
FREEPAGE at partition level
Change materialized after next REORG or LOAD replace.

Beware of MAXROWS value (default: 255): this freespace
is never used, just to improve concurrency.
If no new or updated rows, no freespace should be
implemented. For example, LOAD replace only.
20
Size does matter 6

If new rows are always inserted at the end, no freespace
needed for tablespace and cluster index.
Other indexes need freespace if cluster ratio is not high
(PCTFREE). Mandatory in Data Sharing: index page split
is a penalty (2 sync. Log write I/O). Improved in DB2 11:
decreased to only 1 sync. Log write I/O.
Maximum FREEPAGE value is SEGSIZE 1. Consider
altering SEGSIZE (DB2 10 UTS) or FREEPAGE=0
in order to reduce freespace.
In DB2 10 NFM, new partitioned tablespaces are created
with SEGSIZE 32 (see new ZPARM: DPSEGSZ).
21
Size does matter 7

Page size (tablespace or index) is usually 4K bytes.
Depending on row/key size, it might be pertinent to
increase page size to 8K, 16K or 32K.
Goal: increase number of entries per page
Note: 255 is the maximum only for tablespace.
Useful to combine with Data compression.
Bufferpool efficiency might be affected for random access.
In Data Sharing, increasing index page size helps to
reduce number of page split. But you might get more
index and/or data page latch contention. Performance is
always a trade-off.
22
Size does matter 8

Over the years, the number of columns in a DB2 table
increases. Sometimes, they are never used, even some
programs are still inserting new values.
Goal: remove obsolete columns
How to (Static SQL):
Check: alter table rename column (DB2 9)
Remove: alter table ... drop column (DB2 11, UTS only)
Impacted views and triggers need to be dropped
in order to alter table. Then modify and recreate them.
Dependent packages are invalidated.
If you are lucky, no application change is needed.
23
Filtering means efficiency 1

Consider SQL statement as a question that is expecting
an answer. If the answer is only a few rows, DB2 access
path should ideally involve a few getpages and I/Os.
Early filtering will definitely help:
Matching predicates
Screening predicates
Stage 2 predicates
Read IBM DB2 z/OS Managing Performance manual:

look for Summary of predicate processing .
Application logic should not retrieve undesired data
(as known as stage 3).
24

A few ideas to increase filtering when designing indexes:
Maximize the number of matching columns

Index columns with high cardinality first
Add columns even they dont participate in matching (screening)
Prefer multi-columns instead of single column index
Dont forget column sequence in order to get rid of sort
Use new DB2 10 feature: include columns for unique indexes
Try index on expression or DPSI if applicable
Performance is a trade-off between CPU for selects and

CPU for inserts, update, delete and Utilities.
But keep number of indexes to a minimum.
25

How to remove unnecessary indexes
Check DB2 RTS column LASTUSED (static and dynamic)
Do not remove unique indexes, except former type 1 non unique
index transformed into unique index by adding unique columns
Think about backward scan (available since Version 7 and 8)
Convert index-controlled to table controlled-partitioning for
opportunity to drop former partitioning index if not used for access
Merge several indexes
Understand the importance of clustering (mostly in batch)

Sequential process (asynchronous I/Os)
Enable prefetch (sequential or dynamic)
26

How to help DB2 to choose a better access path:
Use RUNSTATS with colgroup or histogram options
Use REOPT(always) at statement-level with APR
Use a Optimization Hint: more stable with APR
Rebind package switch to original/previous copy
Rebind package with APREUSE (prevent from any change)
Use tricks in SQL statements (OR 0=1, )
Modify DB2 Statistics before rebinding
Rewrite SQL statement
APR means Access Path Repository (DB2 10 NFM)

Look for BIND QUERY in the manual.
27
28

Found package P500NST with low SQL metric :
DATE
03.06.13
04.06.13
05.06.13
06.06.13
07.06.13
#EXEC
1
1
1
1
1
CPU_DB2
72
67
50
64
61
ELAP_DB2
571
520
382
484
519
SQL/CPU
517
483
439
465
413
NB_SQL
37279
32657
22081
29859
25019
Note: units are seconds.
Elapsed time: about 8 X CPU time

Found plan using this package with plan-package table.
Next slide displays online DB2 Accounting report.
29

Observe and Analyze DB2 Accounting report (Batch)
RUNTIME ANALYSIS
ELAPSED TIME
CPU TIME
DB2 WAIT TIME
NOT ACCOUNTED
IN DB2
00:10:06
00:01:55
00:07:26
45 s
IN APPL.
00:02:16
41 s
TOTAL
00:12:22
00:02:36
DB2 is waiting for CPU resource.
Check other factors: http://tinyurl.com/DB2zOSnotaccounted
TOTAL SQL..................6,082K
GETPAGES...................4,430K
SYNC READS (PRLL=00).......74,337
PREFETCH PAGES READ........4,429K
PACKAGE
P500NST
P634NST
P035NST
NO. SQL CPU TIME

25,019 00:01:01
6,041K
54 s
16,159
390 ms
SQL metric: 52,887
WAIT TIME ELAPSED

00:07:25 00:08:39
19 ms
00:01:24
105 ms 2,397 ms
SQL metric:
410
SQL metric: 111,870
30

Run DB2 Performance trace to identify SQL statements:
PROGRAM
P500NST
P500NST
P500NST
STMT
TYPE
OPEN
FETCH
CLOSE
SECT
NO.
1
1
1
STMT SQL +----- TOTAL IN-SQL TIME -----+

NO. CALLS ELAPSED
% CPU
%
1396
1 00:00.82050
0 00:00.08037
0
1409
668 00:00.01227
0 00:00.00932
0
1435
1 00:00.00000
0 00:00.00000
0
GETPAGES
2601
11
0
SIOS
TOTAL
113
0
0
P500NST
P500NST
P500NST
OPEN
FETCH
CLOSE
2
2
2
1490
667 00:00.00619
1503 11842 07:47.19945
1544
667 00:00.00393
0 00:00.00576
90 00:59.52724
0 00:00.00330
0
99
0
0
3540K
0
0
64145
0
P500NST
SELECT
1565 11176 00:50.55968
10 00:00.51287
19972
9161
Investigate slow FETCH #1503

(99% of elapsed time and of CPU time)

CALL
SECT STMT
+--- SQL --+
PROGRAM TYPE
NO.
NO.
CALLS ERRS
-------- ------ ----- ------ ------ ----P500NST OPEN
2
1490
667
0
P500NST FETCH
2
1503 11842
0
AVERAGES:
DECLARE
SELECT
FROM
WHERE
AND
AND
AND
AND
AND
+- TOTAL IN-SQL TIME -+

ELAPSED
CPU
GETPAGES
----------- ----------- -------00:00.00619 00:00.00576
0
07:47.19945 00:59.52724 3539540
00:00.03945 00:00.00503
299
C2 CURSOR FOR
Matching 1 column index IXDF090D with sequential prefetch
COL1, / , COL34
TBDF090
COL1 = :H matching
COL4 = :H
COL5 = :H screening
NUMBER
WAIT TIME
COL6 = :H
SYNC I/O......: 64145
00:02:21
COL7 = :H
ASYNC READ I/O: 90490
00:04:12
COL8 = :H
Table TBDF090 contains about 74 millions rows with 6 index:

IXDF090A (COL1,COL2,COL3,COL4,COL5,COL6,COL7) CLUSTER unique
IXDF090D (COL1,COL2,COL5,COL3) non unique
31
32

SELECT COL1, COL5, COUNT(*) AS 'COUNT'
FROM DB2P.TBDF090
GROUP BY COL1, COL5
ORDER BY 3 DESC
COL1
5500
1177
5500
COL5
8923
8154
8221
COUNT
270222
173814
170980
.../...
SELECT COL1, COL5, COL4, COL6, COL7, COL8, COUNT(*) AS 'COUNT

FROM DB2P.TBDF090
WHERE COL1 = 5500
AND COL5 = 8923
GROUP BY COL1, COL5, COL4, COL6, COL7, COL8
ORDER BY 7 DESC
COL1
5500
5500
5500
COL5
8923
8923
8923
COL4
RIL
RIL
RIL
COL6
EFG
EFG
SF9
COL7
14.02.2002
17.04.2001
02.09.1998
COL8
14.02.2002
17.04.2001
02.09.1998
COUNT
99640
82740
496
5500
8923
RIL
PWD
17.07.1999
17.07.1999
.../...
Create new index?: IXDF090G (COL1, COL5, COL6, COL7) non unique

This access path is efficient, but
CALL
SECT STMT
+--- SQL --+ +- TOTAL IN-SQL TIME -+
PROGRAM TYPE
NO.
NO.
CALLS ERRS ELAPSED
CPU
GETPAGES
-------- -------- ----- ------ ------ ----- ----------- ----------- -------P634NST OPEN
3
1248
144K
0 00:01.35380 00:00.80211
2
P634NST FETCH
3
1257 5609K
0 00:50.20420 00:31.40922
862927
AVERAGES: 00:00.00001 00:00.00001
0
DECLARE C3 CURSOR FOR
SELECT COL4, COL5, COL10, COL11, COL6
FROM TBCD010
WHERE COL1 = :H
Matching 4 columns index IXCD010E
AND COL2 = :H
AND COL3 = :H
Table contains only 68,000 rows,
AND COL6 <= :H
but 5,609,000 rows are fetched!
AND COL4 >= :H
Why not to preload table or remove redundant SQL calls?
AND NOT((COL4 = :H)
AND (COL5 <= :H))
ORDER BY COL4, COL5, COL6 DESC
Index IXCD010E (COL1,COL2,COL3,COL4,COL5,COL6 desc) non unique
33
Decreasing wait times 1

OLTP: CICS/DB2 or IMS/DB2 transaction
1 Input / Output: Read or Write operation.
1 I/O: 10ms, usually less than 5ms,
depending on disk cache activity
1 synchronous I/O involves 1 page, application is waiting.
1 asynchronous I/O involves a set of consecutive pages,
usually 32 pages. Because several asynchronous I/Os
are sequentially triggered, time to read 1 page should be
less than 0.2 ms. Ideally, application isnt waiting.
Number of I/Os can be reduced with better DB2 access
path, bufferpool tuning and application change.
34

Mainly: wait for I/Os and locks.
Usually, async I/Os overlapped with CPU time.
Profile for best performance
OLTP: a few sync. I/Os and almost no async. I/Os
Batch: mostly async. I/Os with a few sync. I/Os
Bad behavior
OLTP: a lot of sync. I/Os and async. I/Os
Batch: a lot of sync. I/Os and a few async. I/Os
(as known as Death by Random I/Os)
Reduce number of I/Os and in particular synchronous

I/Os that slow down your application. CPU time for I/Os
will be reduced too.
35

Check DB2 access path of queries that trigger I/Os.
Look for tablespace scan, non matching index scan, multi
index access (MIAP), matching index with one or two
columns with low cardinality, merge scan or hybrid join, ...
Look for objects with low buffer pool hit ratio and high
number of sync I/Os.
Opportunity to increase bufferpool size (vpsize), vpseqt,
to move object to another bufferpool with same or bigger
size (batch only).
Reduce number of I/Os when average I/O time is high.
36

Index screening helps to reduce
number of getpages and data pages I/Os.
Look for open statement with sort.
Use index to get a access path with no sort.
Reduce key size (columns) and #records to be sorted.
Get rid of sort materialization if high number of records
sorted and low number of rows fetched.
Use order by and fetch first n rows only clauses in cursor
if applicable. Inmemory replacement sort technique
might used by DB2 (DB2 9 and DB2 10).
37
Use Index I/O parallelism (DB2 10)

Reduce number of locks and latches
Use bind currentdata(no) and isolation(cs): lock avoidance
Try new Current Committed Data feature with UTS
For insert and delete statements (DB2 10)
For update statements (DB2 11)
Get rid of simple tablespace (locking issue)

Remove GBP dependency if applicable (-ACCESS DB)
ALTER table APPEND(YES) to speed up the freespace
search during SQL insert and online LOAD
Use DB2 Parallelism and save CPU with zIIP
38
Go further 1
Theres a common misunderstanding about DB2
performance issue:
DB2 Application performance
DB2 DBMS performance
Sometimes, DB2 is victim itself.

Practice any kind of performance problem. It will help you
to work with different actors as a team in a task force.
Migrate to a newer release or apply maintenance
More hardware resources will speed up your SQL and
DB2 Utilities. Memory is the cheapest resource and will
help you to save I/O and CPU. But your applications wont
be more efficient, just faster.
39
Go further 2
With VARCHAR type, test and use
Non-padded index
RRF (Reordered Row Format)
CHAR if max column length is less than 18
Enough freespace for column update
Use Multi-rows fetch, insert or merge

DB2 10: improvement for MRI in Data Sharing
(Complete LRSN spin avoidance)
Unload format internal is much faster and useful if you

would like to reload data in similar table.
Try to lower the total SQL statements.
40
Go further 3
How to solve a DB2 Performance Problem?
Open and describe the problem

Any time spent in DB2?
CPU or I/O bound?
Run 3Rs (REORG, RUNSTATS, REBIND)
Identify large plans, packages and SQL statements
Any Size to reduce?
Any Program Logic issue?
Any Access Path Selection issue?
Describe solution
Fix, test, deploy, check
Communicate and close problem
41
Go further 4
Estimate gains and cost to implement
in order to compute Return On Invest for your Manager.
Update your company standards with DB2 features
available in 2013 (Version 10, not Version 3).
Dont be afraid to use new features: evaluate, test, write
best practices and update your company standards.
During your review, dont forget to note any potential
change that imply SQL or program change.
IBM improved SQL runtime with disorganized index.
Time to experiment less REORGs in order to save CPU
cycles and decrease locking issues with bad applications?
42

Comment Optimiser Une Application DB2 ZOS Sans Modifier Les Ordres SQL Ni Les Programmes

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Comment Optimiser Une Application DB2 ZOS Sans Modifier Les Ordres SQL Ni Les Programmes

Загружено:

Авторское право:

Доступные форматы

Comment optimiser une application DB2 pour z/OS

sans modifier les ordres SQL, ni les programmes ?

Click to edit Master title style

Identify potential targets

Click to edit Master title style

Identify potential targets 1

Click to edit Master title style

Identify potential targets 2

Click to edit Master title style

Identify potential targets 3

A DB2 Accounting report is a good starting point. Then

Click to edit Master title style

Identify potential targets 4

Your DB2 monitor usually provides a set of ETL tools.

Click to edit Master title style

Identify potential targets 5

CPU time is important because it contributes to IBM and

Click to edit Master title style

Identify potential targets 6

Click to edit Master title style

Identify potential targets 7

Found plan using this package with plan-package table.

Click to edit Master title style

Identify potential targets 8

DB2 is waiting for CPU resource.

SQL metric: 1035

WAIT TIME ELAPSED

SQL metric: 598

Click to edit Master title style

Identify potential targets 9

Investigate SELECT #5457 and OPEN cursor #5309

Click to edit Master title style

Identify potential targets 10

Matching 2 columns index IXAD043B with dynamic prefetch.

Table TBAD043 contains about 1 million rows with 2 index:

Click to edit Master title style

Identify potential targets 11

Click to edit Master title style

Identify potential targets 12

DECLARE C1 CURSOR FOR

Click to edit Master title style

Identify potential targets 13

Ask Development about data activity:

Different ways to improve performance

Click to edit Master title style

Size does matter 1

Delete unused rows

Most options available without SQL or program change.

Click to edit Master title style

Size does matter 2

Development should know business rules to delete rows

Run program with SQL delete statements

Alternative: application logic uses active and inactive

Click to edit Master title style

Size does matter 3

Check tablespace compression opportunity

Click to edit Master title style

Size does matter 4

Click to edit Master title style

Size does matter 5

Change materialized after next REORG or LOAD replace.

Click to edit Master title style

Size does matter 6

Click to edit Master title style