0% found this document useful (0 votes)
129 views72 pages

03 - Indexing Strategy S3

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
129 views72 pages

03 - Indexing Strategy S3

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 72

Db2 for i

Indexing Strategy

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Indexing Concepts

• Two types of database indexing technologies are supported


– Radix Index
– Encoded Vector Index
(OmniFind Text Index is a separate concept)

• Each type of index has specific uses and advantages


• Respective indexing technologies complement each other
• Indexes can be used for statistics and implementation
• Indexes can provide RRNs and/or data
• Indexes are scanned or probed
– Probe can only occur on contiguous, leading key columns
– Scan can occur on any key column
– Probe and scan can be used together

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Indexing Concepts

Are there any other indexing options?

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Indexes with Derived Keys

• Indexes built on values derived from the column values can help
with a variety of predicates:

– Case insensitive searches:


 WHERE UPPER(lastname) = ‘MCKINLEY’

– Data extracted from a column:


 WHERE YEAR(orderdate) = 2015
 WHERE SUBSTR(lastname,1,3) = ‘DEN’

– Results of mathematical operations:


 WHERE COL1+COL2>0
 WHERE QTY*COST>1000

• Can enable index only access in more cases and also


reduce table scans and temporary data structures

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Indexes with Derived Keys

• Creation of indexes with derived keys via SQL


CREATE INDEX lastname_upper ON customers
(UPPER(lastname) AS ulastname ASC);
CREATE ENCODED VECTOR INDEX yearqtr ON orders
(YEAR(ORDERDATE) AS orderyear,
QUARTER(ORDERDATE) AS orderqtr ASC);
CREATE INDEX itemtotal ON order_detail
(QUANTITY * PRICE AS itemtotal ASC);
CREATE INDEX creative ON employee
(SUBSTR(firstnme,1,1) CONCAT midinit
CONCAT TRIM(lastname) AS nametoken ASC);
Note: There are some restrictions on when derived indexes
can be used by the optimizer

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Many Indexes Are Already Derived

firstname CHAR "Key" value for firstname


value (‘Michèle’) Build Key (some set of bytes)

Column value and attributes


used
"Key" value used during
• Create index
• Index Scan
• Index Probe
...ORDER BY firstname

• Michèle and Michele normally have equal weights for sorting

• An index built on firstname will behave differently depending on the sort


sequence it represents

• The same idea applies for indexes built to support different CCSID’s which may
have different representations based on their associated national language

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Sparse Indexes

Support of WHERE clause on SQL create index

CREATE INDEX VALID_CUSTOMERS ON CUSTOMERS


(CUSTOMER_ID ASC)
WHERE VALID_FLAG = 'Y';

CREATE INDEX SLOW_SHIPMODE ON ORDERS


(ORDER_ID ASC)
WHERE SHIPMODE = ' TRUCK' OR SHIPMODE = ' RAIL';

The SQE optimizer was enhanced in IBM i 7.1 to support sparse indexes

Even though they are supported, these sparse indexes are rarely useful

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Indexing Concepts

What kind of index works best?

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Indexing Concepts

cardinality The number of elements in a set.


• High cardinality = large distinct number of values
• Low cardinality = small distinct number of values

selectivity The number of elements matching the criteria.


• High selectivity = small number of rows match
• Low selectivity = large number of rows match

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Indexing Concepts

• Table contains one million rows


• Customer_ID column is unique
Customer • Country column is not unique
Master - USA
- Canada
- Mexico

Customer_ID is considered high cardinality or low cardinality?

Country is considered high cardinality or low cardinality?

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Indexing Concepts

• Table contains one million rows


• Customer_ID column is unique
Customer • Country column is not unique
Master - USA
- Canada
- Mexico

WHERE Customer_ID = 123

is considered high selectivity or low selectivity?

WHERE Country = ‘USA’

is considered high selectivity or low selectivity?


IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Indexing Concepts

In general…

• A radix index is best when selectivity is high and the key


cardinality is high

• An encoded vector index is best when selectivity is low and the


key cardinality is low

• Understanding the data and query are key to success

• The query optimizer will make the final decision based on cost

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Indexing Concepts

Can Db2 just tell me what indexes to create?

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Indexing Advice from the Optimizer

