SQL SERVER – TDE Effects on TempDB’s Slow Performance

I am a big supporter of the fact that testing and playing with new features should not be done on production environments. It can prove to be harmful, even after you tried to clean up the system. Sometimes we are not sure what the impact of our acts can lead to. In a recent consulting engagement, I figured this out the hard way. I was brought in for slow performance suddenly and we were not sure what was happening in the system. I love tough challenges and this was no different.

Let me set some context to the learning? SQL Server 2008 introduced the concept of TDE and I was a huge supporter of using in several financial institutions. This was a capability that helped you take care of encrypting the data at rest. What this did was, in case you lost your backups or tapes it would be humanly impossible to restore the same if you don’t have the encrypted key.

To know if a database is encrypted, you will need to know from the DMV sys.databases – as shown below.

SQL SERVER - TDE Effects on TempDB's Slow Performance TDE-overhead-01-800x387

Solarwinds

Make sure you keep checking this DMV from time to time, take the encryption key backups. Having said that, make sure you don’t store the certificate along with the backups as you are prone to data theft. As a golden rule, don’t store the backups and the keys on the same device.

Coming back to my earlier customer scenario, the server was slow because strangely the tempdb related operations were getting slower. My first instinct was to figure out if any of the databases had enabled TDE. Strangely, everything seemed to be fine and none of the databases had this value set.

On deeper inspection with the default trace, I found something interesting. To know what I did, check: SQL SERVER – Who Dropped Table or Database?

This is when I realized one of the DBA’s was playing with the production environment. He was playing and testing TDE.

This is when I had to tell the customer that once TDE is enabled on a user database, TempDB is permanently encrypted. Even after you remove the encryption or drop the database you used for testing, this encryption overhead on TempDB is not removed. This is a great learning in my opinion. Do not ever play or test in your production environments. Make sure you read the documentation well and understand the outcome of your acts.

As I wrap up, let me know of you are one of the users of TDE. How many databases have you enabled TDE on? Did you know the effect of TempDB? Do let me know via comments below.

Reference: Pinal Dave (https://blog.sqlauthority.com)

Solarwinds
, , , ,
Previous Post
SQL SERVER – CLONEDATABASE: Generate Statistics and Schema Only Copy of the Database
Next Post
SQL Server Performance Tuning Practical Workshop – Notes and Thoughts

Related Posts

9 Comments. Leave new

  • How to remove encryption from temple?

    Reply
  • Seams like a bug. With TempDB being recreated during SQL Server startup, there should be a check to see if TDE is in use and act accordingly when creating the new TempDB.

    Reply
  • Tempdb is recreated every time SQL starts. I would think this would remove the encryption if the option is disabled.

    Reply
  • How you get to know that TDE is enable on TempDB

    Reply
  • Wilfred van Dijk
    January 12, 2017 2:46 pm

    What’s the difference between the columns “is_encrypted” and “is_master_key_encrypted_by_server” in sys.databases?

    Reply
  • Hello Everyone,

    I tested on SQL Server 2016 and Tempdb database is still encrypted after disabling encryption for user database and bouncing the SQL Server service. Not sure if it happens to empower the DBA to turn ON or OFF encryption on user databases at any time. There is a connect item in place, you may vote it up.

    https://docs.microsoft.com/en-us/collaborate/connect-redirect

    Thank you.

    Reply
    • Thank you Pinal – That too from none other than Bob Ward :P

      On serious note, great post filled with detailed explanation and interesting approach.

      Great day !

      Reply
  • Based on the Bob Ward article, it seems that after a service restart, tempdb is no longer encrypted, even though sys.databases erroneously says it is. Were you able to resolve the client’s performance issue by restarting the service?

    Reply

Leave a Reply

Menu