Heavy operational reports run directly against the live OLTP licensing database and cause lock contention for clerks. What architecture response is indicated?
Select an answer to reveal the explanation.
Short Explanation
Running giant reports on the same register clerks use is like auditing the cash drawer during every sale—everything locks up. Peel reporting load onto an isolated copy or ODS/warehouse path so transactions keep moving.
Full Explanation
Heavy operational reports running directly against live OLTP licensing databases cause lock contention for clerks and indicate missing workload isolation. Architecture should isolate heavy analytic or operational-reporting reads from the transactional system of record via replicas, ODS, or similar patterns. Increasing report concurrency on the same OLTP tables without isolation worsens contention. Disabling transactions so reports never wait destroys integrity. Requiring clerks to pause work whenever dashboards refresh is an unacceptable operational compromise. Exam response: isolate reporting from OLTP. Caveat: isolation choice depends on freshness needs—some reads may use synchronous replicas; others tolerate ODS lag. Operationally, move heavy licensing reports off the primary OLTP, validate clerk transaction latency recovers, and document which report class uses which isolation pattern. Keep a denylist of report queries forbidden on primary OLTP and enforce it in the licensing database tier used by clerks. Provide a sanctioned reporting replica or ODS path with clear freshness labels so analysts are not tempted to reconnection-string their way back onto primary OLTP. Educate report authors that OLTP connection strings for heavy licensing analytics are an architecture violation, not a productivity tip.