A company runs a critical SAP ERP system on AWS. The architecture includes an SAP HANA database on an r5.24xlarge instance (with 768 GB RAM) in us-east-1a, and multiple SAP application servers in an Auto Scaling group across two Availability Zones (us-east-1a and us-east-1b). The database uses EBS volumes: two 1 TB gp3 volumes for data, one 500 GB gp3 for log, and one 100 GB gp3 for backup. The system has been running without issues for months. At 3:00 PM, the operations team receives alerts from Amazon CloudWatch that the HANA database instance's CPU utilization is at 100%, memory usage is at 95%, and the disk queue length for the log volume is consistently above 10. The SAP application is experiencing intermittent timeouts. The team checks the HANA studio and sees that there are many long-running queries and that the log volume is almost full (95% used). The database backups are scheduled to run at 2:00 AM and completed successfully. There have been no changes to the system or workload recently. The team suspects a performance degradation. What is the MOST likely cause of the issue?
Correct. A nearly full log volume forces HANA to pause transaction processing, leading to increased CPU/memory utilization and application timeouts.
Why this answer
The most likely cause is that the HANA log volume is almost full (95% used). When the log area reaches capacity, SAP HANA suspends transaction processing to prevent log overflow, leading to timeouts and increased CPU/memory usage as transactions queue. Option D correctly identifies this.
Option A is incorrect because HANA's memory management is dynamic and not constrained by global.ini limits. Option B is incorrect because the gp3 volumes have baseline IOPS of 3000, which is sufficient, and the symptom is log volume full, not I/O performance. Option C is incorrect because backups completed at 2:00 AM, hours before the issue.