• The SQE optimizer:

– Provides robust advice

– Considers Radix and EVI indexes

– Is based on all parts of the query

– Can advise multiple indexes for the same query

– Has some limitations to be aware of

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Indexing Advice from the SQE Optimizer

• Local selection, Join, Group By, Order By


• Equals first, followed by one inequality (for probing)
• Simple Ored predicates
– Advice for up to five OR’ed predicates

• No derived keys
• No sparse indexes
• No EVI aggregate (include) columns
• Check advised EVI’s for cardinality/selectivity

Note: Acting on the index advice is NOT mandatory

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Index Advised – System wide

• System wide index advice


– Advice is saved in a Db2 catalog (QSYS2/SYSIXADV)
– Autonomic
– No overhead, part of the query optimization process

• GUI interface via Access Client Solutions


– Detailed and condensed advice for System, or Schema, or Table

• System only adds (summary) rows, user must manage the data
– Options to clear or prune

• Can create indexes directly from GUI


– Additional indexing analysis might be required to determine the optimal
index

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Visual Explain

• Graphical representation of query plan


–Representation of the database objects and data structures
–Representation of the methods and strategy
–Associated environmental information
–Advice on indexes and column statistics
–Highlighting of specific query rewrites
–Highlighting of expensive methods

• GUI interface via Access Client Solutions


• Based on detailed optimizer information
–SQE Plan Cache
–SQE Plan Cache Snapshots
–Detailed SQL Performance Monitor Data

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Indexing Concepts

Can Db2 just create the indexes for me?

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Autonomic Index Creation

• The Optimizer can direct the DB Engine to create temporary


radix indexes
• They provide almost all the functionality of a permanent index
with just a few differences:
– They are maintained
– They can be used for statistics
– Temporary indexes are reused and shared across jobs and queries
– Creation is based on “watching” the query requests over time
– Creation is based on optimizer’s own index advice

• Information on the creation and use of these temporary indexes


is available from the index advised catalog and the GUI

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Autonomic Index Creation – SQE in Action

Same query runs 100 times…


Amortization
Temp IX

Estimated No Indexes

Run
Time
IX Create Time

Maintained Temp IX

Permanent IX

Run 1
IPL Run 100

Time

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Indexing Concepts

How many indexes are too many?

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Index Maintenance

• Indexes have to maintained every time a row is the target of an


update, delete, or insert operation

• Workloads vary considerably!

• Index maintenance costs are generally linear


– There is no magical cutoff when it comes to the number of indexes

• Because Db2 for i is an integrated part of IBM i, maintenance


costs are often less than that of other database vendors

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Indexes Made Simple

Will the index


Create the index
pay for itself?
YES

NO / Not Sure

Is the index
Create the index
created as an MTI?
YES

NO

Are there many


Create the index
changes to the table?
NO

YES
More logic required

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Will the Index Pay for Itself?

• Creating the “right” indexes can eliminate some expensive


access methods:
– Table scan
– Hash table
– Index scan
• The overhead of maintaining the index is often much less than
the cost of these access methods in a frequently run query
• Customer example:

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Is the Index Created as an MTI?

• If the MTI was created, remember that the cost of creating the
index was amortized against the performance of running
without it.
– Index maintenance costs were not considered.

• If the index will be created anyway, creating it as a permanent


index has benefits:

– Prevents performance degradation after an IPL during the MTI’s


amortization

– More predictable performance for queries that don’t run as often and
may only sometimes result in MTI’s

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Are There Many Changes to the Table?

• Indexes have to maintained every time the table is the target of


an update, delete, insert, or merge operation

• Traditional OLTP applications generally write data one time and


read it thousands or millions of times

• There are no tools that directly report index maintenance costs


but there are indirect methods:

– Catalogs like SYSTABLESTAT contain counts of insert, update, delete,


and read operations

– The SQL Performance Monitor can be used to measure the amount of


time spent in update, delete, insert, and merge operations which provides
an upper limit of the index maintenance costs

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
More Logic Required

• If a table doesn’t change much, the maintenance costs for the


