Transparent Data Encryption (TDE)

SQLServerCentral Article

TDE BYOK and Geo-Replication in Azure SQL DB

  • Article

Recently a customer asked me for help with setting up a test of an Azure SQL Database in the single database tier with Geo-Replication to work with Transparent Data Encryption (TDE) with a customer-managed key, also known as Bring Your Own Key (BYOK). It is very simple to do it when you use service-managed keys, […]

(3)

You rated this post out of 5. Change rating

2020-07-21

2,541 reads

Stairway to TDE icon

Restore a Backup of a TDE Database to Another Server: Level 2 of the Stairway to TDE

  • Stairway Step

In the second level of the stairway to TDE, we examine how you can restore your databases on another instance after moving the encryption certificate.

(3)

You rated this post out of 5. Change rating

2024-06-26 (first published: )

53,258 reads

Stairway to TDE icon

Transparent Data Encryption Using Certificates and EKM - Level 1 of the Stairway to TDE

  • Stairway Step

The first level of the Stairway to TDE will explain how the feature works and how to set this up on one of your instances and databases.

(3)

You rated this post out of 5. Change rating

2024-06-26 (first published: )

11,308 reads

SQLServerCentral Article

6 steps to a more secure SQL database

  • Article

Security is often something people think about only after they have had a problem. Given that the average cost of a data breach is $3.92 million (SecurityIntelligence 2019) and ransomware attacks have increased 97% over the past 2 years (PhishMe 2019), the "if it's not broke, don't fix it" approach can clearly be catastrophic. Here […]

(2)

You rated this post out of 5. Change rating

2019-10-07

9,364 reads

SQLServerCentral Article

Key Rotation in TDE

  • Article

Transparent Data Encryption (TDE) has been around for a long time. It first appeared in SQL Server 2008, and after a rocky start with some bugs, it has become a regularly used feature for many organizations. While not perfect, it does provide some protection and auditors like to see physical protection features being used. It's […]

You rated this post out of 5. Change rating

2019-08-29

15,308 reads

Blogs

Why Optimize CPU for RDS SQL Server is a game changer

By

One feature that I have been waiting for years! The new announcement around optimize...

Performance tuning KubeVirt for SQL Server

By

Following on from my last post about Getting Started With KubeVirt & SQL Server,...

T-SQL Tuesday #193 – A Note to Your Past, and a Warning from Your Future

By

I haven’t posted in a while (well, not here at least since I’ve been...

Read the latest Blogs

Forums

Refactoring SQL Code

By Steve Jones - SSC Editor

Comments posted to this topic are about the item Refactoring SQL Code, which is...

The Read Committed Snapshot Isolation behaviour

By Alessandro Mortola

Comments posted to this topic are about the item The Read Committed Snapshot Isolation...

Working with JSON/JSONB Data in PostgreSQL using Python

By sabyda

Comments posted to this topic are about the item Working with JSON/JSONB Data in...

Visit the forum

Question of the Day

The Read Committed Snapshot Isolation behaviour

I am currently working with Sql Server 2022 and AdventureWorks database. First of all, let's set the "Read Committed Snapshot" to ON:

use master;
go

alter database AdventureWorks set read_committed_snapshot on with no_wait;
go
Then, from Session 1, I execute the following code:
--Session 1
use AdventureWorks;
go

create table ##t1 (id int, f1 varchar(10));
go

insert into ##t1 values (1, 'A');
From another session, called Session 2, I open a transaction and execute the following update:
--Session 2
use AdventureWorks;
go

begin tran;
update ##t1 
set f1 = 'B'
where id = 1;
Now, going back to Session 1, what happens if I execute this statement?
--Session 1
select f1
from ##t1
where id = 1;
 

See possible answers