This guide applies to an SQL Server instance you administer on a self-managed server. Confirm the affected database, recovery model, backup policy and available storage. Have an authorized DBA review recovery-model changes, interrupted transactions and availability-group problems. A control-panel disk chart alone cannot identify the cause.

1. Confirm the immediate constraint. Inspect the database error and the free space on the volume containing its log. Check the log file maximum size and autogrowth settings. A configured size limit and a physically full disk need different capacity actions.
2. Identify the reuse wait. Run the following read-only query with appropriate administrative access: SELECT name, recovery_model_desc, log_reuse_wait_desc FROM sys.databases; Find the affected database. The reported reason is a point-in-time clue; collect it again after any corrective action.
3. Measure used space inside the file. In a query window using the affected database, inspect sys.dm_db_log_space_usage with the monitoring permissions required by your SQL Server version. Compare internal used space with the physical file size. A large file can contain substantial reusable space.
4. Resolve the specific blocker. LOG_BACKUP usually calls for repairing the established log-backup job and destination under a recovery model that uses log backups. ACTIVE_TRANSACTION calls for investigating the long-running transaction and its owner. Replication or availability waits need their corresponding subsystem repaired. Do not kill work solely because its transaction is old.
5. Restore safe capacity if writes are threatened. Arrange approved storage expansion or a DBA-planned log file change while the underlying issue is addressed. Preserve enough headroom for transaction rollback and normal activity. Avoid copying or deleting an active .ldf file, and do not change to SIMPLE merely to bypass an alert.
6. Review sizing after recovery. When the blocker clears, confirm reuse and write operations recover. Set a realistic initial size and controlled growth increments for the workload. Shrinking may be appropriate after an exceptional event, but repeated shrink-and-grow cycles are not routine log maintenance.

In SQL Server Management Studio, connect to the intended instance using an account authorised for the required diagnostic views. Replace ExampleDB with the affected database. These statements report state and do not shrink, truncate or alter the transaction log.

SELECT name, recovery_model_desc, log_reuse_wait_desc
FROM sys.databases
WHERE name = N'ExampleDB';

USE [ExampleDB];
SELECT total_log_size_in_bytes, used_log_space_in_bytes,
       used_log_space_in_percent
FROM sys.dm_db_log_space_usage;

Read the result: Compare actual used space with the reason preventing log reuse. LOG_BACKUP, ACTIVE_TRANSACTION and replication or availability-related waits require different investigations. A large physical log file does not necessarily mean that all of its allocated space is currently used.

View permissions vary with SQL Server version and deployment. If access is denied, ask the database administrator for the specific diagnostic output. Preserve recovery requirements and the log-backup chain while resolving the cause; routine shrinking is not a substitute for that work.

Log truncation makes eligible space reusable within the log. It does not automatically reduce the physical file on disk. If used space has fallen and normal growth is stable, keeping an appropriately sized file can avoid repeated expansion. Review storage pressure and future workload before considering a deliberate shrink.

Check that the backup job continues succeeding, the reuse wait reflects normal activity, free disk space is sufficient and the application can commit transactions. Add alerts for backup failure and growth. Escalate with the database name, recovery model, wait reason and storage measurements if the log keeps filling.

• Testing a SQL Server database restore
• Extending a Windows Server data volume safely
• Planning Windows Server Backup and a test restore
• Configuring encrypted SQL Server client connections

• Troubleshoot a full transaction log
• Manage transaction log file size
• Transaction log space usage

• Microsoft: SQL Server transaction-log usage