TempDB is one of the lynchpin features of SQL Server, so understanding what it does and also being able to monitor it to troubleshoot any issues that arise should be a priority for aspiring database administrators.
To give you a head start, here is a brief overview of the purpose of TempDB and the options you have for keeping tabs on it.
A simple explanation
While you can get a more in-depth introduction to TempDB here, the most straightforward way to think of it is as the place where SQL databases keep information while it is being processed.
As the name suggests, it is a temporary storehouse for data, and can encompass information that is being leveraged by every query and routine within a given SQL Server ecosystem.
By its very nature, TempDB is not a permanent fixture of a database, but rather has a life cycle that is tied to the needs of the users and applications that are powered by SQL Server. This means that tables which are created and stored within it will only persist for as long as a given session lasts, before being removed.
Another aspect of its operation to bear in mind is that it is not a resource which can be backed up, and indeed SQL Server is specifically coded to prevent this.
An overview of monitoring and troubleshooting
Monitoring TempDB is vital because it is a single resource that is shared among all of the databases that are running within a given SQL Server instance. Since this can encompass many tens of thousands of databases, if there is a problem with TempDB then its negative connotations can be far-reaching.
Checking in on the way that the available storage space is being used by this facet of SQL Server should be a top monitoring priority for DBAs. If TempDB is not properly configured, then its size could spiral out of control and performance could suffer as a result.
Of course you could find that your storage resources are pushed to their limits even if configuration is carried out correctly, so by monitoring TempDB you should also be using your findings to plan ahead and invest in upgrades in advance of this becoming an issue. In turn this will allow your databases to grow without being encumbered artificially, while also reducing the likelihood of unplanned downtime.
Another thing to look out for is whether version store cleanup is operating as it should be. If it is not, then TempDB could become jammed with old data which is no longer needed by any processes, but has yet to be wiped away to make space for new objects.
In short, TempDB needs to be monitored and managed perpetually, preferably using specific SQL Server monitoring tools that can streamline this process and automate many of the major facets. While it may not need as much intervention as other aspects of SQL Server, if it encounters issues then the problems caused will be far more severe.
