Category: DBA Utilities

How to recover restoring database in SQL Server

At times, we end up with situations like databases suddenly goes into restoring state and becomes not accessible. Few cases those are valid like mirror database in a database mirroring or removed database from AlwaysOn etc. Today, we are not discussing about those valid cases, but as outcome of an incident or unfortunate db state change.

If you happened to see a database in restoring and you want to get it online, you can simply restore with recovery as below.

use master
restore database << dbname >> with recovery

In most cases, the db would get online immediately. Sometimes, it might give you an error message as below:

Msg 4333, Level 16, State 1, Line 3 The database cannot be recovered because the log was not restored. Msg 3013, Level 16, State 1, Line 3 RESTORE DATABASE is terminating abnormally.

If you result with the above error message, then we should understand that the particular database is not restored in a proper way. May be. the restore process would have terminated due to network issues or cancelled the restore part way through etc. Such database cannot be brought online. The best way would be to drop the database and restore from the backup.

restore database << dbname >> from disk ='<filepath>\<backup filename>'

It is important to have a valid database available for us to quickly get this db online. So ensuring the backup is important as always, hope we all will have a good backup plan in place by default, if not, that should be the first priority item.

I’d like to grow my readership. If you enjoyed this blog post, please share it with your friends!

How to Repair Database in Suspect Mode in SQL Server

Today, one of my colleague reached out to me that one of her database has gone into SUSPECT mode. She explained that while she was deploying the db changes, there was an unexpected shutdown happened on the server. While rebooting the server, it is observed the database has gone into SUSPECT mode.

Primary reasons when an SQL Server Database is marked in Suspect Mode

There may be many reasons for a db is getting into a SUSPECT mode. This is the worst case for any database can get as this would lead the database unusable.Here are few reasons I could think immediately, but there could be many other reason, feel free to add in the comment section if I miss anything.

    SQL Server Crash

    Database Files are inaccessible

    Improper shut down of SQL Server System

    Sudden Power Outage

    Hardware Failure etc.

Steps to Fix the SQL Server Database Suspect Mode Error

There are many articles on how to repair a SUSPECT db out there on a google search.

    Bring Database in EMERGENCY MODE

    Perform Consistency Check – DBCC CHECKDB

    Bring the Database in SINGLE_USER Mode with rollback immediate

    Take a Full Backup of the User Database

    Execute DBCC CHECKDB WITH REPAIR ALLOW DATA LOSS (Note: It might result in Data Loss)

    Bring the Database in MULTI_USER Mode for normal operations

Now, Let us look at our specific issue. Firstly, we tried to get this database in EMERGENCY mode with the below T-SQL.Unfortunately, we did end up with an exception given below which is clearly saying that this db has got a severe consistency issue which cannot be used further.
User does not have permission to alter database ‘dbname’, the database does not exist, or the database is not in a state that allows access checks.
How to drop SUSPECT database?

As we identified that this database has severely corrupted and it cannot be repair nor recovered, there is no way other than dropping the database. If you have backup of this database, you can always do restore from the latest valid backup (even up to the point in time). But unfortunately, in our case, it will not even allow you to drop and it would end up with the above same error message for DROP as well.

So, how do we drop this db? Its bit tricky and needs some outage of SQL Server (since one of the step is stopping the service).
    Stop the SQL Server service.

    Rename the file (MDF or LDF or both) of this database.

    Start the SQL Server service.

    Drop the database.

Caveat: The above method is recommended on non- production environments generally.

I’d like to grow my readership. If you enjoyed this blog post, please share it with your friends!

How to read and write backup directory in SQL Server

There is a requirement for me to change the backup directory of a SQL Server instance. Here are few tips related to the sobject and hope it will be useful as a future reference for all of us.

How to read the value of BackupDirectory?


EXEC master.dbo.xp_instance_regread
            @path OUTPUT, 

How to write/set a new value of BackupDirectory?

EXEC master.dbo.xp_instance_regwrite
            N'\\\C$\data\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Backup';

Few other important information:

