A Z of

Performance Tuning

10-Mar-2014

AXP Internal

Page 1 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 2 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. Dont 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 dont 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 3 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 dont update PI column values.

10-Mar-2014

AXP Internal

Page 4 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.

10-Mar-2014

AXP Internal

Page 5 of 5