In this post, I am sharing few steps to find out the transactions history for drop commands which executed in SQL Server.

There are many features for auditing and check the logging in SQL Server, but you can also directly read the transaction log and can get the necessary details.

Please check the below full demonstration of this:

Create a sample database and use it:

CREATE DATABASE Drop_Test
GO
USE Drop_Test
GO

CREATE TABLE tbl_Test (ID INT)
GO

SELECT OBJECT_ID ('tbl_Test')
GO

--tbl_Test object id: 581577110

DROP TABLE tbl_Test
GO

SELECT [Transaction Id], [Begin Time], SUSER_SNAME ([Transaction SID]) AS [User]
FROM fn_dblog (NULL, NULL)
WHERE [Transaction Name] = 'DROPOBJ'
GO

-- The Result:
/*
Transaction Id Begin Time User
-------------- ------------------------ ---------
0000:00000335 2017/04/25 17:53:41:187 Anvesh
*/

SELECT [Transaction Id], [Begin Time], SUSER_SNAME ([Transaction SID]) AS [User]
FROM fn_dblog (NULL, NULL)
WHERE [Transaction Name] = 'DROPOBJ'
GO

-- The Result:
/*
Transaction Id Begin Time User
-------------- ------------------------ ---------
0000:00000335 2017/04/25 17:53:41:187 Anvesh
*/

I am sharing one of the very common and important Interview Questions separately so that SQL Server DBAs can recognize very easily before going for SQL DBA Interview.

The question itself is one kind of common problem which is facing by many of SQL DBAs. When SQL Server transaction log full, they are getting an error like “SQL Server Error 9002 transaction log full”.

When an interviewer asks this question to you, you should give a very clear answer with a just list of few options. If they ask more, only you should explain in details; otherwise, it is OK.

Your answer should be like this,
If we got error 9002 transaction log full, we should take following points:

• We should take backup the transaction log file and truncate the transaction log
• We can move log file to another disk drive
• We can increase the size of log file
• We can also add a new transaction log file in separate disk

I am not sharing more details on each point. If you want, you should prepare it for yourself, but I would suggest avoiding detail answer because you need to prepare different commands for all the options.

SQL Server provides different types of database auditing option like: CDC, Database Audit.
Recently, I have shared one article about, change your database DDL changes using Encrypted DDL triggers.

SQL Server: Encrypted DDL Trigger to Track all Database Changes

Database Administrators are responsible for database security and Periodically, They have to track all the database related changes and make sure that everything is working fine.

But still sometimes, I used to track database changes from the SQL Server log files using fn_dblog().
I am sharing one way to find a person who dropped a table and also can get the name of that dropped table without enabling any auditing option of SQL Server.

Script to find the log of dropped objects:

Using this script, you can find a list of dropped tables and login name information, but you cannot get table name directly.
You can find the transaction id for each record and using this transaction ID, you can find the table name.

SELECT 
	[Transaction Id]
	,[Begin Time]
	,SUSER_SNAME ([Transaction SID]) AS [LoginName] 
FROM fn_dblog (NULL, NULL)  
WHERE [Transaction Name] = N'DROPOBJ';

Find Table name using TransactionID:

SELECT TOP 1 
	[Lock Information] 
FROM fn_dblog (NULL, NULL)  
WHERE [Transaction Id] = '0000:0015d6b3'  
AND [Lock Information] LIKE '%SCH_M OBJECT%';

The result:
To get the table name, you can copy the number and search into sys.objects table.

HoBt 0:ACQUIRE_LOCK_SCH_M OBJECT: 8:1015674666:0

Find your dropped table:
Please do not start to search your dropped table in your current database because Table already dropped.
You must restore the last backup of the database and you should search your dropped table in that database.

SELECT *FROM sys.objects 
WHERE Object_ID ='1015674666'

In this post, I am sharing the basic purpose of pg_log, pg_clog and pg_xlog log directories in PostgreSQL.

If you look into your PostgreSQL data directory, you can find a different type of log folders.

pg_log:

This is a default database logs like: error messages, executed query log, dead lock information, Postgers start/stop messages.

First, you should look into this folder for any investigation. Most of the time we are getting an error because of bad queries or wrong configuration so in these cases we can find the important log messages from this folder.

You can also delete unwanted or old log files because It stores only database action related messages which are not critical for PostgreSQL Server.
There are a few parameters in Postgres.conf file related to pg_log folder, you access below article for this.

PostgreSQL: Important Parameters to enable Log for all Queries

pg_clog:

We cannot read log files of this folder because it is for PostgreSQL internals. It contains logs for transaction metadata. PostgreSQL server access this folder to take the decision like which transaction completed or which did not.

This is critical log folder, you should never forget this folder during your pg_data directory backup.

pg_xlog:

At all the times, PostgreSQL maintains a write-ahead log (WAL) in the pg_xlog/ subdirectory of the cluster’s data directory. The log records for every change made to the database’s data files. These log messages exists primarily for crash-safety purposes.

It contains the main binary transaction log data or binary log files. If you are planning for replication or Point in time Recovery, we can use this transaction log files.

We cannot delete this file. Otherwise, it causes a database corruption. The size of this folder would be greater than actual data so If you are dealing with massive database, 99% chance to face disk space related issues especially for the pg_xlog folder.

But don’t worry, There are multiple ways to optimize pg_xlog folder by removing old WAL files.