Rajasekhar Reddy Bolla Email Id: rajasekharreddyb.dba@gmail.

com
Contact: +91 9966246368 (WhatsApp) YouTube Channel: https://bit.ly/35QYIiG

How to Shrink TempDB Without SQL Server Restart?

Sometimes it is not possible to shrink Tempdb directly. People blindly used to restart the SQL
Service. When you restart the service Tempdb Size will automatically become 0.
Without restarting service also, we are able to shrink the tempdb using the below method.
Restarting Services will cause the business down which is dangerous
Common reasons of Tempdb getting filled

1) Usually, tempdb fills up when you are low on disk space, or when you have set an
unreasonably low maximum size for database growth.

Many people think that tempdb is only used for #temp tables. When in fact, you can easily fill
up tempdb without ever creating a single temp table. Some other scenarios that can cause
tempdb to fill up:

1) any sorting that requires more memory than has been allocated to SQL Server will be forced
to do its work in tempdb;

2) if the sorting requires more space than you have allocated to tempdb, one of the above
errors will occur;

3) DBCC CheckDB('any database') will perform its work in tempdb -- on larger databases, this
can consume quite a bit of space;

4) DBCC DBREINDEX or similar DBCC commands with 'Sort in tempdb' option set will also
potentially fill up tempdb;

5) large result sets involving unions, order by / group by, cartesian joins, outer joins, cursors,
temp tables, table variables, and hashing can often require help from tempdb;

6) any transactions left uncommitted and not rolled back can leave objects orphaned in
tempdb;

The following will tell you how tempdb's space is allocated:

USE tempdb

GO

EXEC sp_spaceused
Rajasekhar Reddy Bolla Email Id: rajasekharreddyb.dba@gmail.com
Contact: +91 9966246368 (WhatsApp) YouTube Channel: https://bit.ly/35QYIiG

The following should give you some clues as to which table(s) consume most of the space in the
data file(s) --this will help you narrow down any transactions that are either taking a long time
or repeatedly being left in limbo:

USE tempdb

GO

SELECT * FROM tempdb..sysobjects

What you need to do, when Tempdb not able to shrink?

Run below query

USE [TEMPDB];
GO
CHECKPOINT;
GO
DBCC DROPCLEANBUFFERS;
GO
DBCC FREEPROCCACHE;
GO
DBCC FREESYSTEMCACHE ('ALL');
GO
DBCC FREESESSIONCACHE;
GO
DBCC SHRINKFILE (TEMPDEV, 1024) –use script mention at the last
GO

DBCC DROPCLEANBUFFERS

Clears the clean buffers. This will flush cached indexes and data pages. You may want to run a
CHECKPOINT command first, to flush everything to disk.

CHECKPOINT;
GO
DBCC DROPCLEANBUFFERS;
GO
DBCC FREEPROCCACHE
Rajasekhar Reddy Bolla Email Id: rajasekharreddyb.dba@gmail.com
Contact: +91 9966246368 (WhatsApp) YouTube Channel: https://bit.ly/35QYIiG

Clears the procedure cache, which may free up some space in tempdb, although at the expense
of your cached execution plans, which will need to be rebuilt the next time. This means that ad-
hoc queries and stored procedures will have to recompile the next time you run them.
Although this happens automatically, you may notice a significant performance decrease the
first few times you run your procedures.

DBCC FREEPROCCACHE;
GO
DBCC FREESYSTEMCACHE

This operation is similar to FREEPROCCACHE, except it affects other types of caches.

DBCC FREESYSTEMCACHE ('ALL');
GO
DBCC FREESESSIONCACHE

Flushes the distributed query connection cache. This has to do with distributed queries (queries
between servers), but I’m really not sure how much space they actually take up in tempdb.
DBCC FREESESSIONCACHE;
GO

How to shrink?
DBCC SHRINKFILE is the same tool used to shrink any database file, in tempdb or other
databases. This is the step that actually frees the unallocated space from the database file.
Don’t set the new size too low! Make a realistic estimate of the largest “normal” size that
tempdb will assume during normal day-to-day operation.
That’s it. If everything works the way it should, you should now be able to verify the new size of
tempdb.
Warning: Make sure you don’t have any open transactions when running DBCC SHRINKFILE.
Open transactions may cause the DBCC operation to fail, and possibly corrupt your tempdb!

--Change the size in MB to shrink to---

DECLARE @size NVARCHAR(10) = 1024
DECLARE @info nvarchar(max)
DECLARE @file nvarchar(max)
DECLARE @q1 nvarchar(max)
Rajasekhar Reddy Bolla Email Id: rajasekharreddyb.dba@gmail.com
Contact: +91 9966246368 (WhatsApp) YouTube Channel: https://bit.ly/35QYIiG

DECLARE tempdb_cursor cursor for

SELECT NAME FROM sys.master_files WHERE database_id = 2 AND NAME !='templog';
OPEN tempdb_cursor
FETCH NEXT FROM tempdb_cursor into @info
while @@fetch_status = 0
BEGIN
SET @info = @info
SET @q1 = 'USE [tempdb] DBCC SHRINKFILE (''' + @info + ''' , ' + @size + ')'
--EXEC @Q1
PRINT @q1
FETCH NEXT FROM tempdb_cursor
INTO @info
END
CLOSE tempdb_cursor;
DEALLOCATE tempdb_cursor;

A word about shrinking database files

Best practice is to try to minimize the use of file or database shrinking as much as possible.
Whenever you shrink a database file and it re-grows later on, you are potentially creating
fragmentation on your physical storage medium. This is because the sectors that the file used
to occupy may now very well be occupied by other information (just a few bytes are enough).
When SQL Server wants to grow that database file, the newly added portion of the file will need
to be placed elsewhere on the disk, thus creating fragmentation.
The number one mortal sin in this context is “autoshrink“, because it may very well add to the
drive fragmentation every time it runs, which could be very frequently.
As a rule of thumb, never ever autoshrink a database. And try to be very restrictive when it
comes to shrinking databases or files in general, unless it’s a one-off operation to fix the
aftermath of a runaway query.