In a user database, the transactions have the ACID attributes: atomicity, concurrency, isolation, and durability whereas in the tempdb database the transactions lose the durability attribute which basically means that they do not persist after a SQL Server shut down event. Most of these internal operations on tempdb do not generate log records as there is no need to roll back. So, these operations are faster. Furthermore, some of the database options cannot be modified for tempdb and others are limited or restricted. Here they are:
- Auto Shrink is not allowed for tempdb.
- Database Shrink and File Shrink capabilities are also limited.
- The database CHECKSUM option cannot be enabled.
- A database snapshot cannot be created on tempdb.
- DBCC CHECKALLOC and DBCC CHECKCATALOG are not supported.
- Only offline checking for DBCC CHECKTABLE is performed.
Tempdb Space Usage: The following types of objects can occupy tempdb space: Internal Objects, Version Stores, and User Objects.
Internal Objects: Internal Objects metadata is stored in memory (it means that the metadata is hidden in the tempdb and it does not appear in catalog views such as 'sys.all_objects') and each of them occupies at least nine pages (one IAM page and eight data pages) in tempdb. Page Allocations and Update operations on it does not generate log records. The Internal Objects are used
- to store intermediate runs for sort
- to store intermediate results for hash joins and hash aggregates
- to store XML variables or other large object (LOB) data type variables (text, image, ntext, varchar(max), varbinary(max), and all others)
- by queries that need a spool to store intermediate results
- by keyset cursors to store the keys
- by static cursors to store a query result
- by Service Broker (Query Notification and Event Notification) to store messages in transit
- by INSTEAD OF triggers to store data for internal processing
- by DBCC CHECKDB (it internally uses a query that may need to spool intermediate results)
Version Stores: They do not appear in catalog views such as 'sys.all_objects'. Here are more concepts:
- Version stores are used to store row versions generated by transactions for features such as snapshot isolation, triggers, MARS (multiple active result sets), and online index build.
- The online index build version store is for row versions from tables that have online index build operations on them.
- The common version store is for row versions from all other tables in all databases.
- The version store consists of append-only store units which are highly optimized for sequential inserts and random look up. Inserts into the version store do not generate log records.
- Each unit can store many row versions. If there are versions to be stored, a new store unit is created about every minute.
In the following cases the versions of rows are generated for
- SNAPSHOT isolation and read committed snapshot isolation (the versions are generated by DML operations in the database when the respective database options are enabled)
- AFTER triggers (the versions are generated for all the update operations by the transaction that fired the trigger during the INSERT, DELETE, or UPDATE statement in any database, independent of database options. INSTEAD OF triggers do not generate versions)
- MARS (the versions are generated by the UPDATE or DELETE statement when there is a pending SELECT on the same transaction and the same connection)
- building an ONLINE index
- The 'sp_spaceused' system stored procedure can show the size occupied by these objects.
- User Objects include both user-defined tables and indexes, and system catalog tables and indexes.
- Operations on User Objects in tempdb are mostly logged. Bulk copy program (BCP), bulk insert, SELECT INTO, and index rebuild operations are bulk logged.
- User-defined tables include the global temporary tables such as ##t, and local temporary tables such as #t.
- Local temporary tables also include table variables such as @t and the mapping index for online clustered index build with the SORT_IN_TEMPDB option.
- The tempdb logging optimization avoids logging the “after value” in certain log records in tempdb.
- Instant data file initialization works by not zeroing out the NTFS file when the file is created or when the size of the file is increased.
- There is less use of the UP type page latch when allocating pages and extents in tempdb. Proportional fill has been optimized to reduce UP latch contention.
- Proportional fill has been optimized to reduce UP latch contention.
- There is now deferred drop in tempdb.
- Worktable caching is improved.
- SQL Server 2005 or later caches the temporary table that is created by using a CREATE TABLE or SELECT INTO statement.
- The tempdb files must be configured with initial size and auto-growth based on your workloads. Do not let with the default sizes.
- The tempdb files must be located on RAID0 (for better performance) or RAID1 (if you need have more writes than reads) or RAID5 (if you have more reads than writes). RAID10 is the best option but no all companies can justify this.
- The tempdb files must be located on separated disks to avoid contention issues and improves the performance.
- Tempdb database must be created with one data file per physical processor if the quantity of CPUs is eight or less. If there are more then eight CPUs then you can start off with eight data files and after increase the number of files by four in case there was PAGELATCH contentions on one of the allocation bitmap pages (including PFS pages, GAM pages and SGAM pages) until the issue is solved, if not, add four files more, and so on.
- Do not forget, tempdb data files or log file should not grow so much in a short time, if this happens then something is working wrong, so you need to analyze the workloads performance and detect the query that you have to optimize.