Executives run large ad hoc sales reports against the production order database during business hours, and online checkout slows noticeably whenever they do. Which change best addresses the conflict?

OLTP and OLAP workloads compete when they share a database: long-running analytical queries consume CPU, memory and I/O and may hold locks or generate heavy versioning, which slows the short transactions customers depend on. The established pattern is to separate them, either by sending reports to a read replica of production or by loading data into a dedicated OLAP store or warehouse through ETL or ELT. Checkout then runs on resources sized for transactions, and reporting can be scaled and modeled independently. Adding many indexes to the order tables may speed some reports but increases the cost of every insert and update at checkout and still leaves both workloads on the same server. Raising the reports to serializable isolation increases locking and blocking, making the checkout slowdown worse rather than better. Denormalizing the production tables to suit reports harms the transactional design by adding redundancy and update anomalies, and the analytical scans still run on the production server. Exam caveat: a replica may lag slightly behind production, which is usually acceptable for reporting but should be agreed with the business. Operational check: redirect report connections to the replica or warehouse and compare checkout response times during reporting periods against the prior baseline.