A large overnight batch loads millions of rows in one transaction. Partway through, the volume holding the transaction log runs out of space and the batch fails. Monitoring covered only the data file volume. Which change best prevents a recurrence?

The transaction log records every change so the database can roll back incomplete transactions and recover after a failure. A single very large transaction keeps all its log records active until it commits, so log space grows throughout the load and cannot be reused until the transaction ends. Monitoring the log volume's free space with threshold alerts provides warning, and breaking the batch into smaller transactions that commit periodically lets the log be reused or backed up between chunks, keeping peak log usage bounded. Polling the data file volume more frequently still leaves the log volume unmonitored, which is where the failure occurred. Disabling transaction logging is not a standard option for relational engines, which rely on the log for atomicity and durability; where minimal logging modes exist, they still use log space and change recoverability, so they are not a substitute for capacity monitoring. Shrinking data files frees space on the data volume, which may not be the same volume as the log, and the data files will simply regrow, adding fragmentation and I/O. Exam caveat: disk space monitoring covers data files, transaction logs, temporary storage and backup targets, each of which can independently fill a volume. Operational check: add warning and critical alerts for the log volume, size the log for the largest expected batch chunk, rerun the batch in commits of a tested size, and confirm peak log usage stays within limits.