In a prior blog we provided some tips on Managing HANA memory. In this article we will further explore the improvement with ESS (Embedded Statistics Service) available on HANA from SPS 7 revision 74 or higher. As a quick recap, memory consumption by the hdbstatisticsserver can be heavily impacted by the volume and frequency of various statistics collected by the HANA statistics engine, mainly the columnar tables in _SYS_STATISTICS schema. These tables provide stats for monitoring by tools such as the HANA Studio, SAP DBA Cockpit and Solution Manager, as well as external SAP management tools like IT-Conductor and HANA Management Pack for SCOM.
We've had the opportunity to work with HANA both as a Startup porting our application to HANA as well as with our SAP customers running HANA in production scale BW or ECC environments. In the R&D environment we have limited hardware capacity and thus resources, especially memory is always a constraint, so we learnt ways to monitor, and automate to optimize our performance and use of the system. In the customers' production environment, we have seen original architecture plans double in nodes and/or memory before they even got to performance testing phase.
SAP has a pretty catchy new spin since 2014 with the slogan “Run Simple”, well maybe for the business and end-users, but as far as the Basis team is concerned, managing the sprawling SAP landscapes and lifecycle is anything but simple. In my experience, the move to newer SAP technologies (such as HANA, Sybase, BOBJ, virtualization, cloud, etc.) has proliferated more requirements and demands on the Basis, Infrastructure and IT Operations teams. One example of this includes new deployments of SAP HANA which may scale out a Production environment up to 16 nodes. That is anything but simple. But I’ll play along that if you consolidated all your SAP environments into this huge HANA cluster, then it may look simple like in the old days when there was only R/3 and everything ran on it. However, if you’re going to put all your eggs into one basket, then you’ll need to protect it with a Business Continuity strategy for HA and DR which would no doubt be very complex.
As far back as I can remember, and that's more than 20 years working in SAP Basis, since the days of R/3, there's always been this 2 second average response time per dialog step (or simply 2 second response) benchmark as acceptable performance of an SAP OLTP system. Depending on the customer, some will tweak that to fit their business, and I have seen it range from 0.5 second to as high as 5 seconds. Honestly, it's a misleading indicator of performance because on any given mid-size SAP ECC production system with about 500 concurrent users, that number quickly becomes a useless measure with more transaction mix between SAP and custom code. To put it into perspective, a system may have a 0.5 second response time, but there are constant complaints from users with bad response times. Why? It's the law of averages. The more number of small transactions there are (those who run relatively quick), the more they bring down the system average into an attractive average response time, even though there are transactions that run forever and frustrate the hell out of those users who need to run them as part of their daily business process. It's because dialog steps are not created equal.
How useful is space monitoring of HANA volumes? After all isn't the data very compressed in memory and the space consumed on the volume should be negligible? It is true that HANA has great compression on most types of data, one of the reason is that columnar tables get better compression because the data in columns tend to be more repetitive. One of the benefit of running on hardware with many fast cores is its ability to perform fast and efficient on-the-fly access to compressed data.
But I digressed, as DBAs we care about how much space is available in the database containers, and if those containers have enough room in the filesystem to grow on demand. Space should never become the reason of an outage in a well maintained database environment.
This week we finally see the results of all the work we put in to Solution Manager 7.1 from system preparation through to technical monitoring. Although no two SAP environment are exactly the same, even though they maybe based on the same products and installed in identical manners, hopefully you have a good sense of what it takes to get technical monitoring up and running in Solman. Unfortunately, no amount of SAP documentation or guided procedures can give you the same sense as actually doing it or follow along an actual implementation, so we encourage you to try it yourself, or use our example here to gauge and plan for such efforts since it's not trivial.
To recap the other 2 parts leading up to this final setup and demo, we completed:
- Netweaver on HANA Monitoring Setup Part 1 of 3 (Preparation)
- Netweaver on HANA Monitoring Setup Part 2 of 3 (Managed System Configuration)
In Netweaver on HANA Monitoring Setup Part 1 of 3 (Preparation) steps were performed to allow the Solution Manager and the Managed System to communicate with each other. As a recap, the landscape consists of Solution Manager 7.1 that was previously upgraded to SPS12 including Landscape Management DB, on Windows/MSSQLServer. The systems to be managed includes SAP BW 7.31 (HNA) on HANA database SPS07 (HDB), both running on SUSE Linux 11.3.
In this Part 2, the majority of the work is to configure the managed systems with these high-level steps:
- Assign Product
- Check Prerequisites
- Maintain RFCs (for ABAP managed system)
- Assign Diagnostics Agent
- Enter System Parameters
- Enter Landscape Parameters
- Maintain Users (for monitoring ABAP managed system)
- Finalize Configuration
- Check Configuration
- Complete Configuration
I mentioned in the prior post (SAP Solution Manager Technical Monitoring) about the effort of installation, patching, and configuration before one can monitor and/or manage an SAP system using Solution Manager 7.1. In this 3-parts article, I'll share just a small (but lengthy) portion: SAP Netweaver on HANA Monitoring Setup, using an example from our lab which I had tasked one of our senior SAP Basis consultants to perform.
To put into context about the landscape, we had already installed Solution Manager 7.1 previously and upgraded to SPS12 on Windows/MSSQLServer. We also installed SAP BW 7.31 on HANA SPS07 on a mini-basis trial, which comprises of a HANA database (HDB) running on SUSE Linux 11.3, and an SAP Netweaver central instance (HNA) also running on another SUSE Linux 11.3 server.
Over the last week we've been busy updating our SAP Solution Manager 7.1 from SPS11 to SPS12. It doesn't sound like much but as usual, we found so many notes, preparations and post-processing to perform. It's a whole lot more than just running SUM (Software Update Manager), so it will have to be topic of discussion for another time.
Pull out your SAP HANA Technical Operations Manual for the latest SPS09 release and you will find section 2.4 about Monitoring the SAP HANA Database, and section 2.9 discussing High Availability for SAP HANA at very shallow depth. After reading them, are you confident that your HANA setup is well monitored and highly available enough to go Production? If the answer is NO, then you've got some work to do before that in-memory investment can go live.
Let's start with Monitoring. Here are your choices from SAP:
- SAP HANA Studio
- SAP HANA Cockpit from a Web browser (essentially SAP DBA Cockpit)
- SAP Management Console
- SAP Solution Manager technical monitoring
- SAP Landscape and Virtualization Manager (LVM)