XLOG is the centralized log service of the SQL Azure Hyperscale (Hyperscale) distributed database-as-a-service (DBaaS) within Microsoft Azure. It is responsible for disseminating transaction log to all clients within the distributed database, such as Page Servers and secondary Compute replicas. As the size of the Hyperscale database increases, the number of XLOG clients also increases, thus presenting scalability challenges in the request handling and IO subsystem. This paper describes how to address scalability challenges by applying various techniques. To solve the thread exhaustion problem, a coroutine-based asynchronous log processing framework was implemented, allowing better management of long-polling requests and eliminating thread starvation. The XLOG Pool, a centralized I/O management component, was introduced to reduce redundant I/Os and improve cold start performance by consolidating log reads across clients. A RateLimiter using a token bucket algorithm was introduced to prevent throttling by Azure storage. To ensure data integrity, several layers of validation, including egress and end-to-end checksum validation, were added to detect and prevent data corruption. Performance evaluations showed significant improvements in log processing and read rates with the new asynchronous framework, XLOG Pool and RateLimiter supporting larger databases more efficiently, enabling Hyperscale to support up to 128 TB size databases in production. This paper illustrates how a real-world cloud database service, responsible for hosting mission-critical applications and managing hundreds of petabytes of data, innovates its logging service to enhance scalability, reliability, and cost efficiency.

Azure SQL DB offers disaggregated storage architecture called Hyperscale. While this architecture provides storage scale out, it comes at the cost of performance of I/O from remote storage. In-memory caches on the Compute nodes are small and lost on process restarts. This paper introduces Resilient Buffer Pool Extension (RBPEX) which is a persistent cache present on both compute and storage nodes. These caches significantly improve performance of I/O from Compute while at the same time maintaining correctness. This paper presents the architecture of RBPEX and how it stores the most relevant pages in an efficient and correct way. It uses innovative techniques like statistics, selective caching and reduction of small writes to improve performance in Hyperscale. It also presents details about handling multiple versions of pages from storage to maintain correctness.

As applications and data evolve over time, the database schema must be adjusted to accommodate their needs. Schema changes in relational databases have traditionally required synchronization with concurrent read and write access, causing significant interruptions to user applications. Although, most commercial databases have optimized common schema changes to reduce their runtime, they have not fundamentally addressed the requirement for synchronization which can lead to data being inaccessible for minutes or even hours in the presence of long running queries. MD-MVCC is a new technology in Azure SQL Database that enables multi-version concurrency control for schema changes. This allows schema changes to occur without any synchronization with concurrent queries which can operate on the earlier version of the schema until ongoing operations are committed, following Snapshot Isolation semantics. Schema deployments can now occur with minimal impact, increasing data availability but also flexibility for application developers. This required a comprehensive redesign of the schema management and metadata components of the RDBMS that are now multi-versioned across all layers, from query execution and in-memory caches to the system tables where metadata is persisted. This paper presents the overall design of MD-MVCC and demonstrates how it fundamentally improves data availability during schema changes without incurring any performance overheads.

SQL Azure's concurrency control relies on multi-versioning to prevent readers and writers from blocking each other and on in-memory row locks to prevent multiple writers modifying the same row. If the number of in-memory locks exceeds a threshold, then to reduce memory used for locking, table-level lock escalation occurs which severely reduces concurrency. This paper presents a technique called transaction-id locking that drastically reduces the number of in-memory locks and eliminates lock escalation. It also describes another technique called lock after qualification where rows are qualified without locking thereby letting concurrent transactions interested in mutually exclusive sets of rows execute without blocking each other. Optimized locking combines these two techniques with the prior scheme of in-memory row locks. This combination to improve common isolation levels (like Read Committed Snapshot Isolation) while retaining support for Serializable isolation level in a developer-friendly manner distinguishes this work from prior art. The paper presents in detail this new scheme which required changes in both the storage engine and the query processing engine. It also presents the results of deploying optimized locking to more than eleven million SQL databases in Azure.

Azure SQL Database and the upcoming release of SQL Server introduce a novel database recovery mechanism that combines traditional ARIES recovery with multi-version concurrency control to achieve database recovery in constant time, regardless of the size of user transactions. Additionally, our algorithm enables continuous transaction log truncation, even in the presence of long running transactions, thereby allowing large data modifications using only a small, constant amount of log space. These capabilities are particularly important for any Cloud database service given a) the constantly increasing database sizes, b) the frequent failures of commodity hardware, c) the strict availability requirements of modern, global applications and d) the fact that software upgrades and other maintenance tasks are managed by the Cloud platform, introducing unexpected failures for the users. This paper describes the design of our recovery algorithm and demonstrates how it allowed us to improve the availability of Azure SQL Database by guaranteeing consistent recovery times of under 3 minutes for 99.999% of recovery cases in production.