You have an SAP production landscape that uses SAP HANA databases on Azure. The HANA database server is a Standard_M32ms Azure virtual machine that has 864 GB of RAM. The HANA database is 400 GB…

Question

Options

• AIncrease the number of vCPUs.
• BConfigure additional disks
• CAdd a secondary network interface.
• DAdd a scale out node.

• A
  4% (2)
• B
  75% (41)
• C
  15% (8)
• D
  7% (4)

Explanation

Configuring additional disks (B) directly addresses the performance impact of database growth because SAP HANA, while in-memory, depends heavily on disk I/O for data persistence, log writes, and savepoints - as the database grows from 400 GB toward 560 GB, storage throughput becomes the bottleneck, and adding disks increases available IOPS and throughput to match that demand. The VM resize already handled RAM (1,024 GB comfortably covers 560 GB), so memory is no longer the constraint.

Why the distractors are wrong:

• A (vCPUs): CPU is not the bottleneck caused by data volume growth; adding cores doesn't relieve disk I/O pressure.
• C (Secondary NIC): A second network interface improves network bandwidth, not storage performance - irrelevant to database size growth.
• D (Scale-out node): Scale-out is for distributing workloads across multiple hosts when a single node can no longer hold the database in memory; since 560 GB fits within 1,024 GB RAM, scale-out is unnecessary and overkill here.

Memory tip: Use the phrase "more data = more disk work." Once RAM is covered by the VM resize, the next bottleneck is always storage I/O - more disks = more IOPS = less performance degradation.

No community discussion yet for this question.