Key Rotation for SQL Server TDE in an Always On Availability Group Environment

 

Introduction:

Managing data security in SQL Server goes beyond enabling Transparent Data Encryption (TDE)—it also requires proper lifecycle management of encryption keys, especially in high-availability environments. In an Always On Availability Group setup, performing a TDE key rotation isn't as simple as running a command on a standalone instance. It involves coordinating key changes across replicas while maintaining encryption consistency and ensuring minimal downtime.

In this blog, I’ll walk you through how to safely rotate the Database Encryption Key (DEK) and the Certificate protecting it in a SQL Server Always On environment. You'll learn the prerequisites, steps involved, potential pitfalls, and how to verify that your key rotation was successful across all nodes in the availability group.

SQL Server Always On Across Two Data Centers: Manual and Automatic Failover Testing – Part 2

Introduction

In Part 1 (SQL Server Always On Across Two Data Centers with Dual Witnesses and DNS CNAME), I walked through how we designed and implemented a more resilient SQL Server Always On Availability Group architecture across two data centers, using dual file share witnesses and a DNS CNAME to simplify failover and enhance high availability.

Now, in Part 2, we put that setup to the test.

This blog focuses on failover testing—a crucial step in validating any high availability or disaster recovery solution. I’ll simulate real-world failure scenarios, including the complete loss of the primary data center (along with its witness and replica) and the failure of the DR data center. You’ll see how the system handles these events in both manual and automatic failover modes, and how our configuration ensures continuity without manual reconfiguration or data loss.

Whether you're preparing for disaster recovery testing or simply validating your SQL Server HA setup, these test cases and results will help you understand what to expect and how to respond when failure happens.

SQL Server Always On Across Two Data Centers with Dual Witnesses and DNS CNAME – Part 1

Introduction

In our existing SQL Server Always On configuration, we had a two-node setup, with each node hosted in a separate data center, and a single witness located in the secondary (DR) data center. Due to our application's design requirements, the availability group was configured for manual failover.

However, this architecture introduced a critical limitation: when the DR DC went offline, we lost quorum, and the Always On configuration became unusable. As a result, we were forced to disable and delete the availability group, and then recreate it from scratch, including re-adding all databases—an error-prone and time-consuming process.

To overcome this limitation and ensure high availability across both data centers, we implemented a more resilient architecture: two file-share witnesses—one in each data center—combined with a DNS CNAME record to abstract the witness name. This solution provides redundancy for the quorum configuration and allows the availability group to survive the failure of either data center without needing to rebuild the setup.

In these two blogs, I will walk you through how we built a more resilient Always On architecture. In Part 1 (SQL Server Always On Across Two Data centers with Dual Witnesses and DNS CNAME), I’ll explain the setup of dual file share witnesses across two data centers, along with the use of a DNS CNAME to manage quorum effectively. In Part 2 (SQL Server Always On Across Two Datacenters: Manual and Automatic Failover Testing), I’ll demonstrate how we tested failover in both manual and automatic modes—simulating complete failure of either the primary or secondary data center—and show how this architecture ensures availability without needing to rebuild the configuration.

Set Up Oracle ASM on an Azure Linux Virtual Machine: Challenges I Encountered and Their Solutions

 

Setting up an Oracle ASM-based database on an Azure Linux virtual machine can come with some challenges. While Microsoft provides a comprehensive official guide (Set Up Oracle ASM on an Azure Linux Virtual Machine) covering the core steps, real-world implementations often come with unexpected challenges that aren't addressed in the documentation.

In this blog post, I won’t repeat the steps already covered in the Microsoft article. Instead, I’ll walk you through the specific issues I encountered during the setup, the errors that slowed me down, and—most importantly—the solutions that worked. Whether you're a DBA, a cloud engineer, or someone exploring Oracle on Azure, I hope these insights will help you avoid similar pitfalls and save valuable time.

Here are the key problems I faced:

1. Installing Azure CLI on Windows
2. Creating an X Server VM (asmXServer) – a Windows-based VM for running graphical tools like asmca and dbca
3. Bastion Connection Failure – caused by an outdated version of Python

In the sections that follow, I’ll explain each of these issues in detail and how I successfully resolved them.

Inside Our Managed Services Team: How DBAs Support and Troubleshoot Oracle, SQL Server, MySQL, Operating Systems, and Cloud Environments

In today’s fast-paced IT landscape, managing databases isn’t just about keeping them online—it’s about ensuring performance, availability, security, and scalability across a wide range of platforms and environments. At Eclipsys, the Managed Services DBA team takes on exactly that challenge. We support a diverse set of databases including Oracle, SQL Server, and MySQL, deployed across cloud platforms like Azure, AWS, and OCI, and operating systems such as Linux, Windows, and Solaris. Our DBAs are also responsible for proactively monitoring these environments using tools like Oracle Enterprise Manager (OEM), Nagios, and SolarWinds, helping us detect issues before they impact performance. Our role goes beyond traditional DBA tasks—we troubleshoot critical problems, automate routine operations, handle performance tuning, and work directly with customers to ensure their systems are running optimally. In this blog, we’ll take you inside our day-to-day responsibilities, the tools we use, and how we help keep enterprise systems running smoothly and securely. Below are some of the other activities that we perform to provide support for clients using SQL server and MySQL databases.

How to Enable, Suspend, and Resume TDE Encryption Scans in SQL Server Always On

 

Transparent Data Encryption (TDE) is a crucial security feature in SQL Server that protects data at rest by encrypting database files. In an Always On availability group, managing TDE encryption scans efficiently is essential to ensure minimal performance impact and seamless data protection. This guide will walk you through the process of enabling, suspending, and resuming TDE encryption scans in SQL Server Always On, helping you maintain security while optimizing system performance. Whether you need to temporarily pause encryption scans for maintenance or resume them after an interruption, these steps will ensure smooth database operations.

For encrypting an SQL Server database, please review Encrypt an Existing MS SQL Server 2019 Database in an Always On Environment Using TDE

How to Decrypt a TDE-Enabled Database in a SQL Server Always On Environment

 

There could be various reasons for removing an existing TDE (Transparent Data Encryption) implementation from SQL Server databases. You may be considering an alternative encryption solution, experiencing performance issues, or needing to share a copy of the database or its backup with other business units that do not support TDE. Regardless of the reason, properly decrypting a TDE-enabled database in a SQL Server Always On environment requires careful execution to ensure data integrity and minimize downtime. In this guide, we will walk through the steps to safely remove TDE encryption from a database while maintaining availability and security.

For encrypting an SQL Server database, please review Encrypt an Existing MS SQL Server 2019 Database in an Always On Environment Using TDE