Morten Buur Rasmussen …schd.ws/hosted_files/data3hk2017/e2/2017 10 17 - Common...IBM iSQL...

© 2017 IBM Corporation

Power Systems Performance

A practical approach to IBM i SQL performance tuning

October 2017

Morten Buur Rasmussen – [email protected]

IBM Lab Services Europe


• The minimum you should know about DB2/SQL for IBM i in the

performance area.

• When you are working with SQL and query tuning you should know

the free tools provided like the Visual Explain where you can view

SQL information from the Plan Cache and from the DB Monitor

trace.

• What is a good approach to viewing the data. Where can you

possible get some easy wins in making your performance better.

• What are the advantages and disadvantages of using the DBMON

(DB Monitor trace).

Goal of this 45 min presentation

2


• Tools to use for SQL performance

• How much SQL is running in your partition and what type?

• Still having CQE around?

• Can we use Plan Cache and avoid DBMON?

• Does your Plan Cache have the right size?

• Do you need to use the Event Monitor?

Session objectives

4


Lewis Hamilton had the best tool and succeeded

Good Tools is VERY important

5


• DBMON – Database monitor trace

• Plan Cache

• Plan Cache event monitor

• Visual Explain

• Jobwatcher and even better iDoctor

--------------------------------------------------------

• Print SQL Information (PRTSQLINF)

• SQL packages

• Programs, service programs with embedded SQL

• Debug joblog

Tools to use for SQL performance

6


� xx

IBM i Access Client Solutions (ACS)


Indexes

Advised

SQE Plan

Cache

Query

Optimization

SQL request Detailed

DB Monitor

Data

Visual

Explain

SQL information and optimization Feedback

SQE Plan

Cache

Snapshots

Jobwatcher

(from job info)

Plan to SQL

packages

Plan to

Programs and

Service pgmsPrint SQL

Information

Debug Job Log

messages

8

Plan Cache

Event monitor

SQE Plan

Cache

properties


• For all queries, unless

• You are running 7.1

• You have chosen to use The CQE for QRY/400 and

OPNQRYF via QAQQINI setting:

• QAQQINI option SQE_NATIVE_ACCESS *NO

• You have chosen on job level or system level not to capture

queries in Plan Cache:

• QAQQINI option

SYSTEM_SQL_STATEMENT_ CACHE *NO

SQE Plan Cache?


