1. DB-2: Tuning OpenEdge® SQL
Boosting your SQL application performance
Steve Pittman
Software Architect

2. Agenda Boosting your SQL application performance
Your application and sql
Your application executing in the sql engine
Tuning and best practices
Questions
Please save your questions until end of session.
Your question may be answered in a slide still to come.
DB-2: Tuning OpenEdge SQL

3. Crystal Reports - ODBC
An ODBC application
DB-2: Tuning OpenEdge SQL

4. OpenEdge DB Navigator - JDBC
DB-2: Tuning OpenEdge SQL

5. Statements and Result Sets
Prepare, execute, fetch cycle
Result Set
For select statements
Sql statement may be hidden by tools
Select onum, name, cnum … from pub.customer c, pub.orders o where c.custnum = o.custnum
SQL Server
Db update statements – insert, delete, update – omit result set.
Doing prepare once, and executing many times can save network roundtrips.
Manual prepare not needed, as of OE 10, in order to save query compile time when repetitively executing a query (or similar forms of query).
Manual prepare does have benefit of less network message traffic, since drivers do hidden prepare for each executed statement.
Database
Crystal (ODBC)
8765 General Motors Toyota Mfg, Inc Home Depot, Inc. 274 … … …
DB-2: Tuning OpenEdge SQL

6. OpenEdge 10.1A Communications
Performance
Version compatibility
JTA
Type 4 JDBC driver
Query timeout (in OE 10.1A01)
“set pro_connect query_timeout <n seconds>”
OpenEdge SQL Server
Rpc type communications protocol ( rpc = remote procedure call). 1 message to server for each batch of output rows.
OE 101a ODBC driver is also a “wire protocol” driver, which does not need procli92.dll. Fewer pieces to install.
JTA – Java Transaction Architeture – part of J2EE.
Performance – fewer round-trip messages in 10.1A.
Compatibity – works with OE 10.1A forward. Incompatible with 10.0B.
Query timeout – both odbc, jdbc. Gives failure status and message back to application. No support yet for async cancel. Unit = 1 second.
Note that communication protocol is common to all clients (ODBC, JDBC, etc.).
Database
ODBC JDBC
DB-2: Tuning OpenEdge SQL

7. Transactions and Locks
How to get fewer locks
Repeatable Read
Read Committed – default
“WITH (NOLOCK)” query hint
Read Uncommitted
Change via ODBC/JDBC API
ODBC DSN Advanced option
JDBC setTransactionIsolation()
To see locks, use PROMON (locking screens).
Isolation level drives locking.
Isolation level cannot be changed in middle of transaction.
Lock hint is in 9.1E03, 10.1A01.
Syntax: SELECT <column> FROM <table> WITH (NOLOCK)
NOLOCK hint works on specific table.
DB-2: Tuning OpenEdge SQL

8. Views Data independence and transformation Arrays Security
10.1A select branch,month[1], month[2]…
10.0B select branch,pro_element(month,1,1)
Security
Base table indexes
PUB.custview
10.1A array type gives easy use of native datatype of array element, and natural, standard syntax (same as 4GL).
Especially valuable for array of numeric datatype (decimal, integer)/
10.0B (for pro_element() example) really means 10.0B and all earlier versions.
PUB.cust
DB-2: Tuning OpenEdge SQL

9. Agenda Boosting your SQL application performance
Your application and sql
Your application executing in the sql engine
Tuning and best practices
Questions
DB-2: Tuning OpenEdge SQL

10. Building Blocks for execution
Project
Sort
Join
Restrict
Index scan
Table scan
SalesHistory
DB-2: Tuning OpenEdge SQL

11. Building Blocks in a Query Plan
Sort
Project
Join
Restrict
Index scan
Table scan
Tuning – goal is to have data pipes as thin as possible.
SQL goal is to build best query plan.
Tools to display the query plan are not this pretty – no GUI available. Will see this later.
SalesHistory
DB-2: Tuning OpenEdge SQL

