TEMPDB – INTERNALS AND USAGE

AGENDA Why is tempdb so special? Myths regarding table variables Spill warnings Logging modifications for tempdb Caching tables

WHY IS TEMPDB SO SPECIAL? Everyone can and will use it It can be used intentionally, none intentionally and even without our knowledge It is the also used as the SQL Server’s developers as their “junk yard”

WHY IS TEMPDB SO SPECIAL? It’s logging and table creation mechanism differ from other database’s Whenever the servers goes down, all data in tempdb is lost

TEMPORARY TABLE VS. TABLE VARIABLE In the procedures and batches we can use 2 types of objects: Temporary table Table variable Both objects are created in tempdb as tables

MYTHS REGARDING TABLE VARIABLES For very few records table variable will always perform better then temporary table Operations on table variable don’t get logged Table variable’s data is written to memory only and temporary table’s data is written to disk only

DEMO 1 Show that temporary tables and table variables are created as user tables in tempdb Checking all the myths that were discussed

TEMPORARY TABLE VS. TABLE VARIABLE Which type of object should we use? For me the default choice is temporary table. I’ll use table variable only in very rare cases

USING TEMPDB NOT INTENTIONALLY Sometimes the server uses the tempdb for executing a select query. This happens mainly because of 2 reasons: The server doesn’t have enough memory The server misevaluates the needed memory to run a query.

TEMPDB AND SPILL WARNING Such state is called spill Unfortunately spill warnings are very hard to detect

DEMO 2 Creating spill with a select query Check how to find out about spill

TEMPDB AND LOGGING Like every database, tempdb also uses logging Logging is needed for: Rollbacks Recovery

TEMPDB AND LOGGING TempDB should handle rollback TempDB should not handle recovery nor roll-forward Because TempDB has different needs from logging, it has different logging from other databases: Many times Inserts and updates on tempdb log only the “before state” Many times the “logging” is done in memory only

TEMPDB AND LOGGING Checkpoint doesn’t write tempdb’s data to disk. If a DBA runs the command checkpoint, it will write tempdb’s data to the disk. Lazywriter does write tempdb’s data to disk.

DEMO 3 TempDB and logging

CACHING TABLES Whenever the code has local temporary table or table variable, a table is created in tempdb Creating a table is a big task System tables have to be updated regarding the table itself, columns, indexes and constraints The table has to get pages allocated to it

CACHING TABLES TempDB has a mechanism to cache tables The server caches: some of the system table entries 2 pages and IAM page and data page

CACHING TABLES Limitations of tables caching There is no support for batches. Table creation has to be in procedure, function or trigger You can not modify the table after its creation You can not give the table’s constraints name

DEMO 4 CACHING TABLES

SUMERY The myths regarding table variables being always in memory, not logged and outperform temporary tables if there are “few records” are not true. Be aware of spill errors When working with temporary tables, avoid modifying them after the table’s creation.

Thank You For Listening