SAP Performance Tuning: The RHONDOS PowerConnect Way (May 2024)
This article was authored by Benjamin Dare, Sales Engineer at RHONDOS.
As an #SAP basis administrator for 18 years, I took pride in my intimate relationship with the systems I managed. I would spend hours each day traversing the many T-codes required to get a complete picture of the health of my systems. While I never paid a penny in maintenance or licensing expenses, they were still MY systems. I cared for them like my children because I was ultimately responsible for their care and feeding. If anything were to go bump in the night, I would get a call; something any basis admin tries to avoid. I knew the user IDs of the “troublesome users” who would not restrict their searches, the biggest problem T-codes, and Z programs that needed tuning. I could instantly rattle off the databases' size and growth rates.
SAP system monitoring became a passion of mine. I earned two certifications in SAP monitoring through Solution Manager (E2E100 – Root Cause Analysis / E2E300 – Business Process Monitoring). Like many basis admins, I had developed my routine and was set in my ways. My inbox was constantly flooded with marketing emails from companies trying to get me to convince management their product would make my life easier so I could spend my time on more meaningful tasks. I wasted time on a couple of vendors. They came to the office, performed their demo, and were never heard from again.
Fast forward to Spring of 2023. I had been working as a Solution Architect for a large managed service provider (MSP), but I was looking for a new role. A recruiter got me an interview with a company called RHONDOS to work as a Sales Engineer selling something called #PowerConnect that sends data to a platform called #Splunk. While both companies were very well established, I had not heard of either. I was an SAP basis admin, and I used the tools SAP provided. I had seen demos of 3rd party vendors saying they could do it better than SAP, but they all fell short. Like any good candidate, I researched the companies and the technology they were selling. During my research, I came across one slide that changed my world.
I had seen dashboards like this in the past, but this one was different. Bougie monitoring platforms I had seen in the past could report KPIs from different sources onto a singular screen, but these were all being reported from the same source. A single source of truth to determine the root cause of performance bottlenecks? Any administrator/engineer who has been in the game long enough has had the unfortunate experience of spending all night on a SEV1 bridge call. If you have been lucky enough to escape this encounter, let me describe it for you.
As Freud would have it, the SEV1 gets triggered at 5:30, just as you pull into your driveway. Someone from the service desk calls you and tells you they are standing up a bridge call and your attendance is required. As a basis admin, you join the bridge along with folks from the server and network teams and someone from the application team that reported the outage. Each team instantly begins frantically searching logs in their respective areas, hoping to uncover the root cause so we can all go back to our lives and enjoy dinner with our families. The network team checks link status, bandwidth capacity, and access control lists for blocked network traffic. The server team is looking through #VMWare logs for over-allocated VMs, busy storage arrays, full file systems as well as CPU and Memory utilization. As a basis admin, you start your checklist of T-Codes to validate the health of SAP. The good news is you don’t find anything wrong with SAP. The bad news is no one else is claiming responsibility for the outage either. Because it’s a SEV1, no one can leave the call until there is an #RCA and the application team gives the all-clear. Each team continues searching through their logs – disparate logs in separate systems with no correlation. I have spent countless hours on these types of bridge calls until the canary finally appears from the coal mine. That pesky bird usually waits until the sun is coming up to appear.
I was enthused about working at #RHONDOS because I was presented with an opportunity to sell a platform and protect others from nightmare phone calls. That single slide excited me because I knew it represented a single platform that correlated data from different sources into a single source of truth.
This is fantastic news! As any basis admin can attest, much of our time is spent proving innocence. Whenever a problem could be remotely tied to SAP, the basis queue is the first place the ticket lands. By ingesting data from multiple data sources that construct an SAP landscape and the spider web of systems that SAP communicates with, the Mean Time To Detect (MTTD) and Mean Time To Resolve (MTTR) improves exponentially. A well-built dashboard will quickly highlight trouble areas for a targeted response. Hopefully, by configuring alerts on anomalies, IT teams can resolve the issue before end users submit a ticket!
In part 2 of this 3-part series, we will take a deep dive into a sample dashboard. I’ll show you how I took all the data from ST06 and made it much easier to view and understand. I will also show you the SPL code I used to create my dashboard. Data that is easy to read and readily available makes submitting data to non-technical management a breeze. I hope you’ll join me as I take you on the journey I’ve been on since joining the team at RHONDOS!
