Importance of transaction log in SQL Server

Importance of transaction log in SQL Server

Transaction logs are a vital and important component of database architecture. In this article, we’ll discuss transaction logs, importance, and their role in the database migration.

Introduction

Let’s talk about different options for taking SQL Server backups. SQL Server supports three different types of Backups.

1. Full

2. Differential

3. Transaction-log

Before jumping into transaction-log concepts, let’s discuss other basic backup types in SQL Server.

A full backup is a copy of everything. As the name implies, it will back up everything. It will back up all of the data, every object of the database such as a file, file-group, table, etc: A full backup is a base for any other type of backups.

A differential backup will back up data that has changed since the last full backup.

The third option is a Transaction-Log Backup, which will log all the statements that we issue to the database in the transaction log. The transaction log is a mechanism known as “WAL” (Write-Ahead-Logging). It writes every piece of information out to the transaction log first and then to the database. In other words, the process does not typically update the database directly. This is the only full available option with Full recovery model of the database. In other recovery models, data is either partial or there isn’t enough data in the log. For example, the log record when recording the start of a new transaction (the LOP_BEGIN_XACT log record) will contain the time the transaction started, and the LOP_COMMIT_XACT (or LOP_ABORT_XACT) log records will record the time the transaction was committed (or aborted).

To find internals of online Transaction Log, you can query sys.fn_dblog function.

The system function sys.fn_dblog accepts two parameters, first, begin LSN and end LSN of the transaction. By default, it is set to NULL. If it is set to NULL, it will return all log records from the transaction log file.

USE WideWorldImporters GO SELECT [Current LSN], [Operation], [Transaction Name], [Transaction ID], [Log Record Fixed Length], [Log Record Length] [Transaction SID], [SPID], [Begin Time], * FROM fn_dblog(null,null)

As we all know, the transactions are stored in binary format and it’s not in a readable format. In order to read the offline transaction log file, you can use fn_dump_dblog.

Let us query the transaction log file to see who has dropped object using the fn_dump_dblog.

SELECT [Current LSN], [Operation], [Transaction Name], [Transaction ID], SUSER_SNAME ([Transaction SID]) AS DBUser FROM fn_dump_dblog ( NULL, NULL, N'DISK', 1, N'G:\BKP\AdventureWorks_2016_log.trn', DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT) WHERE Context IN ('LCX_NULL') AND Operation IN ('LOP_BEGIN_XACT') AND [Transaction Name] LIKE '%DROP%'

We will use fn_dblog() function to read the active portion of the transaction log for finding activity that is performed on the data . Once the transaction log is cleared, you have to query the data from a log file using fn_dump_dblog().

This function provides the same rowset as fn_dblog(), but has some interesting functionality that makes it useful is some troubleshooting and recovery scenarios. Specifically, it can read not only transaction log of the current database, but also transaction log backups on either disk or tape.

To get the list of the objects that are dropped using transaction file, run the following query. Initially, the data is dumped to temp table. In some cases, the execution of fun_dump_dblog() takes a little longer to execute. So, it’s better to capture the data in the temp table.

To get an object ID from the Lock Information column, run the following query.

SELECT * INTO TEMP FROM fn_dump_dblog ( NULL, NULL, N'DISK', 1, N'G:\BKP\AdventureWorks_2016_log.trn', DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT) WHERE [Transaction ID] in( SELECT DISTINCT [Transaction ID] FROM fn_dump_dblog ( NULL, NULL, N'DISK', 1, N'G:\BKP\AdventureWorks_2016_log.trn', DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT) WHERE [Transaction Name] LIKE '%DROP%') and [Lock Information] like '%ACQUIRE_LOCK_SCH_M OBJECT%'

To get an object ID from the Lock Information column, run the following query.

SELECT DISTINCT [Lock Information],PATINDEX('%: 0%', [Lock Information])+4,(PATINDEX('%:0%', [Lock Information])-PATINDEX('%: 0%', [Lock Information]))-4, Substring([Lock Information],PATINDEX('%: 0%', [Lock Information])+4,(PATINDEX('%:0%', [Lock Information])-PATINDEX('%: 0%', [Lock Information]))-4) objectid from temp

The object_id can be found by manipulating theLock Informationcolumn value. In order to find object name for the corresponding object id, restore the database from the backup right before the table got dropped. After the restore, you can query the system view to get the object name.

USE AdventureWorks2016; GO SELECT name, object_id from sys.objects WHERE object_id = '1815677516';

Now, let us see the different forms of the same transaction details using sys.dn_dblog, sys.fn_full_dblog. The system function fn_full_dblog works only with SQL Server 2017.

Query to fetch the top 10 transactions using fn_dblog.

SELECT TOP 10 * FROM sys.fn_dblog(null,null)

From SQL Server 2017 onwards, you can use fn_full dblog.

SELECT TOP 10 * FROM sys.fn_full_dblog(null,null,DB_ID(),null,null,null,null,NULL)

You can further delve into the system function using the sp_helptext fn_full_dblog.

Next, query the backup file using the system function using fn_full_dblog. Again, this is applicable only from SQL Server 2017 onwards.