What’s the issue?
Every SQL Server database has at least one data file (.mdf or .ndf) and one transaction log file (.ldf). The data files hold the actual data and indexes, while the log file records every transaction for recovery and rollback purposes. Under normal operation, the log file should be sized appropriately for the workload but generally remains smaller than the total data file size. This finding flags databases where the transaction log file has grown larger than the combined data files, which is almost always a sign that something is wrong.
Why is this a problem?
A log file that exceeds the size of the data files indicates that log truncation is not occurring as expected. Common causes include the database being in FULL or BULK_LOGGED recovery model without regular transaction log backups, a long running open transaction blocking truncation, replication or Change Data Capture falling behind, an Always On Availability Group replica that is disconnected or far behind in synchronization, or a one time operation such as a massive data load that forced the log to grow. The immediate consequence is wasted storage, but the deeper problem is that whatever is preventing truncation is also preventing recovery point objectives from being met. If the log file fills the disk, all writes to the database stop, causing an immediate outage.
What should you do about this?
First, determine why the log is not truncating by querying sys.databases for the log_reuse_wait_desc column, which tells you exactly what is holding log space. Common values include LOG_BACKUP (no transaction log backup has run), ACTIVE_TRANSACTION (a long running transaction is open), REPLICATION or DATABASE_MIRRORING (a feature is consuming log records), and AVAILABILITY_REPLICA (a replica is behind).
Address the underlying cause: take a transaction log backup if the database is in FULL recovery model, kill or commit blocking transactions, fix replication or AG synchronization issues, or investigate the specific reason reported. Once truncation resumes, the log space inside the file is freed but the file itself remains the same size. If the oversized log is not needed for normal operation, shrink it once with DBCC SHRINKFILE to a size that comfortably fits your normal workload plus headroom for index maintenance and large transactions, then leave it alone.
Avoid repeatedly shrinking and growing the log, since each growth event causes a brief pause and creates virtual log file fragmentation that hurts performance. Finally, confirm your recovery model and backup strategy align with your recovery objectives, and add log file size monitoring to your alerting so the next runaway growth is caught early.