---
title: "Manage SQL Transaction Log File Size"
slug: "manage-log-file-size"
updated: 2026-11-05T06:45:38Z
published: 2026-11-05T06:45:38Z
canonical: "docs.biztalk360.com/manage-log-file-size"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.biztalk360.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Manage SQL Transaction Log File Size

If the SQL transaction log file is consuming a significant amount of disk space, follow the steps below to identify the cause and reduce the log file size where appropriate.

## Check Disk Usage

First, check how much disk space is being used by the transaction log file.

1. In **SQL Server Management Studio (SSMS)**, right-click the **BizTalk360** database.
2. Select **Reports → Standard Reports → Disk Usage**.
3. Check the transaction log space usage. If a significant percentage of the log file is unused, you can shrink the log file to release the unallocated space.

![](https://cdn.document360.io/253f6006-3994-42d0-98cd-fdc637f51791/Images/Documentation/image-WDR6GL7Q.png)

## Shrink the Transaction Log File

To release unused space from the transaction log file:

1. Open **SQL Server Management Studio (SSMS)**.
2. Right-click the **BizTalk360 database**.
3. Select **Tasks → Shrink → Files**
4. Select the appropriate **File type** and **File name**.
5. Select **Release unused space**.
6. Click **OK**.

The **Release unused space** option releases unallocated space back to the operating system without moving data within the file.

![](https://cdn.document360.io/253f6006-3994-42d0-98cd-fdc637f51791/Images/Documentation/image-3DCILSH9.png)

![](https://cdn.document360.io/253f6006-3994-42d0-98cd-fdc637f51791/Images/Documentation/image-4IDDQJQQ.png)

You can also create and execute a SQL script to shrink the transaction log file.

![](https://cdn.document360.io/253f6006-3994-42d0-98cd-fdc637f51791/Images/Documentation/image-MYE65XW9.png)

> [!WARNING]
> Shrinking a transaction log file **does not resolve the underlying cause of continuous log growth**. Avoid shrinking the log file repeatedly as a routine maintenance activity. Instead, identify why the log space cannot be reused and address the underlying issue.

## Troubleshoot a Transaction Log That Cannot Be Truncated

If the transaction log file remains large after shrink, the database may be waiting for a transaction log backup or another operation before it can reuse the log space. This commonly occurs when the database uses the **FULL** or **BULK_LOGGED** recovery model and does not perform regular transaction log backups.

### Check the Log Reuse Wait Reason

Execute the following query in SSMS:

```sql
SELECT name, recovery_model_desc, log_reuse_wait_desc
FROM sys.databases
WHERE name = 'BizTalk360';
```

Review the `log_reuse_wait_desc` column to identify why SQL Server cannot reuse the transaction log space.

If the result is`LOG_BACKUP`, a transaction log backup is required before the log space can be reused.

### Take a Transaction Log Backup

If the database uses the FULL or BULK_LOGGED recovery model, and the log reuse wait reason is `LOG_BACKUP`take a transaction log backup to a suitable backup destination.

For example:

```sql
BACKUP LOG [BizTalk360]
TO DISK = N'D:\SQLBackups\BizTalk360_Log.trn'
WITH COMPRESSION;
```

Replace the example destination with an appropriate path that exists on the SQL Server and is accessible to the SQL Server service account. After the backup completes successfully, check the log reuse wait reason again:

```sql
SELECT log_reuse_wait_desc
FROM sys.databases
WHERE name = 'BizTalk360';
```

If the log space is now reusable, you can attempt to shrink the log file to an appropriate size.

> [!CAUTION]
> **Note:** The `BACKUP LOG ... WITH NO_LOG` command shown in older SQL Server (2008 SQL) guidance is no longer supported. Do not use it.

### Consider the Recovery Model

If the database uses the **SIMPLE** recovery model, SQL Server automatically reclaims inactive transaction log space when possible. However, active transactions or other conditions can still prevent log space reuse.

![](https://cdn.document360.io/253f6006-3994-42d0-98cd-fdc637f51791/Images/Documentation/image-7G6V0RPB.png)

> [!WARNING]
> Switching from **FULL** to **SIMPLE recovery** should not be treated as a routine log-shrinking solution. It breaks the existing transaction log backup chain and affects point-in-time recovery. Before changing the recovery model, review your backup and recovery requirements with your database administrator.

## Clean Up the BizTalk360 Database in an Availability Group

If the BizTalk360 database is part of a SQL Server Always On Availability Group, additional considerations apply.

**Do not remove the database from the Availability Group or switch it to SIMPLE recovery solely to shrink the transaction log.**

A large transaction log can often be addressed by taking the required transaction log backups and resolving the underlying log reuse issue without disrupting high availability.

If database maintenance genuinely requires removing the database from the Availability Group, plan the operation with your SQL Server administrator and follow the appropriate procedure for your SQL Server version and topology. A planned maintenance procedure may include the following steps:

1. Review the Availability Group configuration, backup strategy, and recovery requirements.
2. Take the required database and transaction log backups.
3. **Remove** the database from the Availability Group only if necessary and in accordance with the approved maintenance plan.
4. Perform the required database maintenance.
5. Change the recovery model to **SIMPLE**. If the recovery model is changed to SIMPLE, understand that the existing transaction log backup chain is broken. Take a new full backup before establishing a new log backup chain.
6. **Run the cleaning job** to shrink and clear the database
7. Prepare the secondary replica for rejoining the Availability Group using the supported seeding or database restoration procedure.
8. Rejoin the database to the Availability Group and verify synchronization and data movement.
9. Confirm that the transaction log backup schedule and database monitoring are operating correctly.

The exact steps depend on the Availability Group configuration and whether automatic or manual seeding is used. Follow the appropriate Microsoft documentation for your environment.

### Summary

To manage the BizTalk360 transaction log file size effectively:

- Check the database's disk usage and transaction log space consumption.
- Check `log_reuse_wait_desc` to identify why log space cannot be reused.
- Take transaction log backups when required by the recovery model.
- Shrink the log file only when necessary and after resolving the underlying issue.
- Avoid switching recovery models or removing a database from an Availability Group without evaluating the impact on backup recovery and high availability.
- Configure regular database backups and monitor transaction log growth to prevent recurring disk space issues.