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