Causes for Tempdb Full

========================

Causes:

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 resultsets 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;

7) use of an ODBC DSN with the option 'create temporary stored procedures' set
can leave objects there for the life of the connection.

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

------------------------------

USE tempdb
GO
EXEC sp_spaceused

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 name
FROM tempdb..sysobjects

SELECT OBJECT_NAME(id), rowcnt

 FROM tempdb..sysindexes
WHERE OBJECT_NAME(id) LIKE '#%'
ORDER BY rowcnt DESC

Short-term fix:
--------------------

Restarting SQL Server will re-create tempdb from scratch, and it will return to its
usually allocated size. In and of itself,
this solution is only effective in the very short term; assumedly, the application
and/or T-SQL code which caused tempdb to grow once,
will likely cause it to grow again.

To shrink tempdb, you can consider using DBCC ShrinkDatabase,

-----------------------------------------------

DBCC ShrinkFile (for the data or the log file), or ALTER DATABASE. See KB #256650,
KB #272318 and KB #307487 for more information.

If you can't shrink the log, it might be due to an uncommitted transaction. See if
you have any long-running transactions with the following command:

DBCC OPENTRAN -- or DBCC OPENTRAN('tempdb')

Check the oldest transaction (if it returns any), and see who the SPID is (there
will be a line starting with 'SPID (Server Process ID) : <number>').

Use that <number> in the following:

DBCC INPUTBUFFER(<number>)

This will tell you at least a portion of the last SQL command executed by this
SPID, and will help you determine if you want to end this process with:

KILL <number>.

Long-term prevention
-------------------------

Here are some suggestions for maintaining a healthy tempdb:

Make sure that tempdb is set to autogrow -- do *NOT* set a maximum size for
tempdb. If the current drive is too full to allow autogrow events, then buy a
bigger drive,

or add files to tempdb on another device (using ALTER DATABASE) and allow those
files to autogrow. You will need at least one data file and at least one log file
in order to avoid this problem from halting your system in the future.

For optimal performance, make sure that its initial size is adequate to handle
a typical workload (autogrow events can cause performance to suffer as it allocates
new extents). For an approach to setting a non-default size for tempdb, see the
suggestion from Dinesh at http://www.tkdinesh.com/faq/ans/tempdbsh....

If possible, put tempdb on its own physical disk, array or disk subsystem (see
KB #224071 for more information).
 To prevent tempdb log file growth, make sure tempdb is in simple recovery mode
(this allows the log to be truncated automatically). To check if this is the case:

-- SQL Server 7.0, should show 'trunc. log on chkpt.'

-- or 'recovery=SIMPLE' as part of status column:

EXEC sp_helpdb 'tempdb'

-- SQL Server 2000, should yield 'SIMPLE':

SELECT DATABASEPROPERTYEX('tempdb', 'recovery')

---------------------------------------------------

If the database is not set to simple recovery, you can force it so as follows:

ALTER DATABASE tempdb SET RECOVERY SIMPLE

------------------------------------------------

====>

Make sure that TempDB is set to autogrow and do not set a maximum size for TempDB.

If the current drive is too full to allow autogrow events, then arrange a bigger
drive,

or add files to TempDB on another device (using ALTER DATABASE as described below
and allow those files to autogrow.

Move TempDB from one drive to another drive. There are major two reasons why TempDB
needs to move from one drive to other drive.

1) TempDB grows big and the existing drive does not have enough space.

2) Moving TempDB to another file group which is on different physical drive helps
to improve database disk read, as they can be read simultaneously.

Follow direction below exactly to move database and log from one drive (c:) to
another drive (d:) and (e:).

Open Query Analyzer and connect to your server. Run this script to get the names of
the files used for TempDB.

USE TempDB
GO
EXEC sp_helpfile
GO

Results will be something like:

name fileid filename filegroup

size
-
- -
tempdev 1 C:Program FilesMicrosoft SQL ServerMSSQLdatatempdb.mdf PRIMARY
16000 KB
templog 2 C:Program FilesMicrosoft SQL ServerMSSQLdatatemplog.ldf NULL
1024 KB

along with other information related to the database. The names of the files are
usually tempdev and demplog by default.

These names will be used in next statement. Run following code, to move mdf and ldf
files.

USE master

GO

ALTER DATABASE TempDB MODIFY FILE

(NAME = tempdev, FILENAME = 'd:datatempdb.mdf')

GO

ALTER DATABASE TempDB MODIFY FILE

(NAME = templog, FILENAME = 'e:datatemplog.ldf')

GO

The definition of the TempDB is changed. However, no changes are made to TempDB
till SQL Server restarts.

Please stop and restart SQL Server and it will create TempDB files in new
locations.