indexes will be minimal
• If the table changes more often, it is necessary to find a balance
between index maintenance and the improvement in query
performance including how often the query runs
– Most clients and most environments err on the side of too few indexes
• Sometimes a table will have significant changes during some
window of time:
– Event driven changes like archival, upgrade, or some periodic process
(e.g. month end)
– Starting with an empty table that will grow rapidly
• In this situation, it may be better to drop and recreate the
indexes when the changes are complete
– General guideline – Whenever Insert/Update/Delete/Merge operations
will affect more than 40 percent of the table rows

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Maximizing Index Value

• Understand the selectivity of the column values


– Indexes over more selective columns will have more performance benefit
– Here’s a sample query to determine selectivity of columns A, B, and C:

SELECT A, B, C, COUNT(*) FROM TABLEA


GROUP BY A, B, C ORDER BY 4 DESC

• Understand the cardinality for single and multiple columns


– Here’s some sample queries:

SELECT COUNT(DISTINCT X) FROM TABLEB

WITH MYCTE ( X, Y, XYCOUNT ) AS


( SELECT X, Y, COUNT(*) FROM TABLEB GROUP BY X, Y )
SELECT COUNT(*) FROM MYCTE

• If the column values are truly unique, specify UNIQUE on the


index as it aids in optimization

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Maximizing Index Value

• Create the indexes that benefit performance the most


– Frequently used
– Frequently advised
• Create indexes to tune a single query only if it is significant with
regard to the entire workload
• Think about rearranging the “order independent” keys if it makes
the index more useful to more queries
– An index with keys A, B, C can also be probed for A and A,B
– You may start with index advice but based on your knowledge of the
database and queries, you might rearrange the keys to B, A, C
– You might also add columns to facilitate index only access, for example
B, A, C, X

• Check which indexes are being used and which ones are
redundant

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Index Evaluator – Work with Indexes

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Index Evaluator – Work with Indexes…

Meta data for Indexes…

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Don’t Forget Change Control

• Use a naming convention when creating indexes


• Create indexes using an interface that allows you to save your
create index statements as documentation and to honor change
control practices

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Customer Example

• Table CUSTOMERS contains cust_number and cust_name


– There is an index over cust_number

• This statement takes several seconds to execute:


SELECT * FROM CUSTOMERS
WHERE cust_number=888
• Visual Explain looks like this:

• What’s wrong?

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Customer Example …

• The index was scanned because customer number was character in the
table but numeric in the front end user interface
• Implicit conversion works on some interfaces but the rules for blank padding
try to be tolerant
• The engine scanned for the customer number embedded within blanks
• Changing the front end to supply the value as character let the query run
many times faster

• The encoding of the key value in the index made a big difference to
performance!

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Effective Index Usage

• Db2 is unable to use indexes in some cases where key column


attributes do not match the comparison column or literal

• Avoid mismatches in column type, precision and scale

• Avoid comparing columns to derived values without a derived


index

• Match the data types and attributes of the column value and
search values (either host variables or constants)

• The optimizer is able to perform some mapping of attributes

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Effective Index Usage

• Avoid LIKE patterns that begin with a wildcard ( % or _ )

...WHERE lastname LIKE 'J%SON%‘


Can probe
leading
is better than characters
using index
...WHERE lastname LIKE '%SON'

Table scan

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Indexing Concepts

How can I minimize index costs?

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Best Practices – Index Creation

• Creating permanent or temporary indexes is resource intensive

• Db2 Symmetric Multiprocessing can be used to reduce the time


needed to create indexes

– It allows for parallel index builds including prefetch of data from storage
– The Db2 SMP feature must be installed (Option 26)
– There must be sufficient partition resources to allow parallel processing –
processor, disk, and memory. More resources means faster index
creation.
– Use the settings described in the SMP section of the workshop:
*MAX should be used sparingly if at all
*OPTIMIZE is the usual choice

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Index Strategy – Index Creation for EVI’s

• Use the optional clause on CREATE INDEX to specify how


many key values are expected:

– CREATE ENCODED VECTOR INDEX … WITH n DISTINCT VALUES

– This essentially determines if the encoded value is 1, 2, or 4 bytes

– There is no significant performance difference so it is best to “go big”


when you’re unsure of how many values will be required

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Index Maintenance

