Advanced HANA Monitoring
3 Useful Checks for SAP HANA Monitoring
As with any technical system, HANA needs to be properly monitored. All standard checks, reports and alerts should be put in place to make sure the system is operating at its prime such as:
- Resource Consumption (CPU, Memory, Disk, etc.)
- Emergency Setup (Backups, HA, DR, etc.)
- Network Performance
- And a world of various other checks, monitors and alerts
While each are vitally important and require proper monitoring, there is a world of blogs and papers out on this extremely important topic. The intent of this blog, however, is to review a handful of unique checks that can help your HANA system run optimally. Below are three monitoring checks that should be implemented to keep an eye on HANA performance:
1. Plan Cache Release: The plan cache provides a unique window into the workload of the system. At the core level of any database are a set of statements used to run queries. HANA’s Plan Cache can store these plans for reuse, thus not having to recompile each time. Inherently, this cuts down on the amount of time for a query to run and directly impacts system performance. Within the HANA studio itself, one can generate a graphical view of a statement by selecting “Visualize Plan”. However, from a monitoring standpoint, it’s important to know the statistics around ‘expensive’ queries and plans. Monitoring the plan cache can give an easy and informative performance analysis overview by reviewing the number of executions, average runtime and lock/wait statistics of long running plans. Continually identifying candidates for optimization will keep the system running lean and mean.
2. Expensive Statements: Storing poorly written plans in the Plan Cache for reuse can be troublesome if the contained statements are poorly written. Out of the box, HANA does not set any thresholds to alert on statements that are expensive (run for long periods of time and take up resources). By turning this check on, it is easy to see the statements causing issues. Historically, this is something we’d review weekly or monthly in the SAP provided EWA reports. With HANA, this has become much more critical and needs to be reviewed in near real time. Not only can these statements be monitored live, the amount of peak memory (most memory used) can be directly associated and identified with a problem statement.
3. Delta Merge Operation: Delta storage is where the database write operations occur in HANA. At a basic level, the data must be converted into a design that is enhanced for memory based performance for an operation writing to two main storage segments and two storage deltas. This whole operation goes into multiple writes, deletes, and possibly even reorders rows and adjusts compression parameters – a topic for multiple blogs alone. However, from a monitoring perspective, it’s important to keep an eye on the delta merge operation. This whole process is not only CPU extensive but also memory taxing as it writes in parallel and duplicates memory usage (temporarily).
These are just the tip of the iceberg for HANA performance monitoring. Depending on how granular you want to get, there is a world of other checks that can be performed. Every system is developed uniquely and different checks will be at a different level of importance for each system. What are some of the unique HANA checks you’ve found valuable? To find out more about Symmetry’s HANA service and hosting solutions please visit us at symmetrycorp.com.