You have an Azure SQL database named DB1 in the General Purpose service tier. The performance metrics for DB1 are shown in the following exhibit. You need to reduce the Log IO percentage. The…

Question

Exhibits

Options

• AChange Service tier to Business Critical.
• BIncrease the number of vCores.
• CPerform a checkpoint operation.
• DChange Recovery model to Simple.

• A
  81% (47)
• B
  2% (1)
• C
  5% (3)
• D
  12% (7)

Explanation

Explanation

Switching to the Business Critical service tier is the correct choice because it uses a local SSD-based storage architecture, which provides significantly higher transaction log I/O throughput compared to General Purpose's remote storage - directly reducing Log IO percentage without requiring additional vCores. Option B (increasing vCores) does not address the root cause; adding more compute resources won't meaningfully improve log write performance in General Purpose, as the bottleneck is the remote storage layer, not CPU. Option C (performing a checkpoint) flushes dirty pages from the buffer pool to disk but does not reduce the Log IO percentage metric, which reflects write pressure on the transaction log itself. Option D (changing to Simple recovery model) reduces log space usage by allowing log truncation more frequently, but it does not reduce the I/O rate on the log - and it sacrifices point-in-time recovery, which is usually unacceptable.

Memory Tip: Think "Business Critical = local SSD = blazing fast log I/O." Whenever you see Log IO as the bottleneck in General Purpose, the tier change to Business Critical is the targeted fix - it's a storage architecture upgrade, not just a compute upgrade.

No community discussion yet for this question.