• For radix indexes with MAINT(*IMMED) and EVIs, maintenance


occurs when inserting, updating or deleting rows
• Index maintenance can cause a decrease in table I/O velocity
– Maintenance takes place synchronously as part of the row operation
INSERT INTO MY_TABLE...

Row data
Maintain indexes... ...then insert row data into table

MY_TABLE
IX1 IX2 IX3 IX4

Time

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Parallel Index Maintenance with Db2 SMP

• For radix indexes and EVIs, maintenance occurs in parallel


when inserting blocked data
INSERT INTO MY_TABLE...

Row data
Maintain indexes in parallel...
...then insert row data into table

IX1
IX2
IX3 MY_TABLE
IX4
Time

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Insert into a table with REUSEDLT(*YES)

– Insert requests will reuse deleted rows one row at a time (blocking turned off)
– Index maintenance takes place synchronously as part of the row operation

INSERT INTO MY_TABLE...

Maintain indexes...then insert single row data into table reusing deleted rows

Deleted rows

IX1 IX2 IX3 IX4 MY_TABLE

Time

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Insert into a table with REUSEDLT(*NO)

– Insert requests are inserted at the end and benefit from Db2 level row blocking
– Index maintenance occurs in parallel when inserting blocked data
INSERT INTO MY_TABLE...

Maintain indexes in parallel...then insert blocked data into table at the end

Deleted rows

IX1
IX2 MY_TABLE
IX3
IX4

Time

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Insert into a table with REUSEDLT(*NO)

• SQL tables are created with REUSEDLT(*YES) by default

• OVRDBF supports the REUSEDLT keyword

– Allows the REUSEDLT attribute of a table or PF to be changed


temporarily to *NO
– Useful for increasing I/O performance of batch inserts and writes

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i

Indexing Strategies

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Indexing Concepts

The goals of creating permanent indexes are:


1. Provide the optimizer the statistics needed to
understand the data, based on the query
2. Provide the optimizer implementation choices,
based on the selectivity of the query

Accurate statistics means accurate costing

Accurate costing means optimal query plan

Optimal query plans means best performance

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Data Access Methods and Strategies

Create indexes to give the optimizer and DB engine multiple


methods and strategies to choose from…

High

Response
Time Table Scan

Skip Seq

Low
Ix Probe

Few Many
Number of rows searched / accessed

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
The Process of Identifying Indexes

Proactive method
• Analyze the data model, application and SQL requests
• Database PK, UK, RI constraints are helpful

Reactive method
• Rely on optimizer feedback and actual implementation methods
• Rely on SQE’s ability to auto tune using temporary indexes

Understand the data being queried


• Column selectivity
• Column cardinality

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Indexing Strategy - Basic Approach

Radix Indexes
• Common local selection columns
Minimum
• Join columns
• Local selection columns + join columns
• Local selection columns + grouping columns
• Local selection columns + ordering columns
Advanced
Requires
knowledge of
Encoded Vector Indexes query
• Local selection column for index ANDing/ORing optimization
and data
• Join columns (star or snowflake schema) lifecycle
• Index only access
•DISTINCT, COUNT, COUNT DISTINCT, SUM()

Note: Columns used with equal conditions are first in key list

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Indexing Strategy - Examples

CUSTOMERS
custkey

ORDERS
orderkey
custkey
DATES partkey
datekey orderdate PARTS
shipdate partkey
suppkey SUPPLIERS
suppkey

What about constraints?


IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Art - The Perfect Index

• A "perfect" index is a radix index that is permanent, providing:


– Useful statistics to the optimizer
 Index contains appropriate selection, joining, grouping, ordering columns
 Applicable columns are the leading, contiguous keys
 Equal predicate columns first, one or more non-equal predicate columns last
– Multiple possible implementation methods
 Index ANDing / ORing with dynamic bitmaps
 Index probe
 Index scan
 Index only access
 Nested loop join via key
 Index grouping
 Index ordering
– Multi-key column access
 Identifies a very narrow range of values

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Art - The Perfect Index

• SELECTING
– Table scan
– Table scan or probe via bitmap or RRN list
– Index scan or probe

