You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/relational-databases/logs/troubleshoot-a-full-transaction-log-sql-server-error-9002.md
+22-8Lines changed: 22 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -27,7 +27,7 @@ ms.custom: "seo-lt-2019"
27
27
**Option 1: Follow the steps directly in a notebook via Azure Data Studio**
28
28
29
29
> [!div class="nextstepaction"]
30
-
> [Open Notebook in Azure Data Studio](azuredatastudio://microsoft.notebook/open?url=https://raw.githubusercontent.com/microsoft/tigertoolbox/master/Troubleshooting-Notebooks/DOCs-to-Notebooks/T-Shooting_LogFull_9002.ipynb)
30
+
> [Open Notebook in Azure Data Studio](azuredatastudio://microsoft.notebook/open?url=https://raw.githubusercontent.com/microsoft/mssql-support/master/sample-scripts/DOCs-to-Notebooks/T-Shooting_LogFull_9002.ipynb)
31
31
32
32
[Learn how to install Azure Data Studio](../../azure-data-studio/download-azure-data-studio.md)
33
33
@@ -56,13 +56,19 @@ ms.custom: "seo-lt-2019"
56
56
57
57
The following specific steps will help you find the reason for a full transaction log and resolve the issue.
58
58
59
-
## Truncate the Log
59
+
## 1. Truncate the Log
60
+
61
+
A very common solution to this problem is to ensure transaction log backups are performed for your database which will ensure the log is truncated. If no recent transaction log history is indicated for the database with a full transaction log, the solution to the problem is straightforward: resume regular transaction log backups of the database.
62
+
63
+
### Log truncation explained
60
64
61
65
There is a difference between truncating a transaction log and shrinking a transaction log. [Log Truncation](the-transaction-log-sql-server.md#Truncation) occurs normally during a transaction log backup, and is a logical operation which removes committed records inside the log, whereas [log shrinking](../../t-sql/database-console-commands/dbcc-shrinkfile-transact-sql.md#shrinking-a-log-file) reclaims physical space on the file system by reducing the file size. Log truncation occurs on a [virtual-log-file (VLF)](../sql-server-transaction-log-architecture-and-management-guide.md#physical_arch) boundary, and a log file may contain many VLFs. A log file can be shrunk only if there is empty space inside the log file to reclaim. Shrinking a log file alone cannot solve the problem of a full log file, instead, you must discover why the log file is full and cannot be truncated.
62
66
63
67
> [!WARNING]
64
68
> Data that is moved to shrink a file can be scattered to any available location in the file. This causes index fragmentation and might slow the performance of queries that search a range of the index. To eliminate the fragmentation, consider rebuilding the indexes on the file after shrinking. For more information, see [Shrink a database](../databases/shrink-a-database.md).
65
69
70
+
### What is preventing log truncation?
71
+
66
72
To discover what is preventing log truncation in a given case, use the `log_reuse_wait` and `log_reuse_wait_desc` columns of the `sys.databases` catalog view. For more information, see [sys.databases (Transact-SQL)](../../relational-databases/system-catalog-views/sys-databases-transact-sql.md). For descriptions of factors that can delay log truncation, see [The Transaction Log (SQL Server)](../../relational-databases/logs/the-transaction-log-sql-server.md).
67
73
68
74
The following set of T-SQL commands will help you identify if a database transaction log is not truncated and the reason for it. The following script will also recommend steps to resolve the issue:
@@ -296,14 +302,21 @@ A complete history of all SQL Server backup and restore operations on a server i
296
302
297
303
#### Create a transaction log backup
298
304
299
-
300
-
> [!IMPORTANT]
301
-
> If the database is damaged, see [Tail-Log Backups (SQL Server)](../../relational-databases/backup-restore/tail-log-backups-sql-server.md).
302
-
305
+
Example of how to back up the log:
306
+
307
+
```tsql
308
+
BACKUP LOG [dbname] TO DISK = 'some_volume:\some_folder\dbname_LOG.trn'
309
+
```
310
+
303
311
-[Back Up a Transaction Log (SQL Server)](../../relational-databases/backup-restore/back-up-a-transaction-log-sql-server.md)
> If the database is damaged, see [Tail-Log Backups (SQL Server)](../../relational-databases/backup-restore/tail-log-backups-sql-server.md).
317
+
318
+
319
+
307
320
### More information on ACTIVE_TRANSACTION log_reuse_wait
308
321
309
322
The steps to troubleshoot ACTIVE_TRANSACTION reason include discovering the long running transaction and resolving it (in some case using the KILL command to do so).
@@ -327,7 +340,7 @@ Sometimes you just have to end the transaction; you may have to use the [KILL](.
327
340
328
341
When transaction changes at primary Availability replica are not yet hardened on the secondary replica, the transaction log on the primary replica cannot be truncated. This can cause the log to grow , and can occur whether the secondary replica is set for synchronous or asynchronous commit mode. For information on how to troubleshoot this type of issue see [Error 9002. The transaction log for database is full due to AVAILABILITY_REPLICA error](/troubleshoot/sql/availability-groups/error-9002-transaction-log-large)[Error 9002. The transaction log for database is full due to AVAILABILITY_REPLICA error](/troubleshoot/sql/availability-groups/error-9002-transaction-log-large)
329
342
330
-
## Resolve full disk volume
343
+
## 2. Resolve full disk volume
331
344
332
345
In some situations the disk volume that hosts the transaction log file may fill up. You can take one of the following actions to resolve the log-full scenario that results from a full disk:
333
346
@@ -422,7 +435,7 @@ END
422
435
423
436
```
424
437
425
-
## Change log size limit or enable Autogrow
438
+
## 3. Change log size limit or enable Autogrow
426
439
427
440
Error 9002 can be generated if the transaction log size has been set to an upper limit or Autogrow is not allowed. In this case, enabling autogrow or increasing the log size manually can help resolve the issue. Use this T-SQL command to find such log files and follow the recommendations provided:
428
441
@@ -509,3 +522,4 @@ If autogrow is disabled, the database is online, and sufficient space is availab
0 commit comments