DECLARE @SQLDataRoot nvarchar(512)
DECLARE @DefaultData nvarchar(512)
DECLARE @DefaultLog nvarchar(512)

--Installation Root Info
EXEC master.dbo.xp_instance_regread 
Select @SQLDataRoot

-- SQL Data file Info
EXEC master.dbo.xp_instance_regread
@DefaultData OUTPUT
Select @DefaultData

-- SQL Default Default Log file info
EXEC master.dbo.xp_instance_regread
@DefaultLog OUTPUT
Select @DefaultLog
xp_instance_regread & xp_instance_regwrite are undocumented features, so it may be deprecated any time, however, can be used for non-production or DBA specific tasks at own discretion.

I’d like to grow my readership. If you enjoyed this blog post, please share it with your friends!

When was the database taken offline/online in SQL Server

Here is a script to identify when was the database taken offline/online and few other information like login name, host name and application name.


DECLARE  @DBNAME nvarchar(100)
  ,@FileName nvarchar(max)
  ,@Status nvarchar(10)
SET @Status = 'OFFLINE' --Provide [OFFLINE / ONLINE]
SELECT @FileName=[path] FROM sys.traces WHERE is_default=1

DECLARE @ErrorLogTable table (Logdate datetime, ProcessInfo nvarchar(10), [Text] nvarchar(max))

INSERT INTO @ErrorLogTable
EXEC xp_readerrorlog 0,1, @Status, @DBNAME, NULL, NULL, 'desc'

SELECT Distinct DatabaseID, DatabaseName, HostName, ApplicationName, LoginName, StartTime, B.ProcessInfo, B.Text
FROM sys.fn_trace_gettable( @FileName, DEFAULT ) A
Inner join @ErrorLogTable B on A.SPID = cast(SUBSTRING(B.ProcessInfo,5,5) AS int)
and CAST(StartTime AS nvarchar)=cast(B.Logdate AS nvarchar) 

I’d like to grow my readership. If you enjoyed this blog post, please share it with your friends!

A way to Shrink Data File in SQL Server

Problem Statement

We recently wanted to drop few obsolete tables those are really big ones in my SQL Server databases. Post clean up, meaning dropping the tables, we would like to reclaim the space it occupied to OS and reduce the cost associated with. What are the best options in such situations?

DBA’s Ponderings

Usually, DBAs would never support shrinking of data file due to several reason. They consider about their system performance than the disk cost, especially, now days, the worry on cost associated must be an outdated belief. Shrink can cause many bad on your databases and some of them are listed as below:

1. It increases the fragmentation.

2. It will have a system performance issues due to heavy fragmentation.

3. While running shrink a data file, it may have dangerous locking issues. This must be an offline activity.

4. If shrink file on a LOB data, that would slow down the process badly.

Due to all the above reasons, we should always keep a long distance to shrink file operations. Thats not our best friend for our system.

Then, How do we shrink data file?

Then, What we do if its mandatory to do shrink the data file as our initial Problem Statement?

If its mandatory or meaningful or sensible, then you can do with few extreme considerations. In one of my case, I had to clean up almost 1000 tables from a database and I had to do this for almost 2000 databases. It had almost 4GB data to be cleared from a single database resulting a whooping amount of cost save! This is a real example where shrink file is important or a valid reason to do so. Myself & one of my colleague “Pascal Benguigui” have come up with an approach here as below.

Let us look at the options/considerations to apply shrink file as below. It may vary for others, but its more of our deliberate thoughts.

1. Understand the size of data that you wanted to eliminate. To understand, I would suggest you to take backup and restore your database to local and remove the data followed by shrink file and then identify the current size of data file.

2. If the file size if more than 1000 MB, we can consider shrinkfile, otherwise, it may not be so efficient.

3. If the file size is more than 1000 MB, let us also consider the percentage of free space. If free space percentage is lesser than 10%, it may not be so efficient again.

4. Let us also shrink the file up to the used space and 10 percentage added to the space. This must be a good number, but depends!, it may or may not suitable for all cases. A detailed analysis can be carried out and define as per your environment leaving it to the respective DBA’s descretion.