• JOINING
– Index scan or probe
Assume the query
– Hash table probe
is highly selective,
– Sorted list probe and using an index
• GROUPING is the best strategy
– Index scan or probe
– Hash table scan

• ORDERING
– Index scan or probe
– Sorted list scan

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Indexing Strategy - Example
SELECT d.year, d.week, s.supplier, o.orderkey, o.quantity, o.revenue_wo_tax
FROM ORDERS o
INNER JOIN SUPPLIERS s ON (o.suppkey = s.suppkey)
INNER JOIN DATES d ON (o.shipdate = d.datekey)
WHERE s.country = 'UNITED STATES'
AND d.week = 52
ORDER BY s.supplier;

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Indexing Strategy - Example
SELECT d.year, d.week, s.supplier, o.orderkey, o.quantity, o.revenue_wo_tax
FROM ORDERS o
INNER JOIN SUPPLIERS s ON (o.suppkey = s.suppkey)
INNER JOIN DATES d ON (o.shipdate = d.datekey)
WHERE s.country = 'UNITED STATES'
AND d.week = 52
ORDER BY s.supplier;

ORDERS SUPPLIERS DATES

week = 52
supplier= UNITED STATES
IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Indexing Strategy - Example
SELECT d.year, d.week, s.supplier, o.orderkey, o.quantity, o.revenue_wo_tax
FROM ORDERS o
INNER JOIN SUPPLIERS s ON (o.suppkey = s.suppkey)
INNER JOIN DATES d ON (o.shipdate = d.datekey)
WHERE s.country = 'UNITED STATES'
AND d.week = 52
ORDER BY s.supplier;

CREATE INDEX dates_idx3 ON dates (week);

CREATE INDEX suppliers_idx3 ON suppliers (country);

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Indexing Strategy - Example
SELECT d.year, d.week, s.supplier, o.orderkey, o.quantity, o.revenue_wo_tax
FROM ORDERS o
INNER JOIN SUPPLIERS s ON (o.suppkey = s.suppkey)
INNER JOIN DATES d ON (o.shipdate = d.datekey)
WHERE s.country = 'UNITED STATES'
AND d.week = 52 o.shipdate = d.datekey
ORDER BY s.supplier;

o.suppkey = s.suppkey

SUPPLIERS ORDERS DATES

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Indexing Strategy - Example
SELECT d.year, d.week, s.supplier, o.orderkey, o.quantity, o.revenue_wo_tax
FROM ORDERS o
INNER JOIN SUPPLIERS s ON (o.suppkey = s.suppkey)
INNER JOIN DATES d ON (o.shipdate = d.datekey)
WHERE s.country = 'UNITED STATES'
AND d.week = 52
ORDER BY s.supplier;

CREATE INDEX dates_idx3 ON dates (week);

CREATE INDEX suppliers_idx3 ON suppliers (country);

CREATE INDEX orders_idx4 ON orders (suppkey);

CREATE INDEX orders_idx5 ON orders (shipdate);

CREATE INDEX suppliers_idx4 ON suppliers (suppkey);

CREATE INDEX dates_idx4 ON dates (datekey);

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Indexing Strategy - Example
SELECT d.year, d.week, s.supplier, o.orderkey, o.quantity, o.revenue_wo_tax
FROM ORDERS o
INNER JOIN SUPPLIERS s ON (o.suppkey = s.suppkey)
INNER JOIN DATES d ON (o.shipdate = d.datekey)
WHERE s.country = 'UNITED STATES' s.supplier
AND d.week = 52
ORDER BY s.supplier;
o.shipdate=d.datekey

o.suppkey = s.suppkey

SUPPLIERS ORDERS DATES

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Indexing Strategy - Example
SELECT d.year, d.week, s.supplier, o.orderkey, o.quantity, o.revenue_wo_tax
FROM ORDERS o
INNER JOIN SUPPLIERS s ON (o.suppkey = s.suppkey)
INNER JOIN DATES d ON (o.shipdate = d.datekey)
WHERE s.country = 'UNITED STATES'
AND d.week = 52
ORDER BY s.supplier;

CREATE INDEX dates_idx3 ON dates (week);

CREATE INDEX suppliers_idx3 ON suppliers (country);

CREATE INDEX orders_idx4 ON orders (suppkey);

