The Trick to Monitoring SAP on IBM i

Image

IBM’s Power servers running the IBM i operating system is a popular platform for hosting SAP, due to its robustness and reliability. Even so, IBM i and related SAP workloads can be challenging to monitor at a discrete workload level.

SAP offers built-in tooling to help monitor and analyze SAP-specific performance data, but the data is communicated in SAP terms and not in view of overall system utilization, which is critical to providing optimal performance and throughput to the end user.

In the first part of this article, I’ll share the most important system and network components to keep an eye on. And in the second half, I’ll show you how an automated monitoring solution can help you do it.

Part One: What Should I Monitor?

Subsystems and jobs

SAP instances are isolated into individual IBM i subsystems, which allow multiple instances and even multiple SAP systems to run on a single partition. This means that fewer partitions are required to support development, test, and multiple production environments and—added bonus—protect against server sprawl.

Each environment is easily identified using the SAP naming convention SAP{nn}{SID}. You should be monitoring for each subsystem’s workload:

• Subsystem status (active/inactive)
• Job status (active/inactive)
• Temporary storage used by subsystem jobs
• CPU utilization total for each subsystem
• Disk busy for each subsystem
• Memory pool size and faulting rate

Image

Figure 1: SAP subsystem on IBM i

In a consolidated SAP environment that includes different types of SAP workloads with different characteristics (i.e., transactional versus analytical), I recommend exercising your work management skills by separating the SAP instances even further using “shared memory pools” and appropriate routing entries. This will separate each workload, making balancing busy environments much easier.

Memory, faulting, and temporary storage

Since the SAP work processes are heavily based on SQL, temporary storage is going to be higher than you may have encountered on non-SAP-based ERP solutions running on IBM i.

In addition, being able to compare average memory pool size—by month, day, or hour of the day—along-side memory pool faulting rates will help you determine the thresholds that you could put in place.

Based on these thresholds, an automated monitoring tool could also notify you when an environment gets busy and moving resources might be your best defense, but more on that later.

QUSRWRK

In order for SAP access to DB2 from outside IBM i, you’ll find XDN jobs and other SAP jobs in the QUSRWRK subsystem. JDBC access to DB2 will reveal QZDASOINIT jobs.

Image

Figure 2: QUSRWRK subsystem SAP-specific jobs

You’ll want to watch how much system performance this work is consuming and track how it impacts the rest of the IBM i environment. You’ll also want to compare resources consumed by external requests (QZDASOINIT or XDN) with internal SQL or requests submitted by work process “WP” tasks.

Disk utilization

SAP is very data-centric—even the run time code is stored in the DB2 database! Though the run time program databases are static, the rest of the ERP data is stored in tables. These journals and journal receivers are in IBM i libraries, while SAP logs are stored in the IFS. It’s best practice to manage and track that storage.

Visibility into the library structure and comparative analysis over time (12-18 months) is more helpful for growth planning than looking at the infamous WRKDSKSTS or WRKSYSSTS point-in-time data, which only provides a high-level view of ASP utilization.

RTVDSKINF for libraries and directories (but again, only point-in-time data) is provided unless manual tracking or custom coding is put into place.

Image

Figure 3: Directory analysis for the month of August 2017 for /user/sap/DE1 directory

Proper review on a regular basis and more granular disk analysis may reveal journal receivers that can be cleaned up or file reorg (RGZPFM) that could be done.

Careful review of disk utilization may reveal that additional disk storage is not needed when simple housekeeping will suffice.

Mixed environments

IBM i environments running SAP may not be running SAP exclusively, so integration points with other applications is a normal business practice. Integration is being accomplished with subsystems, interface jobs, ODBC/JDBC connections, and other facilities to share data. These IBM i facilities and jobs need the same monitoring to ensure all interfaces are up and running and performing adequately.

Similarly, today’s Power servers are not static, single partition environments. Virtualization reigns thanks to PowerVM, Virtual I/O Servers (VIOS), and SAN storage.

If you’re using VIOS, be sure to monitor—and ideally receive notification for—the following:

• Status of the physical disk adapter and network ports (available/ unavailable)
• Physical port throughput to disk (usage percent)
• AIX/VIOS error report (ERRPT command)

Part Two: How Should I Monitor It?

You want to continuous and automatically collect the critical metrics outlined in part one. You also want to be able to answer the question “What just happened?” with forensic detailed and summary data.

Even better, you want to be able to set multiple thresholds for performance factors such as CPU, disk I/O, or memory faulting and receive notification when they approach known boundaries where the end user or processing may suffer.

This is where an automated monitoring solution is your best ally for SAP success on IBM i.

Thresholds and notifications

Any monitoring solution you put in place should establish an historical record of where you’ve been with system and application performance. The data will vary by time of day and day of the week or month as the highs and lows of business transactions occur. Ad hoc reporting, daily batch processing, and heavy, transaction-based updates also impact the system and manifest in different ways.

Your job is to review historical data, determine what normal looks like, set appropriate thresholds, and set up notification so you can make changes before the system is overtaxed.

I recommend identifying performance metrics and setting thresholds prior to software updates. After deployment, compare how the software patch or software updates affects your CPU, disk, and memory utilization, and give that feedback to the AppDev team for next time.

Dashboards

Management loves dashboards. With an automated monitoring solution, you can provide a personalized dashboard to the CIO of your ERP environment that they can launch as needed. Not to mention that dashboards also give you a quick, at-a-glance way to confirm that IBM i is firing on all cylinders and not running too lean in any area.

Image

Figure 4: SAP performance and monitoring dashboard provided by Robot Monitor

Reporting

Management also loves—and often requires—reporting on past performance. Whether its daily, weekly, or monthly, reporting can be redundant at best and a drudgery at worst.

With all the historical data your automated monitoring solution collects, reporting is simply a matter of choosing the metric(s), the time range, and whether detail or summary data is most important. The tool should also facilitate posting the report for retrieval, emailing it to interested parties, or archiving it for auditing purposes.

Image

Figure 5: Sample reports available in Robot Monitor

Conclusion

Whether you’re more familiar with IBM i, SAP, or both, SAP monitoring and administration can be so much easier with well-defined procedures and proper tooling that can provide feedback on how the system and the discrete workloads are performing now, recently, and comparatively over past performance.

Providing this type of discrete, end-to-end monitoring and reporting for the SAP environment on IBM i (and AIX/VIOS) can be accomplished through a single tool called Robot Monitor, available from Fortra.

If you have any questions about monitoring SAP on IBM i or would like to see how Robot Monitor can help in your SAP environment, just let me know.

Happy monitoring!