When the warehouse runs, but the workload does not
A query that finished yesterday now consumes the batch window. One AMP runs out of spool while others have capacity. A statistics refresh changes the plan, or a busy reporting period exposes contention that individual query tests never showed.
We work with Teradata DBAs, data engineers and platform owners to separate SQL problems from distribution, statistics, workload and capacity issues. The first deliverable is a defensible diagnosis and a prioritised set of changes.
What we investigate
SQL and execution plans
Review expensive joins, filters, aggregations, intermediate results and repeated transformations. Compare EXPLAIN plans with recorded execution behaviour, and test rewrites against the original business results.
Spool usage and data skew
Check whether spool pressure comes from intermediate row volume, uneven AMP distribution, concurrency or unsuitable access paths. Review primary-index choices and data distribution before recommending more space.
Statistics and optimizer estimates
Identify missing, stale or unhelpful statistics for the workload under review. Compare estimated and observed cardinalities where the available diagnostics allow it, and plan collection frequency around data changes.
Batch windows and workload contention
Use DBQL and the monitoring data available in your environment to distinguish execution time from queueing, blocking and competing workloads. Review dependencies and scheduling as well as individual statements.
How a tuning engagement works
- Agree a baseline. Select representative queries and a measurement window. Record data volumes, elapsed time, CPU, I/O, spool and concurrency where available. Define the operational target and the correctness checks.
- Diagnose and prioritise. Inspect SQL, DDL, plans, statistics and query logs. Rank changes by expected impact, implementation effort and regression risk.
- Test controlled changes. Compare one change at a time where practical. Reconcile outputs and repeat measurements under comparable conditions, including the busy periods that matter to your users.
- Roll out and hand over. Agree deployment and rollback steps with your team. Provide the changed SQL or configuration recommendations, measurement evidence and a maintenance plan.
You receive: a workload baseline, findings with supporting evidence, prioritised recommendations, the agreed tested changes, and a record of the before-and-after results. The exact deliverables depend on the scope and access agreed at the start.
What we need from your team
Start with a short description of the problem, your Teradata version and the affected process. For detailed analysis, useful inputs include representative SQL, table definitions, EXPLAIN output, statistics information and an agreed DBQL extract. Your team can supply approved extracts where direct access is unavailable.
Do not include passwords or production data in the initial enquiry. We agree access, confidentiality and data handling before analysis begins.
Technical depth you can inspect
Our published guides explain the same issues that arise during delivery:
- Diagnosing Teradata spool-space errors
- Using DBQL to understand query workloads
- SET and MULTISET behaviour and performance
- Teradata Query Performance Tuning book
Review our published delivery experience and the engineers behind DWHPro. Results from another workload are context, not a promise for yours.
Start with a defined problem
A free 30-minute discovery call helps establish whether you need a focused query investigation, a batch-workload review or a broader platform diagnostic. We agree the workload, deliverables, access requirements and price before analysis starts. Implementation and ongoing support are scoped explicitly.
See the wider service and engagement options. If you are weighing tuning against migration, we can compare the options using your workload and constraints; see our Teradata-to-Snowflake migration service.
Common questions
Can you guarantee a percentage improvement?
No percentage applies to every workload. We establish a baseline and agree measurable acceptance criteria for the selected scope. A finding may point to data growth or capacity limits as well as SQL changes.
Can you investigate without production access?
We can begin with approved SQL, DDL, plans and diagnostic extracts. Recommendations that depend on runtime behaviour still need validation in a representative environment.
Will you change production settings immediately?
Changes follow your deployment and approval process. Tests, correctness checks and rollback conditions are agreed before production rollout.
Tell us what is slowing you down
Describe the slow query, spool error or batch deadline. Include the current and required runtime if known. A short explanation is enough to begin.
The delivery team and your platform decision
DWHPro is led by Roland Wenzlofsky and works with a network of specialists. We agree the proposed team, responsibilities and availability for your engagement. See how we scope, deliver and hand over the work.
If the platform direction is still open, begin with an independent assessment. Improving the current platform remains an option; a migration recommendation should be justified by your requirements and evidence. Explore our broader data engineering services.