CREATE INDEX orders_idx5 ON orders (shipdate);

CREATE INDEX suppliers_idx4 ON suppliers (suppkey);

CREATE INDEX dates_idx4 ON dates (datekey);

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Indexing Strategy - Example
SELECT d.year, d.week, s.supplier, o.orderkey, o.quantity, o.revenue_wo_tax
FROM ORDERS o
INNER JOIN SUPPLIERS s ON (o.suppkey = s.suppkey)
INNER JOIN DATES d ON (o.shipdate = d.datekey)
WHERE s.country = 'UNITED STATES'
AND d.week = 52
ORDER BY s.supplier;

CREATE INDEX dates_idx3 ON dates (week);

CREATE INDEX suppliers_idx3 ON suppliers (country);

CREATE INDEX orders_idx4 ON orders (suppkey);

CREATE INDEX orders_idx5 ON orders (shipdate);

CREATE INDEX suppliers_idx4 ON suppliers (suppkey);

CREATE INDEX dates_idx4 ON dates (datekey);

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Indexing Strategy - Example
SELECT d.year, d.week, s.supplier, o.orderkey, o.quantity, o.revenue_wo_tax
FROM ORDERS o
INNER JOIN SUPPLIERS s ON (o.suppkey = s.suppkey)
INNER JOIN DATES d ON (o.shipdate = d.datekey)
WHERE s.country = 'UNITED STATES'
AND d.week = 52
ORDER BY s.supplier;

CREATE INDEX orders_idx4 ON orders (suppkey);

CREATE INDEX orders_idx5 ON orders (shipdate);

CREATE INDEX suppliers_idx4 ON suppliers (suppkey);

CREATE INDEX dates_idx4 ON dates (datekey);

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Indexing Strategy - Examples

-- Query 1
SELECT A.CUSTOMER_NO, A.ORDER_DATE, A.QUANTITY
FROM ORDERS A
WHERE A.CUSTOMER_NO = 0112358;

CREATE INDEX ORDERS_IX1 ON ORDERS (CUSTOMER_NO);

-- Query 2
SELECT A.CUSTOMER_NO, A.ORDER_DATE, A.QUANTITY
FROM ORDERS A
WHERE A.CUSTOMER_NO = 0112358
AND A.ITEM_ID = ‘ABC123’;

CREATE INDEX ORDERS_IX2 ON ORDERS (CUSTOMER_NO, ITEM_ID);

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Indexing Strategy - Examples

-- Query 3
SELECT A.CUSTOMER_NO, A.CUSTOMER, A.ORDER_DATE
FROM ORDERS A
WHERE A.CUSTOMER_NO IN (0112358, 1321345, 5891442)
AND A.ORDER_DATE > ‘2014/06/30’
ORDER BY A.ORDER_DATE;

CREATE INDEX ORDERS_IX3a ON ORDERS (CUSTOMER_NO, ORDER_DATE);


CREATE INDEX ORDERS_IX3b ON ORDERS (ORDER_DATE, CUSTOMER_NO);

-- Query 4
SELECT A.CUSTOMER_NO, A.CUSTOMER, A.ORDER_DATE
FROM ORDERS A
WHERE A.CUSTOMER_NO = 0112358
OR A.ORDER_DATE = ‘2014/06/30’;

CREATE INDEX ORDERS_IX4 ON ORDERS (CUSTOMER_NO);


CREATE ENCODED VECTOR INDEX ORDERS_EVI4 ON ORDERS (ORDER_DATE);

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Indexing Strategy - Examples

-- Query 5
SELECT *
FROM ORDERS A
WHERE UPPER(A.LASTNAME) = ‘MCLOUTH’
ORDER BY A.ORDERDATE DESC
FETCH FIRST 10 ROWS ONLY;

CREATE INDEX ORDERS_IX5 ON ORDERS


(UPPER(LASTNAME) AS u_lastname, ORDERDATE);

Bonus Question: Will this index be advised?

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Indexing Strategy - Examples
SELECT *
FROM ORDERS A
WHERE UPPER(A.LASTNAME) = ‘MCLOUTH’
ORDER BY A.ORDERDATE
FETCH FIRST 10 ROWS ONLY;

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Indexing Strategy - Examples

