Back in November of 2008, I blogged on the topic of Transparent Data Encryption (TDE) and its affects on the tempdb database. Within that post I mentioned that the tempdb is dropped and recreated when the instance of SQL Server is restarted. Through the process of restarting an instance and reviewing the tempdb and its accompanying database encryption key, an anomaly was discovered. Here is the scenario:
On an instance of SQL Server that contained a database that had TDE enabled, I stopped the instance by right-clicking on the instance within SQL Server Management Studio (SSMS) and clicked on the "stop" option. Once the instance stopped, I started it again by right-clicking the instance and clicked the "start" option.
I queried the sys.databases catalog view to reveal the create date of my tempdb:
SELECT
name,
create_date
FROM
sys.databases
WHERE
name = 'tempdb';
The results of this query revealed that the current version of the tempdb was created on:
2009-09-01 21:16:26.623
I then queried the sys.dm_database_encryption_keys dynamic management view (DMV) for the database encryption key that is used to protect the tempdb database:
SELECT
database_id,
create_date
FROM
sys.dm_database_encryption_keys
WHERE
database_id = 2;
The results of this query revealed that the current version of the tempdb database encryption key was created on: 2009-09-02 01:16:18.583
At first glance, the difference in the date might give appeared to contradict the understanding that the database encryption key is recreated as the tempdb is recreated during an instance restart; but with closer inspection I noticed that the create date of the encryption key is in the future!
I thought to myself "It's astounding. Time is fleeting. How could this be?"
My recent encounter of converting my time zone, Eastern Standard Time (EST), to Greenwich Mean Time (GMT) revealed that this five hour difference was familiar.
With a jump to the left, and a step to the right, this baffling time warp was cracked. The sys.databases catalog view reflects the time based off of the time zone that has been defined on your server, in my case EST, while the sys.dm_database_encryption_keys DMV utilizes GMT; therefore, the understanding is confirmed: the tempdb database encryption key is recreated along with the recreation of the tempdb database when the instance is restarted.