10-Mar-2014 AXP Internal Page 1 of 5

A – Z of

Performance Tuning

10-Mar-2014 AXP Internal Page 2 of 5

Contents a) Respect PPI ........................................................................................................................................ 3

b) No Functions in JOIN conditions ....................................................................................................... 3

c) Avoid querying same table multiple times ....................................................................................... 3

d) Play with PI of volatile tables ............................................................................................................ 3

e) Collect Stats on Volatile table ........................................................................................................... 3

f) Look for grouping Join Conditions .................................................................................................... 3

g) Keep dropping volatile tables explicitly ............................................................................................ 3

h) Use Complete PI ................................................................................................................................ 3

i) Type of Joins ...................................................................................................................................... 3

j) Avoid unnecessary casting ................................................................................................................ 3

k) Avoid UDF.......................................................................................................................................... 3

l) Explore new functions ...................................................................................................................... 3

m) Try OLAP Functions ............................................................................................................................ 4

n) NO LOG for volatile tables ................................................................................................................ 4

o) Check column mapping in table ........................................................................................................ 4

p) Try MSR ............................................................................................................................................. 4

q) Consider using MVC for your table ................................................................................................... 4

r) Utilize existing AJI ............................................................................................................................. 4

s) Avoid IN clause in filter ..................................................................................................................... 4

t) Check DBQL Stats .............................................................................................................................. 4

u) UPD or (DEL & INS) ............................................................................................................................ 4

v) Same PI in Src & Tgt .......................................................................................................................... 4

w) Tune your GROUP BY clause .............................................................................................................. 4

x) Tune your UPDATE clause ................................................................................................................. 4

y) Stats on SI .......................................................................................................................................... 5

z) Explain the Explain ............................................................................................................................ 5

10-Mar-2014 AXP Internal Page 3 of 5

a) Respect PPI: If there is PPI created on a table, try to use it. If you are not using it in filter

condition, it will degrade the performance.

b) No Functions in conditions: Avoid using any function on joining columns or in filter

conditions. Eg: Applying TRIM on joining columns can increase the CPU consumption by 1000

AMPCPU.

c) Avoid querying same table multiple times: If required, create a volatile table with

required PI and fetch superset data from the base table. Now query, volatile table as per your

requirement. This method can save loads of AMPCPU especially when you are hitting big table

having PPI defined. And your query requires FTS.

d) Play with PI of volatile tables: Avoid keeping DATE column as PI. I am sure you can get

better PI candidate than date columns.

e) Collect Stats on Volatile table can save AMPCPU. If the volatile table contains UNIQUE

PI , then go for sample stats rather than full stats.

f) Look for grouping Join Conditions: You can see few instances where there is no need

of creating multiple volatile tables and same logic can be implemented in one step. Go ahead

and replace multiple volatile tables with one single table. Be cautious as multiple complex joins

may lead to extra AMPCPU.

g) Keep dropping volatile tables explicitly once it is no more required. Don’t wait for

complete proc to be over. This will free some spool space immediately and could prove to be

very helpful in avoiding No More Spool Space error.

h) Use Complete PI: If PI is composite key, then try to look into data in the Source Table

especially values in PI columns. If possible, try to include complete PI to avoid re-distribution.

i) Type of Joins: If you don’t have to extend NULL values replace LEFT OUTER JOIN with INNER

JOIN. This will enhance performance greatly.

j) Avoid unnecessary casting for DATE columns. Once defined as DATE, you can compare

date columns against each other even when they are in different format. Internally, DATE is

stored as INTEGER. CAST is required mainly when you have to compare VARCHAR value as DATE.

k) Avoid UDF if you can achieve something directly in TERADATA.

l) Explore new functions available in Teradata 14 to make your life easy. Avoid OREPLACE,

OTRANSLATE, UDF for DATE conversions if possible. Try REGEX, it can save good amount of

AMPCPU.

10-Mar-2014 AXP Internal Page 4 of 5

m) Try OLAP Functions: Check if replacing co-related sub query with OLAP function may

result in AMPCPU saving. Also, it is advisable to

n) NO LOG for volatile tables:Create volatile tables with NO LOG option.

o) Check column mapping in table:Try to relate value of PI or PPI column with other

available column. This can help in leveraging PI or PPI. Eg: PPI is on feed_key and as_of_dt value

is available. If there is one-one mapping between as_of_dt and feed_key I can replace as_of_dt

with feed_key in query to use PPI.

p) Try MSR: If same target table is loaded multiple times, try MSR for several sections. This will

speed the final MERGE step into target table and you may see good CPU gain.

q) Consider using MVC for your table. If the table size is huge then applying MVC may

reduce SPOOL Size and may improve the performance.

r) Utilize existing AJI: Check if there is any AJI available on the table and you can tune your

query to use it.

s) Avoid IN clause in filter conditions especially when there can be huge number of values.

Better option can be to insert such values in a volatile table and use volatile table with INNER

JOIN in the main query.

t) Check DBQL Stats: Keep your performance stats handy. Target the most AMPCPU

consuming query first.

u) UPD or (DEL & INS): Sometimes replacing UPDATE with DEL & INS can save good number

of AMPCPU. Check if this holds good for your query.

v) Same PI in Src & Tgt: PI column not only help in retrieving values efficiently , it also helps

in saving data into disk efficiently. So consider this point also while choosing PI column. If Source

& Target table share same PI columns, you can expect very efficient data dump from Source to

Target.

w) Tune your GROUP BY clause: Need not include static values in group by clause. Eg: If I

am doing aggregation for CUST_XREF_ID = 20440314016, then I need not do GROUP BY

CUST_XREF_ID. I can put MAX(CUST_XREF_ID) in my select clause to avoid this. This way you can

save some AMPCPU and may see better query performance.

x) Tune your UPDATE clause: Do not write UPDATE clause with just SET condition and no

WHERE condition. Even if the Target/Source has just one row, add WHERE clause for PI column.

We don’t update PI column values.

10-Mar-2014 AXP Internal Page 5 of 5

y) Stats on SI: Secondary Indexes without proper STATS can be of little or no help. Check for

STATS status of the table. This holds good for partitions too.

z) Explain the Explain: Check for EXPLAIN plan to see how exactly Teradata will be executing

the query. Try to understand basic keywords in Explain Plan like confidence level, join strategy

used, re-distribution happening or not.