-- Query 6
SELECT A.CUSTOMER_NO, B.CUSTOMER, A.ORDER_DATE, A.QUANTITY
FROM ORDERS A,
CUSTOMERS B,
ITEMS C
WHERE A.CUSTKEY = B.CUSTKEY
AND A.ITEMKEY = C.ITEMKEY
AND A.CUSTOMER_NO = 0112358;

CREATE INDEX ORDERS_IX6a ON ORDERS (CUSTOMER_NO, CUSTKEY);


CREATE INDEX ORDERS_IX6b ON ORDERS (CUSTOMER_NO, ITEMKEY);
CREATE INDEX CUSTOMERS_IX6 ON CUSTOMERS (CUSTKEY);
CREATE INDEX ITEMS_IX6 ON ITEMS (ITEMKEY);

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Indexing Strategy - Examples

-- Query 7
SELECT A.CUSTOMER_NO, B.CUSTOMER, A.ORDER_DATE, A.QUANTITY
FROM ORDERS A
INNER JOIN CUSTOMERS B
ON A.CUSTKEY = B.CUSTKEY
INNER JOIN ITEMS C
ON A.ITEMKEY = C.ITEMKEY
WHERE B. CUSTOMER LIKE ‘CAIN%’;

CREATE INDEX ORDERS_IX7c ON ORDERS (CUSTKEY);


CREATE INDEX ORDERS_IX7i ON ORDERS (ITEMKEY);
CREATE INDEX CUSTOMERS_IX7cc ON CUSTOMERS (CUSTKEY, CUSTOMER);
CREATE INDEX CUSTOMERS_IX7c ON CUSTOMERS (CUSTOMER);
CREATE INDEX ITEMS_IX7 ON ITEMS (ITEMKEY);

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Tuning Subqueries

• It is often helpful to think of subqueries as separate queries for purposes of


creating the right indexes:

SELECT deal_date FROM analytics_input WHERE cust_id = 4 AND deal_date =


(SELECT MIN(deal_date) FROM analytics_input WHERE deal_date BETWEEN
(SELECT (MAX(import_datetime)) - 10 days FROM scores) AND
(SELECT (MAX(import_datetime)) FROM scores) )

CREATE INDEX ai_ix ON ai (Deal_Date ASC, Cust_Id ASC)

SELECT deal_date FROM ai WHERE cust_id = 4 AND deal_date = :H1


H1 = SELECT MIN(deal_date) FROM ai WHERE deal_date BETWEEN :H2 AND :H3
H2 = (SELECT (MAX(import_datetime)) - 10 days FROM scores)
H3 = (SELECT (MAX(import_datetime)) FROM scores)

Need to tune ONE Cursor at a time...

CREATE INDEX scores_ix ON scores (Import_DateTime DESC)

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Join via Multiple Key Column Probe

• Join is processed using index probe on equal selection


predicates just like local selection

SELECT EMPLOYEE.NAME, EMPLOYEE.TITLE


FROM EMPLOYEE,
SALES
WHERE EMPLOYEE.EMPNUM = 112358 local selection
AND EMPLOYEE.EMPNUM = SALES.EMPNUM join predicate
AND SALES.STORE = 13 local selection
AND SALES.DATE = '2004/03/01' local selection

• Index with three keys: STORE, DATE, and EMPNUM (in any
order) can be used to satisfy both the join and non-join selection
predicates on the table SALES in one query step.

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Indexing Strategy - Examples

If the optimizer feedback indicates:

Full table scan  Create an index on local selection columns

Temporary index  Create an index on join columns


 Create an index on grouping columns
 Create an index on ordering columns

Hash table  Create an index on join columns


 Create an index on grouping columns

“Perfect”, multiple key column radix indexes are usually best

Check the Db2 for i index advice

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i
Art - The Perfect Index

Remember: a given perfect index may only cover a small set of queries

Skip
sequential
with
RRN lists
Keyed access
with Temporary All
"perfect" data Queries
indexes structures

Temporary
indexes

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation
Db2 for i

LAB
Art of Perfect Indexes

IBM Systems Lab Services – January 2019 Copyright 2019 IBM Corporation

You might also like