12. Building the query plan
sql statement
schema
sql statistics
SQL Optimizer
U s e r
Analogy - compiler optimization.
Building the query plan is driven by your statement’s components.
SQL Runtime
Query plan
DB-2: Tuning OpenEdge SQL

13. Building the query plan
Cost based optimization
Optimization model
Figure out all feasible ways to do a step
Figure out the costs of each way
Choose way with smallest cost
Optimize from the bottom up
Optimize table access
Optimize joins
Optimize result set
What cost is
“way” = method
Cost = work = time.
Result set – optimize Project, Sort, etc.
Building the query plan is driven by your statement’s components.
[Pause a second for everyone to read the text.]
DB-2: Tuning OpenEdge SQL

14. What is the cost? Rule based mode When no statistics exist
Table and index metadata
number of key components used
unique and non-unique indexes
Default selectivity per comparison operator
“=” is .04, “between” is .1, etc.
Heuristics – rules of thumb
All tables have same number of rows
Cost equations
Define all terms - statistics, cardinality.
By default, no statistics exist.
Rules assume even data distribution across tables (~same #rows) and within tables (no skew).
Sweet spot where this works well – db with same sized tables.
DB-2: Tuning OpenEdge SQL

15. What is the cost? Database without statistics ABC Corp DB Customers
Orders
SalesHist
Distributors
Parts
Suppliers
OrderLines
Employees
DB-2: Tuning OpenEdge SQL

16. What is the cost? Database with statistics ABC Corp DB SalesHist
OrderLines
Customers
Distributors
Orders
Big = costly to access a large percentage of data
Parts
Employees
Suppliers
DB-2: Tuning OpenEdge SQL

17. What is the cost? Statistics based mode – basic statistics
Table statistics – number of rows
Column statistics - data distribution++
Get column selectivity for predicate
% of table’s data returned
Combining multiple columns selectivities
Best for range operators(“between”, etc.), especially in Version 9
Cost equations use statistics
By default, no statistics exist.
Basic statistics = table statistics + column statistics.
Cost equations use counts (rows, #unique) from table statistics, column statistics.
Cost equations use selectivity from column statistics.
[Do not read the individual bullets of this slide.]
[Pause a second for everyone to read the text.]
DB-2: Tuning OpenEdge SQL

18. What is the cost? Without index statistics
Counts number of values for components of index
ABC Corp DB
SalesHist
Cust_idx
Yr_idx
This is a real-worlld test case, from an actual customer.
Each index has same number of components (one in this specific case).
DB-2: Tuning OpenEdge SQL

19. What is the cost? With index statistics
Counts number of unique values for components of index
ABC Corp DB
SalesHist
Cust_idx
Yr_idx
This is a real-worlld test case, from an actual customer.
Each index has same number of components (one in this specific case).
Index statistics highpoints
Count of number of unique values for components of index
Gives most precise estimate of number of rows satisfying “=” and “in” operators
Accounts for correlation between components of an index key
Can accurately model
very, very low selectivity
very high selectivity
DB-2: Tuning OpenEdge SQL

20. What is the cost? Index statistics
Count of number of unique values for components of index
Gives most precise estimate of number of rows satisfying “=” and “in” operators
Accounts for correlation between components of an index key
Can accurately model
very, very low selectivity
very high selectivity
Counts are for prefixes of the index.
Selectivity = amount (fraction) of data returned when index used with suitable predicates.
[Pause a second for everyone to read the text.]
DB-2: Tuning OpenEdge SQL

21. More on index statistics
OpenEdge 10 vs. Version 9
OpenEdge 10: counts for all prefixes
Prefix - key components 1 to n
Exact count for prefix
V9: counts for
First key component, last 3 prefixes
V9 “interpolation” for prefixes without counts
V9 interpolation does estimate via “straight line” between first 2 counts.
DB-2: Tuning OpenEdge SQL

22. Example – cost via index statistics
#comps
count
Xconsumer_id 1 90 2
10K 3
20K 4
300K 5
800K 6 1M
index statistics
Cost = (1M/ 800K )rows * IO cost per row
select …
from Sales_History
where terr_id = ‘abc’
and subt_id = 1
and zip = ‘05601’
and demo_cat = ‘xyz’
and cust_stat = ‘M’;
5 components specified
DB-2: Tuning OpenEdge SQL

23. Optimizing join execution
Or, What gets optimized
Join order
Join methods
index join (= augmented nested loop)
nested loop
dynamic index (looks like index join)
Hash join when low data volume
Index join when larger data volume
DB-2: Tuning OpenEdge SQL

24. What optimizer does for join order
Consider many possible join orders
Choose least cost order
Estimated cost = number of rows joined
Joining small amount of data to larger amount of data is usually least cost
Cost estimation drivers
Table statistics
Index statistics
OpenEdge 10 employs much more powerful join order exploration
Important point: table and index statistics will give sql the best join cost estimation.
V9.1E has most, but not all, of 100b join order optimization changes.
DB-2: Tuning OpenEdge SQL

25. Sql statement execution
10.1A Temp data handling for sorting (and dynamic indexes)
Performance results
40X faster for 900K rows
3.5X faster for 43K rows
New algorithms
More powerful space use
Aggressive use of memory
New Storage Manager
Type 2 area (like OpenEdge ProDataSets)
New internal storage mgmt.
New key form and key compare methods.
New merge methods.
New compact record format.
Terricic performance measurements.
DB-2: Tuning OpenEdge SQL

26. Temp data performance in 10.1A
10.1A Temp data handling – a scalable solution
Scenario – small server, complex queries
Each curve based on real-world customer db and application.
Huge (case 1) – 80 min. to 2 min.
Prol (case 2) – 1.9M rows – 165 min. to 14 min.
Some cases are grouping intensive, some are sort intensive, some use dynamic indexes intensively.
Cases 6-8 = aq084, aq188, aq157 (times in seconds).
Lines at bottom have same relative improvement (X3) as top – just do not show as dramatically.
DB-2: Tuning OpenEdge SQL

27. Temp data performance in 10.1A
10.1A Temp data handling – a scalable solution
Scenario – large server, simple queries
Each curve based on real-world customer db and application. These data samples selected from several others as good representatives.
Some cases are grouping intensive, some are sort intensive, some use dynamic indexes intensively.
Cases 6-8 = aq084, aq188, aq157 (times in seconds).
Case9 = q06 from dwhoe-timings (time in seconds). These done on smaller server configuration.
Lines at bottom have same relative improvement (X3) as top – just do not show as dramatically.
DB-2: Tuning OpenEdge SQL

28. Agenda Boosting your SQL application performance
Your application and sql
Your application executing in the sql engine
Tuning and best practices
Questions
DB-2: Tuning OpenEdge SQL

29. What to tune Tune your sql statements Tune your sql server
Possible problems
Finding problems
Special situations
Tune your sql server
Sql Statistics
Releases
Tune here
OpenEdge SQL Server
Sql client
Database
DB-2: Tuning OpenEdge SQL

30. Tuning your sql server Create, or update, sql statistics
Move to newer Open Edge release
OpenEdge 10.1A is better than 10.0B
OpenEdge 10.0B is better than Version 9.1E
Version 9.1E is better than 9.1D
Latest Service Pack
OpenEdge 10 service packs
Version 9.1 service packs
OpenEdge 10.1A temp data startup parameters
DB-2: Tuning OpenEdge SQL

31. Updating sql statistics
Default statistics
“update statistics [for <table name>];”
Best statistics
“update table statistics and index statistics and column statistics [for <table name>];”
Reads all of each index for all tables, or for one table
May be resource intensive
Example - 4.5G customer db, 600 tables, 4500 indexes
Index stats runtime = 25 CPU minutes
Index statistics drive best join optimizations.
Note that UPDATE STATISTICS is online.
[Pause a second for everyone to read the text.]
DB-2: Tuning OpenEdge SQL

32. Updating statistics Database with statistics ABC Corp DB
Update table, index, column stats for all tables
SalesHist
OrderLines
Customers
25% change
Distributors
Orders
Update table, index stats for volatile tables
Note that Update Statistics is an online operation.
Must be DBA to update statistics.
To get “info” on 25% change:
- use table statistics which db can be configured, at startup, to track:
- define range of tables to track with –basetable n, -tablerangesize m
- start and run server
- look at VST _TableStat writes – create/delete/update
Can use db “high water mark” to get sense of gross level of db activity. Can see this in PROMON.
25% guideline is a guideline, not an ironclad rule. Derives from notion that 25% change to volatile tables means that relationships have changed in way that will effect cost estimation.
Parts
Employees
Suppliers
DB-2: Tuning OpenEdge SQL

33. 10.1A Temp data startup parameters
Sorting and Dynamic indexes
-T directory-name -t
-Bt number
-SQLTempBuff number
-Bt – also influences degree of merge, and can greatly affect sort performance.
All parameters apply to all connections for server.
-SQLTempBuff – sort buffer size, hash index size (K bytes).
Default – 1000 (1M)
-Bt – number of Storage Manager page buffers.
Default – 32
8K bytes per buffer
-T – directory for disk space allocation
-t – whether disk file is visible
DB-2: Tuning OpenEdge SQL

34. 10.1A Temp data startup parameters
-SQLTempBuff 2000
-Bt 4
data1
buf1
data2
buf2
data3
buf3
sort run
buffer
sort
data4
buf4
merge DB
data sorted
-SQLTempBuff – default K units (== 1M). Unit = 1K.
-Bt – default 32 8K buffers. Unit = 1 buffer.
-Bt – also influences degree of merge, and can greatly affect sort performance.
All parameters apply to all connections for server.
Temp db
DB-2: Tuning OpenEdge SQL

35. 10.1A Temp data startup parameters
Performance recommendations
Large file system cache
-SQLTempBuff has little effect
-Bt – double it to 64 if more than 24M data
Will drive down number of merge passes
Small file system cache
-SQLTempBuff may help
-Bt – same as above
Mid-range sort volume (1.1M – 4M)
-SQLTempBuff – same size as sorted data
Defaults are pretty good for a wide range of circumstances.
Large file system cache functions as super-extended values for these parameters.
-SQLTempBuff – specify in units of 1K pages
[Pause a second for everyone to read the text.]
DB-2: Tuning OpenEdge SQL

36. Tuning your sql statements
Possible problems and remedies
Join relationships not completely expressed in predicates
Remedy - more, better join predicates on sql statements
Every pair of tables with a relationship should have a predicate giving that relation:
This slide transitions back to the “tuning your statements” sub-topic!
This example is overly simplistic but it makes the point!!
Example also shows how can specify constant for non-leading index component to get first row only in joining data.
This somewhat resembles a 4GL FOR FIRST .
“select … from pub.orders O, pub.orderlines L where O.onum = L.onum and L.linenum = 1”
DB-2: Tuning OpenEdge SQL

37. Tuning your sql statements
Possible problems and remedies - more
Leading keys of indexes not specified
Remedy - give predicates on leading keys
Predicates best for index use not used
Best: “=”, IN
Near best: BETWEEN
Good: >, >=, <, <=
Note - OR can disable index optimizations
This example is overly simplistic but it makes the point!!
DB-2: Tuning OpenEdge SQL

38. Tuning communication for your statement
Drives number of messages for Result Set
ODBC – Fetch Array Size
DSN option in ODBC Data Source Administrator
JDBC - setFetchSize( )
SQL Server
JDBC api is 10.1A new feature.
Goal is to incur fewer round trips between client and server.
“round trip” – 1 Fetch message from client to server, 1 Result Set array from server to client.
Fetch array size unit is the result set row.
No upper limit except available memory on server for required data buffes for each column instance.
Server’s column buffers are sized to sqlwidth, to hold max possible size.
Experiment with typical result sets to determine benefit.
Can also use Prepare to drive down number of roundtrips, when statement can be prepared once and executed many times.
Database
Crystal (ODBC)JDBC
50 rows of data ……… ………… …………
500 rows of data ……… ………… ……………… ……… ………… ……………… ……… ………… ………………
DB-2: Tuning OpenEdge SQL

39. Tuning your sql statements
Finding the problem
Time, Inspect, Investigate, Change
To investigate: sql virtual system table for query plan
Access query plan for sql statement executed
Query plan data will show:
Tables, indexes
Joins
Predicates, join order
Note: only your query plans available
Must be DBA or have DBA grant privileges to you
Time – do simple timing of data access requests.
Inspect – see sql statement executed.
Investigate – query plan
DB-2: Tuning OpenEdge SQL

40. Getting the query plan Basic form Simplify with views
select substring("_Description",1,80)
from pub."_Sql_Qplan“ where "_Pnumber" = (select max("_Pnumber")
from pub."_Sql_Qplan" where "_Ptype" > 0 );
Simplify with views
See Appendix for how to define view.
select * from my_Qplan;
DB-2: Tuning OpenEdge SQL

41. Getting the query plan Get your sql statement
Crystal Reports:
Database menu
“Show SQL query …”
Copy into a sql query tool
DB Navigator, WinSQL, DB Visualizer, SQL Explorer
Run your statement
Run the sql statement to get query plan
DB-2: Tuning OpenEdge SQL

42. Query plan – what to look for
Simple single table select
“select … from pub.customer where custnum between 1000 and 1100”
SELECT COMMAND.
PROJECT [66] (
| PROJECT [64] (
| | PUB.CUSTOMER. [0](
| | | INDEX SCAN OF (
| | | | CustNum,
| | | | | (PUB.CUSTOMER.CustNum)
between (1000,1100))
table
index
Simple indentation to show tree form.
Find and consider the highlights shown.
Ignore the Project operations, and other less important operations.
index keys, predicates
DB-2: Tuning OpenEdge SQL

43. Query plan – what to look for
Two table select with 2 join keys
join
JOIN [13][AUG_NESTED_LOOP-JOIN]
| | PUB.O. [2](
| | | INDEX SCAN OF (
| | | | CustOrder,
| | | | | (PUB.O.CustNum) between (1,3))
| (PEXPR1, PEXPR3) = (PEXPR5, PEXPR6)
| -- above defines ANL left side keys
<relop> right side keys
| | | PUB.L. [3](
| | | | INDEX SCAN OF (
| | | | | orderline,
| | | | | |(PUB.L.Ordernum, PUB.L.Linenum)
= (null,null))
joining table
join predicates
joining table
Simplified from a real query.
Find and consider the highlights shown.
Ignore the Project operations, and other less important operations.
join index
DB-2: Tuning OpenEdge SQL

44. Query plan – what to look for
Four table join
| JOIN [15][AUG_NESTED_LOOP-JOIN]
| | JOIN [13][AUG_NESTED_LOOP-JOIN
| | | JOIN [11][AUG_NESTED_LOOP-JOIN]
| | | | PROJECT [66] (
| | | | | PUB.O. [10](
| | | | | | INDEX SCAN OF (
| | | | | | | CustOrder,
| | | | | | | | (PUB.O.CustNum) …
| | | | PROJECT [61] (
| | | | | PUB.C. [9](
| | | | | | | CustNum,
| | | | | | | |(PUB.C.CustNum) = …
| | | PROJECT [72] (
| | | | PUB.L. [12](
| | | | | INDEX SCAN OF (
| | | | | | orderline,
| | | | | | | (PUB.L.Ordernum,
PUB.L.Linenum)
= (null,1))
Order of joins
2 tables for a join
Drastically simplified from a real query.
Find and consider the highlights shown.
Ignore the Project operations, and other less important operations.
Note that the 2 inputs to a join may be a table and another join, or 2 other joins.
But in all cases, most important pattern to see is the order in which tables are being joined.
DB-2: Tuning OpenEdge SQL

45. Tuning your sql statements
Hints and tips
Use NOEXECUTE to evaluate
Test, inspect query plan, repeat until done
OpenEdge 10 and Progress Version 9
NOEXECUTE is 1 word
Example:
Experiment with alternate queries without cost of query execution!
select … from Table1 t1, Table2 t2
where t1.key = 5 and t1.key = t2.key
NOEXECUTE;
DB-2: Tuning OpenEdge SQL

46. Tuning your sql statements
Hints and tips
Forcing the join order
NO REORDER phrase at end of FROM clause
When all else fails!
Example:
Index hints
Use carefully - not deterministic
select …
from Table1, Table2, Table3 {NO REORDER}
where … ;
DB-2: Tuning OpenEdge SQL

47. Choose index if it is an eligible candidate
Index hint
Syntax
WITH ( INDEX ( <index name> ) )
Choose index if it is an eligible candidate
select …
from … PUB.pt_mstr pt_mstr with (index(pt_type)), …
where idh_hist.idh_part = pt_mstr.pt_part
and pt_mstr.pt_part_type = ‘FG’
and …
DB-2: Tuning OpenEdge SQL

48. In summary What the sql server does for your application
What the sql server does with your application
Tuning to make the server do what you want
Tuning to make your statements do what you want
DB-2: Tuning OpenEdge SQL

49. Relevant Exchange Sessions
DB-31: Understanding and Leveraging the Latest ODBC and JDBC Technology
Monday, 5 June, 3:15pm - 4:30pm
DB-7: OpenEdge Db Performance Tuning
Tuesday, 6 June, 2:15pm – 3:15pm
INNOV-12: OpenEdge Database Roadmap
Wednesday, 7 June, 9:00am - 10:00am
DB-11: OpenEdge Data Management Info Exchange
Wednesday, 7 June, 10:15am – 11:15am
DB-2: Tuning OpenEdge SQL

50. Questions?
DB-2: Tuning OpenEdge SQL

51. Online resources White paper on query optimizer
PSDN Library, Whitepapers, Progress RDBMS and SQL92
Collection of white papers at PSDN library
ODBC, JDBC Configuration
Locking, Index statistics, Server configuration
Visit new URL at “to be announced”
Online documentation at Progress web site
Knowledge base
21676, 20007, query plan
Exchange 2005 presentation
DB-16 JTA Transactions in the Database
DB-2: Tuning OpenEdge SQL

52. Thank you for your time!
DB-2: Tuning OpenEdge SQL

53. DB-2: Tuning OpenEdge SQL

54. Appendix – query plan view 1
-- to show all of query plan for most recent statement.
create view qplan_full as
select *
from pub."_Sql_Qplan"
where "_Pnumber" = (select max( "_Pnumber" )
from pub."_Sql_Qplan"
where "_Ptype" > 0 );
grant select on qplan_full to public;
create public synonym qplan_full for qplan_full ;
commit work;
DB-2: Tuning OpenEdge SQL

55. Appendix – query plan view 2
-- try to show just the highlights of query plan, omitting data specifics.
create view qplan_no_data as
select *
from pub."_Sql_Qplan"
where "_Pnumber" = (select max( "_Pnumber" )
where "_Ptype" > 0 )
and "_Description" not like '% , %'
and "_Description" not like '%, PEXPR%'
and "_Description" not like '%, substr%'
and "_Description" not like '%| )'
and "_Description" not like '%| )%'
and "_Description" not like '%| ,%'
and "_Description" not like '%callback%'
and "_Description" not like '%col id# %'
and "_Description" not like
and "_Description" not like '%terminate%'
and ("_Description" not like '% )' or
"_Description" like '%OJ Predicate%' ) ;
grant select on qplan_no_data to public;
create public synonym qplan_no_data for qplan_no_data ;
commit work;
DB-2: Tuning OpenEdge SQL

56. Appendix – query plan view definition
Table "_Sql_Qplan" exists as if it had been created by the sql syntax below
The definition of this sql virtual system table is not visible to client tools such as Crystal Reports
create table "_Sql_Qplan" (
"_Pnumber" integer not null, plan number.
"_Ptype" integer not null, plan type.
"_Dtype" integer not null, description type.
"_Description" varchar(255) not null, -- description line.
"_Dseq" integer not null description sequence#. );
DB-2: Tuning OpenEdge SQL

57. Updating sql statistics
Specific categories of statistics
Table statistics
“update table statistics [for <table name>];”
Column statistics
“update [all] column statistics [for <table name>];”
Index statistics
“update index statistics [for <table name>];”
reads all of each index for 1, or all, tables.
DB-2: Tuning OpenEdge SQL

58. Updating sql statistics
The who and the when
Must be DBA
When to do
Do it once
For all tables
Repeat yearly for all tables
Repeat selectively for a few tables
Volatile tables
Capture the average
Relationships between tables or indexes change
The When question is frequently asked.
Let the data drive the solution.
DB-2: Tuning OpenEdge SQL

59. Schemas PUB schema Default schema
Inter-operability with 4GL
PUB schema
Schema for inter-operability with 4GL
Default schema
10.1A – settable in connection string
Earlier - Set schema ‘pub’
SQL Server
Schema - set of tables with common owner
PUB
SMITH
Sql client
JONES
DB-2: Tuning OpenEdge SQL

60. Tuning your sql statements
General sql best practices - more
Inner join or Outer join
Outer join - more expensive
Join relationships in ON clause
Including single column predicates
Auto-commit - expensive
Cursor based updates - slow (currently)
DB-2: Tuning OpenEdge SQL

61. Tuning your sql statements
General sql best practices
Predicates are good
More is always better
Specify exact set of needed columns in result set
sql engine may be able to avoid reading data page when only key columns used
Sort and group on the server
Sort, group by – especially in 10.1A
DB-2: Tuning OpenEdge SQL

62. Tuning your sql statements
Possible problems and remedies - more
Several similar indexes not distinguished as expected
Remedy: index statistics
Index 1 – comp, div, city, custid
Index 2 – comp, div, city, po_num
This example is overly simplistic but it makes the point!!
Refer back to earlier index statistics visual diagram, and how it showed statistics giving exactly how many rows a set of keys would return.
select …
where comp = ‘a’ and div = ‘b’ and city = ‘c’
and custid = 123
and po_num = 98765
DB-2: Tuning OpenEdge SQL

63. Query plan – what to look for
Larger and more complex plan
Two table select with 2 join keys
-- 2 key join
select o.ordernum, o.orderdate, l.itemnum
from pub.order o, pub.orderline l
where o.custnum between 1 and 3
and o.ordernum = l.ordernum
and o.custnum = l.linenum;
Illustrate example query behind 2 join query plan slide.
DB-2: Tuning OpenEdge SQL

64. Query plan – what to look for
Larger and more complex plan
Four table join
select c.custnum, o.ordernum, o.OrderDate,
i.Itemnum, l.price
from pub.customer c,
pub.order o,
pub.orderline l,
pub.item i
where c.custnum = o.custnum
and o.ordernum = l.ordernum
and l.linenum = 1
and l.itemnum = i.itemnum
and c.custnum between 1 and 6
order by 1,3
DB-2: Tuning OpenEdge SQL