Whether you're a seasoned SAP HANA administrator, a SQL Server DBA, or someone responsible for monitoring both platforms with SolarWinds Database Performance Analyzer (DPA), you've likely encountered the term "waits." For SQL Server professionals, wait statistics are one of the most trusted methods for diagnosing performance bottlenecks because they reveal where sessions spend time waiting on resources such as I/O, locks, memory, or CPU scheduling. SAP HANA, however, approaches performance monitoring differently. While DPA presents performance events in a familiar wait-based interface, SAP HANA does not expose wait statistics in the same way SQL Server does. Understanding this distinction is essential to interpreting what DPA is reporting and, more importantly, knowing which HANA metrics and system views should be used to investigate the root cause of performance issues. This blog post explores those differences and provides practical guidance for interpreting performance data in SAP HANA through the lens of both HANA and SQL Server professionals.
Unlike SQL Server, SAP HANA does not maintain a centralized wait statistics repository that aggregates where sessions spend their time waiting throughout the lifetime of the instance. Instead, SolarWinds Database Performance Analyzer (DPA) maps SAP HANA thread activity into meaningful execution categories that help identify where SQL statements are spending time during execution. Although these categories appear in the familiar Top Waits view, they should be interpreted as execution phases or thread states rather than SQL Server-style wait statistics. The screenshot below demonstrates a simple snapshot in Top Waits of this SAP Hana Instance where DPA captured three primary activities: Running ExecuteStatement, Running PrepareStatement, and Network Write.
The dominant activity shown in this workload is Running ExecuteStatement. This represents the period where SAP HANA is actively executing a SQL statement after parsing and optimization have already occurred. When this category consumes a significant amount of time, it often indicates the database engine is spending considerable resources processing the statement itself rather than waiting on an external resource. SQL Server professionals may instinctively compare this to CPU-intensive execution rather than a traditional wait type such as PAGEIOLATCH or LCK_M_X. For HANA administrators, prolonged ExecuteStatement activity can point toward inefficient SQL, large table scans, missing predicates, or statements that repeatedly bypass prepared execution by using literal values instead of bind variables.
The second category, Running PrepareStatement, represents the compilation and preparation phase before execution begins. During this stage, SAP HANA parses the SQL text, validates objects, generates an execution plan, and prepares the statement for execution. Excessive preparation time is frequently associated with applications issuing thousands of ad hoc SQL statements instead of parameterized statements. In those environments, SAP HANA may repeatedly compile nearly identical SQL, increases CPU utilization and generating unnecessary plan cache activity. Monitoring views such as SYS.M_SQL_PLAN_CACHE can help determine whether statements are being prepared far more frequently than they are reused, making parameterization and prepared statements valuable optimization opportunities.
The final activity captured by DPA is Network Write. Unlike the previous two execution phases, Network Write typically indicates the database engine is ready to return results but cannot transmit them to the client as quickly as they are being produced. This can occur because of network latency, limited bandwidth, slow client applications, oversized result sets, or consumers that retrieve data more slowly than SAP HANA can generate it. From a SQL Server perspective, this resembles situations where the database finishes execution but spends additional time sending rows across the network rather than performing database work. The root cause is therefore often found outside the database engine itself. To clarify, from a point of view of SQL Server DBAs, Network Write can be loosely compared to the ASYNC_NETWORK_IO wait type, where the database is primarily occupied transmitting results to the client.
One important observation from this example is that none of these three activities necessarily indicate a bottleneck inside SAP HANA itself. Instead, each highlights a different phase of the query lifecycle that deserves further investigation. Heavy ExecuteStatement activity points toward query tuning opportunities, elevated PrepareStatement time suggests application parameterization or plan cache improvements, while Network Write shifts attention toward client behavior and network infrastructure. Understanding which phase dominates allows DBAs to engage the correct teams database administrators, application developers, or infrastructure engineers to resolve the underlying issue.
Although SAP HANA approaches performance analysis differently than SQL Server, DPA still provides an effective workflow for identifying performance problems. Rather than focusing exclusively on traditional wait statistics, administrators should use these execution categories alongside HANA monitoring views, expensive statement analysis, SQL Plan Cache information, savepoint metrics, and thread samples to build a complete picture of workload behavior. For SQL Server DBAs learning HANA, this represents a shift in terminology rather than a loss of diagnostic capability. The goal remains the same: identify where execution time is being spent and determine the most effective optimization strategy.
Taking a deeper dive at the SQL Text in DPA, we observe the SQL statement SELECT * FROM SYS.M_MONITOR_COLUMNS captured by DPA queries SAP HANA’s system catalog to return metadata about the columns available across HANA monitoring views, making it a convenient read-only statement for generating observable activity in a demonstration environment. Because the query requests every column from the view without filtering, HANA must prepare the statement, execute it, assemble the result set, and return the rows to the client. In DPA, that lifecycle appears as three activity categories: Running PrepareStatement, representing parsing, validation, and execution-plan preparation; Running ExecuteStatement, representing the time HANA actively processes the query and retrieves the monitoring metadata; and Network Write, representing time spent transmitting the completed result set to the requesting client. The chart therefore does not necessarily indicate a serious performance problem it shows where elapsed time was distributed while the statement was processed. SAP defines M_MONITOR_COLUMNS as the system view containing information about the columns in HANA monitoring views, while DPA’s trend charts aggregate the activity attributed to a SQL statement over the selected period.
As SAP HANA adoption continues to expand across enterprise environments, database teams need observability platforms that can follow the workload beyond traditional SQL Server, Oracle, or PostgreSQL estates. SolarWinds Database Performance Analyzer’s SAP HANA monitoring capability helps close that gap by providing a familiar, time-based workflow for identifying expensive SQL, reviewing execution activity, correlating performance trends, and determining where statement time is being spent. Although HANA does not expose wait statistics in the same manner as SQL Server, DPA translates HANA thread and execution activity into categories that DBAs can use to investigate query preparation, execution, locking, network transfer, and other contributors to response time.
That capability is increasingly important as database environments become more diverse and application teams expect consistent visibility across platforms. Database observability is no longer limited to confirming whether a database is available; teams must quickly explain why performance changed, which SQL statements were involved, and whether the next action belongs to the DBA, application developer, infrastructure team, or network team. By extending its wait-time analysis methodology to SAP HANA while respecting the differences in HANA’s architecture, DPA gives organizations a practical way to monitor a growing platform without forcing every administrator to learn an entirely separate troubleshooting workflow from the beginning.
