Ola Hallengren documented an August fix for a regression that could rebuild or reorganize an entire index under conditions where maintenance was intended for a partition. On a large partitioned table, that difference can transform a bounded task into hours of extra I/O, transaction-log growth, blocking, replication pressure, and storage consumption. Automation scope is therefore a production control, not an implementation detail.
Why it matters in production
Teams should first identify estates where partition-level maintenance is expected. Capture the maintenance-solution version, parameters, table and index size, partition count, recent commands, duration, log growth, and wait behavior. The command log can reveal whether the generated `ALTER INDEX` statements operated on the intended partition or the full index.
Version management matters because shared maintenance code can spread a regression quickly. Pin an approved release, review version history, test generated commands against representative partitioned objects, and promote through rings. A central deployment should report the installed version and configuration on every instance rather than assume that files copied successfully.
Operational safeguards include free log and data space, log-backup capacity, blocking thresholds, abort criteria, and workload monitoring. If an unexpected whole-index operation occurred, assess log-chain impact, replica lag, maintenance overlap, and downstream storage effects before simply rerunning the intended partition work.
Practical takeaway
The practical conclusion is to verify what automation executed, not only what it was asked to do. Partition maintenance should produce partition-scoped commands and bounded resource use. Version pinning, command-log review, and representative tests turn a popular maintenance solution from trusted folklore into controlled production code.