How to resolve/ fix Orphaned users from SQL Database.

 Below is a small snippet of cursor created to identify all the users who have the flag of IsSQLUser except for SID not Null & SID <> 0X0 (because they dbo, Guest, Information_Schema & sys accounts) and run Auto fix the orphaned users.

DECLARE @USRNAME VARCHAR(100), @COMMAND VARCHAR(100)
DECLARE CURSORS INSENSITIVE CURSOR FOR

SELECT NAME AS USERNAME FROM SYSUSERS
WHERE ISSQLUSER = 1 AND (SID IS NOT NULL AND SID <> 0X0)
AND SUSER_SNAME(SID) IS NULL ORDER BY NAME

FOR READ ONLY

OPEN CURSORS
FETCH NEXT FROM CURSORS INTO @USRNAME
WHILE @@FETCH_STATUS=0
BEGIN
SELECT @COMMAND='SP_CHANGE_USERS_LOGIN ''AUTO_FIX'', '''+@USRNAME+''' '
EXEC(@COMMAND)
FETCH NEXT FROM CURSORS INTO @USRNAME
END

CLOSE CURSORS

DEALLOCATE CURSORS.

How To Shrink The TEMPDB Database in SQL SERVER ?

Occasionally, Every DBA will bump across this issue, Tempdb database is getting full, Tempdb Drive has exceeded the disk threshold and need to take action to reduce the file size.

DBAs having little experience would think of shrinking the database using the GUI, Right Click on the Database > Tasks > Shrink > Database / Files and then shrink the database accordingly.

DBAs with some experience would think of running the command DBCC Shrinkfile ('Filename', target_in_MB)

However, with both the Solutions / Steps,  files / database doesn't shrink  and you can see that the file size is not having any impact.

So, here  is a couple of solutions you can try to shrink the Tempdb database and reduce the size on the drive accordingly.

1.  Try running the following command :-

USE TEMPDB
GO
DBCC FREEPROCCACHE
GO
DBCC FREESESSIONCACHE
GO
DBCC FREESYSTEMCACHE ('ALL')
GO

and then run the command.

DBCC SHRINKFILE ('FILENAME', TARGET_SIZE_IN_MB)
GO

If there are more than one Tempdb data ( Tempdev )  file , you can use those files seperately to run the DBCC Shrinkfile command to shrink the file size after clearing the DBCC System , Session and Proc Caches

These are the DBCC commands to free up some of the SQL SERVER Memory Caches.

DBCC FREESYSTEMCACHE ('ALL')
Clears all unused cache entries from all the caches.

DBCC FREESESSIONCACHE
Flushes all the distributed query connections' cache that are used against the instance of Microsoft SQL Server.

DBCC FREEPROCCACHE
Clears all elements from the procedure cache.
Freeing the procedure cache would cause, an ad-hoc SQL statement to be recompiled rather than reused from the cache.


2.  Here's another solution which can help to shrink the tempdb database.

Add a few MB to the data file and then try shrinking the file., it will release some space to the OS.

For Example:- when you find the tempdb is growing and has a couple of hundreds of MBs to reach the threshold. You can try shrinking the database normally. If there's any bulk transaction running against the instance or If there's a replication set up on the database.
Then, you can increase the tempdb data file to a few MBs and then try shrinking the file using the DBCC command to claim more space.

Troubleshooting the 'KILLED/ROLLBACK' sessions in SQL Server

One of the not so frequent issues encountered off lately which doesn't has any other solution than to restart the SQL Service ( Recycling ) is when you have the Command status as 'KILLED/ROLLBACK' for any of the sessions in sysprocesses.

The Command of the sysprocesses session 'KILLED/ROLLBACK'  happens when there's any DML ( INSERT , UPDATE, DELETE ) activity happening against any database and it is being interrupted or killed before the process is complete.

Some of the scenarios where u might encounter this situation :-

1.    Database backup using any third party software is taking longer than expected and the process is being killed. This session will lead to 'Killed/Rollback' status.
2.    Any DML statement running via linked server connecting from another server and the process is being killed from either end will lead to the 'Killed/Rollback' Status.
3.    Any DMLs being killed from the application end before the process completes, will lead the process to 'Killed/Rollback' State.

To determine which process is hung or in the state of 'Killed/Rollback' , You can use the following commands :-

SP_Who2

OR

SELECT spid
,kpid
,login_time
,last_batch
,status
,hostname
,nt_username
,loginame
,hostprocess
,cpu
,memusage
,physical_io
FROM sys.sysprocesses
WHERE cmd = 'KILLED/ROLLBACK'

After figuring out the spid and kpid, run the DBCC INPUTBUFFER (<SPID>) to know what is the batch running under this session.

There are a few blogs recommending to kill the kpid session from the task manager.
** Please be careful about what you are doing. This is not recommended, especially,If there's any third party tool involved in the process. You may hang the third party tool's service as well, while trying to kill this session from the task manager**.

You can use this technique of killing the kpid to release the session, If there's any stored procedure or a batch running against the database directly and due to some reasons it was killed and the session moved to 'Killed/Rollback' status, that should work., However, that's never going to be the case.

So, we can try using the below command to see the status of the session.

KILL  <SPID>  with STATUSONLY

If you would get the output message as follows :-
   
SPID <spid> : transaction rollback in progress. Estimated rollback completion: 100%. Estimated time remaining: 0 seconds.

Only if you find the percentage complete is any number other than 0% or 100% and the time remaining is other than 0 or 554 seconds, only then, you still have a hope of getting this command completed by the time displayed, else, this process can go on hung until you restart the SQL Server service.

If there's a linked server or replication process involved in this session, here's what we can do :-

Try restarting the DTC ( Distributed Transaction Coordinator) service, which could release the session from 'Killed/Rollback' Status.

This could work if there's any Linked Server or Replication service involved in the process, OR, if there's any application triggered stored procedure which was closed from the front-end before the transaction committed.

Considering this issue occurring on the Production server where you would not have the leverage of restarting the SQL Server Service frequently.

There's one more option which you could try before giving up or concluding to restarting the SQL Server service :-

KILLING THE PROCESS USING THE Dedicated Administrator's Connection (DAC).

You need to have the DAC enabled / activated before your can think of using this option.

So, if we have the DAC enabled and if you are able to connect to the DAC session, Please go ahead and run the appropriate queries to determine the spids associated with the command 'KILLED/ROLLBACK' and kill them. This could resolve the issue.

If the above said scenarios or options didn't work for you, please don't think anything else, go ahead and have the SQL Service restarted to release these sessions.