SF-PD2 Performance Practice Question
A developer is building an Apex batch job that processes 50,000 Account records. The batch class uses `Database.executeBatch` with a batch size of 200. After running the job, the developer notices that the job takes significantly longer than expected and sometimes fails with `UNABLE_TO_LOCK_ROW` errors on the Account object. What is the most likely cause of the performance degradation?
⚠ Common exam trap
The trap here is assuming that batch size is the primary cause of locking errors, when in fact concurrent updates from other processes are the usual culprit.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The batch job is running in parallel with another batch job that updates the same Account records, causing lock contention.
The `UNABLE_TO_LOCK_ROW` error occurs when multiple processes attempt to modify the same records simultaneously. In this scenario, the batch job likely runs concurrently with another process updating the same Accounts, causing lock contention and slowing down the job. Adjusting batch size or query selectivity would not resolve the locking issue; coordinating the timing of updates is necessary.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
The batch job is running in parallel with another batch job that updates the same Account records, causing lock contention.
Why this is correct
When two batch jobs or processes attempt to update the same records concurrently, row-level locks are held, leading to `UNABLE_TO_LOCK_ROW` errors and longer runtimes. The default batch size of 200 is not inherently problematic. The scenario indicates concurrent access, which is the most plausible cause of the locking and slowdown.
- ✗
The batch job is using a SOQL query without a WHERE clause, causing a full table scan.
Why it's wrong here
A full table scan would cause the query to be slow, but it would not typically result in `UNABLE_TO_LOCK_ROW` errors. Locking errors are related to record modifications, not query performance. The scenario mentions locking errors, so this option is not the primary cause of the performance degradation.
- ✗
The batch size is too large, causing excessive locking on the Account records.
Why it's wrong here
A batch size of 200 is relatively small and typically reduces locking contention because each batch processes fewer records. Increasing batch size would likely increase lock contention, not decrease it. The error is more likely due to concurrent updates from other processes or a different batch job. Therefore, this option does not correctly explain the observed performance issue.
- ✗
The batch job is not using `Database.Stateful`, causing it to lose state between batches.
Why it's wrong here
`Database.Stateful` is used to maintain state across batch executions, but it does not affect record locking or performance in the way described. Without it, the job simply loses variable values, but that does not cause `UNABLE_TO_LOCK_ROW` errors. This option is unrelated to the locking issue.
Visual reference
About these practice questions
This SF-PD2 question is part of Courseiva's 226-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Salesforce exam blueprint
This SF-PD2 practice question is part of Courseiva's free Salesforce certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SF-PD2 exam.