TempDb is a system database available to all users and databases belonging to a SQL Server instance. As the name suggest is a temporary store. When TempDb LOG is growing too big or too fast (I've seen a log occupying 200GB - 97% full) obviously there is a problem with your database. Solutions that you may found on the net are:

• Shrink tempDB transaction log - using log backup for example, inside a job
• Restart SQL Server - that will recreate tempdb and tempdb log with default initial size

Both can be used just in the case you don't want to admit that your database has a problem. You should start looking first at the objects that generate excessive use of TempDb like:

• Triggers - yes, because inserted and deleted tables are created in TempDB
• Temporary Tables or Global Temporary Tables (e.g. CREATE TABLE #MyTemp(col1 INT)).
• Table variables (DECLARE @MyTemp TABLE (col1 INT)) - Yes they can be created in TempDB!
• XML - sp_xml_preparedocument creates a work table in tempdb.
• Queries can store intermediate results for joins, aggregates (GROUP BY) and sorting (ORDER BY).
• Cursors, where static type is the worse possible.

Note: Personally, I can't see any reason somebody would ever use a Global Temporary Table!

Use the following command to list all temp tables:

Output, like in the following image:

Easiest method to monitor the logs is to issue the following command:

Result looks like in the following picture, you are interested on line 2 :

As a conclusion, I would recommend 2 things:

• Review your code and try to reduce the use tempdb (see above who's using temp db).
• Estimate the amount of space required by tempdb database, and set initial values for it - we don't want extents.