Shrink Script

CREATE OR ALTER procedure Shrink_DataFile @db varchar(200)

declare @f_name varchar(200)
declare @f_file varchar(500)
declare @f_size int
declare @f_used int
declare @pct_free int
declare @f_newsize int
declare @sql_query nvarchar(2000)
declare @sql_param nvarchar(200)

print 'Datafile SHRINK requested on database ['+@db+'] : '
declare cur_name cursor for 
select name from sys.sysaltfiles where dbid=db_id(@db) and groupid=1 and CONVERT(sysname,DatabasePropertyEx(@db,'Updateability'))='READ_WRITE' order by fileid asc

open cur_name
fetch next from cur_name into @f_name

while @@fetch_status=0

       select @sql_param =N'@f_size_out int OUTPUT,@f_used_out int OUTPUT,@f_file_out varchar(500) OUTPUT'
       select @sql_query=N'use ['+@db+']; select @f_size_out=CAST(s.size/128.0 AS int) , @f_used_out=CAST(FILEPROPERTY(, ''SpaceUsed'')/128.0 AS int),@f_file_out=filename from sys.sysfiles s where groupid=1 and name='''+@f_name+''''
       EXEC sp_executesql @sql_query, @sql_param, @f_size_out=@f_size OUTPUT, @f_used_out=@f_used OUTPUT,@f_file_out=@f_file OUTPUT ;
       select @pct_free=(@f_size-@f_used)*100/@f_size

       if @f_size >1000 and @pct_free>10
             -- shrink should keep 10% free space and be a multiple of 100 higher
             select @f_newsize=@f_used*1.1
             select @f_newsize=ceiling(cast(@f_newsize as decimal(38,2))/100)*100
             if @f_newsize < @f_size
                    print 'File "'+@f_file+' (size '+convert(varchar,@f_size)+' MB) " will be shrinked to '+convert(varchar,@f_newsize)+' MB ...'
                    select @sql_query=N'USE ['+@db+']; 
                    DBCC SHRINKFILE (N'''+@f_name+''' , '+convert(varchar,@f_newsize)+')  WITH NO_INFOMSGS'
                    print @sql_query
                    exec sp_executesql @sql_query

                    select @sql_param =N'@f_size_out int OUTPUT'
                    select @sql_query=N'use ['+@db+']; select @f_size_out=CAST(s.size/128.0 AS int) from sys.sysfiles s where groupid=1 and name='''+@f_name+''''
                    EXEC sp_executesql @sql_query, @sql_param, @f_size_out=@f_size OUTPUT;
                    print '... New size for file "'+@f_file+'" shrinked is '+convert(varchar,@f_size)+' MB
                    print 'NO SHRINK : New size estimated for file "'+@f_file+'" ('+convert(varchar,@f_newsize)+' MB) not lower than the current file size ('+convert(varchar,@f_size)+' MB)'

             print 'NO SHRINK : Size requirements not valid to shrink file "'+@f_file+' (size '+convert(varchar,@f_size)+' MB / free space '+convert(varchar,@pct_free)+' %)

       fetch next from cur_name into @f_name
       close cur_name
deallocate cur_name

if @f_file is null
       print 'database ['+@db+'] not existing or not in READ-WRITE mode


Post shrinkfile, we would expect lots of fragmentations. This can severely impact the system performance. We need to make sure that we need to avoid fragmentation as quickly as possible by running INDEX rebuild/reorganize. There is a well defined index maintenance solution defined by Ola Hallengren that can be used for the same.

If you have to plan it for many number of databases, you need to consider this to happen in multiple batches to ensure that this process does not hurt the system. There may be a chance that your immediate backup jobs taking longer time than usual. Importantly, we need to make sure the shrink followed by index defragmentation is planned at application off peak hours, otherwise it might end up with larger number of blocking/locking scenarios.

I’d like to grow my readership. If you enjoyed this blog post, please share it with your friends!