SF-Data-Arch Large Data Volume Considerations Practice Question
A custom object 'Invoice__c' contains 8 million records and has a lookup to Account. A nightly batch job deletes approximately 2 million old invoices using Database.delete() in batches of 200. Users report that the batch sometimes fails with 'UNABLE_TO_LOCK_ROW' errors when running concurrently with account updates. What is the most likely cause of these lock contention errors?
⚠ Common exam trap
The trap here is assuming that batch size or batch mode is the root cause, when the real issue is parent record locking inherent to deleting child records with lookup relationships.
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 delete operation is acquiring exclusive locks on the parent Account records referenced by the deleted invoices.
Deleting child records in a lookup relationship acquires exclusive locks on the parent records to maintain referential integrity. When concurrent updates target those same parent Accounts, lock contention triggers UNABLE_TO_LOCK_ROW errors. This is a common issue with high-volume deletes on objects with lookups to frequently updated parents.
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 nightly batch job is running in parallel mode, which causes multiple batch threads to compete for the same parent Account locks.
Why it's wrong here
Parallel batch mode can increase contention, but the question does not state that parallel mode is used. Even in serial mode, parent locking occurs. The primary cause is the inherent locking of parent records when deleting children, regardless of batch processing mode.
- ✓
The delete operation is acquiring exclusive locks on the parent Account records referenced by the deleted invoices.
Why this is correct
When deleting child records, Salesforce locks the parent records referenced by lookup relationships to maintain referential integrity. This blocks concurrent updates on those Accounts, causing UNABLE_TO_LOCK_ROW errors. The 2 million deletes touch many parent Accounts, increasing collision probability with the nightly account updates.
- ✗
The Invoice__c records have a master-detail relationship to Account, so deleting them cascades and locks all child records simultaneously.
Why it's wrong here
The scenario specifies a lookup relationship, not master-detail. Even with master-detail, deletes lock parent records individually as they are processed, not all at once. The lock contention arises from parent locking, but the relationship type and cascade behavior described here are incorrect.
- ✗
The batch size of 200 is too large, causing the database to lock the entire Invoice__c table during each batch execution.
Why it's wrong here
Salesforce never locks entire tables during DML operations. Batch size affects governor limits and transaction duration but not table-level locking. A smaller batch size might reduce lock duration, but the root cause is parent record locking from the lookup relationship, not the batch size itself.
About these practice questions
This SF-Data-Arch question is part of Courseiva's 222-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-Data-Arch 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-Data-Arch exam.