call qsys2.dump_plan_cache_properties(‘LIB',

‘PCPROP1');

SQL performance approach – Plan Cache

10


• In version 7.1 and 7.2, its tempting to simply use the

SQE Plan Cache when analyzing missing indexes

and queries taking up most time.

• Before doing this, its important to make sure the Plan

Cache size is large enough and check the Plan

Cache settings

• You can capture the properties into a file:

call qsys2.dump_plan_cache_properties(‘LIB', ‘PROP1');

SQL performance approach – Plan Cache

11


• Examples of what can cause the a high number of plans pruned

from the Plan Cache.

• Plan Cache is too small for the queries running

• Unqualified queries in scenarios where the PATH or library list

is changing

• Environment is changing over the short time, like the memory

pool where the query is running. This can be caused by having

the automatic performance adjuster activated.

• Queries are running in different memory pools and the memory

pools have different sizes.

More equal query plans in the Plan Cache

12


• SELECT A,B FROM F1 where C in (1,2);

• SELECT A,B FROM F1 where C in (1,2,3);

• SELECT A,B FROM F1 where C in (1,2,3,4);

• SELECT A,B FROM F1 where C in (1,2,3,4,5);

• SELECT A,B FROM F1 where C in (1,2,3,4,5,6);

• SELECT A,B FROM F1 where C in (1,2,3,4,5,6,7);

• SELECT A,B FROM F1 where C in (1,2,3,4,5,6,7,8);

• SELECT A,B FROM F1 where C in (1,2,3,4,5,6,7,8,9);

How many Plans can you get here?










If QPFRADJ = 0, probably only one plan here


DBMON

Snapshot

Event Monitor

Time

This is only if the DBMON and Event Monitor is running all the time

What Plan Cache data can be collected


• In ACS under Run SQL Scripts:

Plan Cache Event monitor


Use ACS:

Daily SQL Plan Cache management


• To collect all pruned plans, you can use the following two

procedures:

Plan Cache Event Monitor


• Run DBMON to select only CQE (Classic Query Engine):

• STRDBMON OUTFILE(MYLIB/MYMONFile) JOB(*ALL)

TYPE(*DETAIL) COMMENT('WANT_CQE_ONLY')

Still having CQE around?

19


• If the number of CQE requests are limited, we can make use of the

Plan Cache for the primary tool to analyze SQL performance.

• If the number of pruned plans is high, we need to make use of the

Event Monitor.

• If the CQE queries are still around, its needed to use DBMON

• Make use of the COMMENT('WANT_CQE_ONLY')

• This can still be an overhead on the system, even for SQE.

• The overhead of running DBMON can sometimes be up to 1ms or

more per SQL request.

• Good SQL requests can often run in 200 micro seconds, so the

overheard could potential be very significant.

Can we use Plan Cache and avoid DBMON?

20


Save Plan Cache:

CALL QSYS2.DUMP_PLAN_CACHE(‘MYLIB', 'PCS1')

Clear Plan Cache:

'CALL QSYS2.CLEAR_PLAN_CACHE()')

Work is taking place overnight or during the day

Save Plan Cache:

CALL QSYS2.DUMP_PLAN_CACHE(‘MYLIB', 'PCS2')

Analyze the Plan Cache

Without SQL interface, you can execute SQL like this:

SBMJOB CMD(RUNSQL SQL('CALL

QSYS2.CLEAR_PLAN_CACHE()') COMMIT(*NONE) NAMING(*SQL))

Plan Cache – Alternative use in SQL interface

21


xxxxx

Use of Visual Explain (VE)

22


xxxxx


23


Index advised

What is the best INDEX ADVISED or PLAN CACHE?

24


Index Advised – System wide and Condensed

Queries:

PWHERE YEAR = 2016 AND QUARTER = 1 AND COLOR = ‘BLUE;

PWHERE YEAR = 2016 AND QUARTER = 1;

PWHERE YEAR = 2016;

Index advice by query:

YEAR, QUARTER, COLOR

YEAR, QUARTER

YEAR

Condensed advice:

YEAR, QUARTER, COLOR


Index advised


26


Plan Cache – most time consuming


27


Plan Cache – most frequently run


28


• Index advised

• All index advised

• Notification that something may be missing

• No knowledge if the advices would help any queries

• Plan Cache or Plan Cache snapshot

• Risk of missing queries because of cache or CQE

• Show how long time and how many times queries are running

• Can show most resource demanding queries and missing

advises


29


Access methods used by the query engine. Some very common:

Look at the access method. Often is the table scans and index scans not

very efficient, so it’s better, if you can have the query use an index probe.


30


� xx

Session summary


� With the IBM i and selected Power Systems™ servers, valuable education and services vouchers are included at no additional charge

� Vouchers are designed to help you more fully understand and use the advanced features and capabilities of IBM i

� Vouchers are only available with selected new Power Systems servers, and vouchers are not available with system upgrades

� Vouchers are valid for 5 years beyond the ship date

� For more information, eligible systems and registration information see: http://www-03.ibm.com/systems/power/hardware/vouchers/index.html

� Or contact: – Camilla Jellingdal - [email protected]– Pia Grynderup- [email protected]

IBM Lab Services Vouchers for IBM i


� IBM i Performance – IBM i Performance– SQL Performance

� IBM i Database– DB2 for IBM i Best Practices– DB2 Web Query for IBM i

� Security– Security Assessment– PowerSC– Single Sign On

� Availability– IBM i Availability Assessment– IBM i BRMS– PowerHA on IBM i

� System Solutions– Migration Assistance– PowerVM Virtual I/O Server and IBM i– External Storage for IBM i

� Middleware– WebSphere® with IBM i– PHP and Open Source on IBM i

� Applications– SAP on IBM

IBM i Vouchers – Available services

© 2017 IBM CorporationIBM Systems

IBM Lab Services: Proven expertise to help IT leaders plan,

design and implement infrastructure to

accelerate digital transformation

| 34

Contact in the Nordics:

Pia Grynderup

Nordic Manager, IBM Systems Lab Services

[email protected]

Camilla Jellingdal

Nordic Opportunity Manager

[email protected]

Morten Buur Rasmussen …schd.ws/hosted_files/data3hk2017/e2/2017 10 17 - Common...IBM iSQL...

Documents

Transcript of Morten Buur Rasmussen …schd.ws/hosted_files/data3hk2017/e2/2017 10 17 - Common...IBM iSQL...