SAP HANA PlanViz and SQL Analyzer for Performance Diagnosis

An SQL statement is transformed by the HANA optimizer into an executable operator plan. Plan analysis reveals whether filters are pushed early, which join algorithm/order is chosen, where intermediate row counts explode, whether partitions are pruned, whether calculations prevent pushdown, and which operators dominate time/memory. Estimated cardinality can differ from actual runtime cardinality, leading to poor choices. PlanViz captures detailed execution statistics for a statement. SQL Analyzer in current HANA Cockpit/database tooling provides interactive analysis and plan visualization; exact tool naming/UI depends on HANA revision and deployment.

Use HANA plan analysis only after a problematic SQL has been isolated. Begin with ST05/SQLM for ABAP-source attribution or HANA expensive statements for database workload, then reproduce the exact SQL with representative parameter values. Use plan evidence when tuning joins, predicates, CDS stack, table functions, partitions or indexes. Do not optimize based solely on SQL text length or developer intuition.

ABAP Open SQL/CDS compiles to SQL sent to HANA. ST05 shows the statement and timing from ABAP; PlanViz shows what HANA did internally. Nested CDS, AMDP/table functions and calculated filters can introduce optimization boundaries visible in the plan. Database indexes/partitions affect access operators. SAT measures ABAP CPU but cannot explain an expensive HANA join operator.

A CDS report takes 90 seconds only for one company code. ST05 identifies one statement responsible for most DB time. Plan analysis shows a calculated expression prevents an early selective filter and creates a huge intermediate join. The CDS stack is refactored so the filter applies before the calculation; actual intermediate rows collapse and runtime drops. Adding an index would not have fixed the original pushdown boundary.

Plan analysis is highly relevant for S/4HANA because custom CDS/Open SQL/AMDP can generate complex HANA plans even when ABAP code is short. Clean-core does not mean performance is automatic; released views can still be consumed inefficiently. Managed cloud deployments may restrict direct DB tooling and provide alternative monitoring/support workflows.

HANA performance specialists interpret database plans; ABAP/CDS developers own application query redesign; functional teams provide representative selections/data semantics; Basis controls tracing/production access.

ST05/SQLM identify statements; SAT/ST12 measure ABAP/runtime. Nested CDS, code pushdown, table functions and database-index topics explain common plan shapes and remediation.

Production review: Capture SQL statement hash/text or ABAP source, bind values, execution count, total/average DB time, rows returned, PlanViz or analyzer capture, data volume and HANA revision. Preserve before/after plans for the same business case. A tuning change is successful only if workload-level time or resource use improves without changing business results or causing a different high-cost plan.

Additional validation: Operational validation for SAP HANA PlanViz and SQL Analyzer for Performance Diagnosis: capture a known-good baseline and one failing or stressed scenario from the exact SID, instance and client. Record release/kernel or HANA revision, timestamp, affected users/processes and the primary monitor evidence before any restart or cleanup. Test how the condition behaves across multiple application servers where relevant. Any tuning or administration change should have a rollback, persistence/restart requirement, and post-change metric so the team can prove improvement rather than merely observe that the symptom temporarily disappeared.