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.

The panel will discuss the research opportunities for the database research community in the context of cloud native data services.

SQL Ledger is a new technology that allows cryptographically verifying the integrity of relational data stored in Azure SQL Database and SQL Server. This is achieved by maintaining all historical data in the database and persisting its cryptographic (SHA-256) digests in an immutable, tamper-evident ledger. Digests representing the overall state of the ledger can then be extracted and stored outside of the RDBMS to protect the data from any attacker or high privileged user, including DBAs, system and cloud administrators. The ledger and the historical data are managed transparently, offering protection without any application changes. Historical data is maintained in a relational form to support SQL queries for auditing, forensics and other purposes. SQL Ledger provides cryptographic data integrity guarantees while maintaining the power, flexibility and performance of a commercial RDBMS. In contrast to Blockchain solutions that aim for full integrity, SQL Ledger offers a form of integrity protection known as Forward Integrity. The proposed technology is significantly cheaper and more secure than traditional solutions that establish trust based on audits or mediators, but also has substantial advantages over Blockchain solutions that are complex to deploy, lack data management capabilities and suffer in terms of performance due to their decentralized nature.

This paper presents Always Encrypted, a recently released feature of Microsoft SQL Server that uses column granularity encryption to provide cryptographic data protection guarantees. Always Encrypted can be used to outsource database administration while keeping the data confidential from an administrator, including cloud operators. The first version of Always Encrypted was released in Azure SQL Database and as part of SQL Server 2016, and supported equality operations over deterministically encrypted columns. The second version, released as part of SQL Server 2019, uses an enclave running within a trusted execution environment to provide richer functionality that includes comparison and string pattern matching for an IND-CPA-secure (randomized) encryption scheme. We present the security, functionality, and design of Always Encrypted, and provide a performance evaluation using the TPC-C benchmark.

Database systems based on ARIES [11] protocol rely on Write Ahead Logging (WAL) to recover the database in the event of a crash. WAL protocol requires changes to the database are recorded to the transaction log before updating the underlying database page. WAL also mandates that the log record corresponding to the change is persisted to disk before the updated page. While WAL allows updates to the databases using in-place updates or using shadow paging, database systems that perform in-place updates typically latch the page exclusively for the entire duration of log generation and the change on the page. The exclusive latch on the page prevents other threads from modifying the page at the same time, reducing the concurrency, and negatively impacting the throughput of the system. While approaches like Segment-Based recovery [16] attempt to solve the contention by pushing the burden of synchronization to the application along with a proposal for recovering parts of pages, this paper takes a different approach by providing a mechanism to support concurrent updates to certain kinds of pages under a shared latch using lock-free algorithms. The pages are recovered using existing ARIES protocol with a few modifications. This approach significantly boosts the throughput of an ARIES based database system, without any application changes. The paper describes in detail the challenges of implementing the mechanism and how the ARIES concepts like page LSN, logging and checkpoint are handled to support concurrent updates on space maintenance pages in Microsoft SQL Server. The paper also presents the experimental results showcasing the impact of the work.

The database-as-a-service paradigm in the cloud (DBaaS) is becoming increasingly popular. Organizations adopt this paradigm because they expect higher security, higher availability, and lower and more flexible cost with high performance. It has become clear, however, that these expectations cannot be met in the cloud with the traditional, monolithic database architecture. This paper presents a novel DBaaS architecture, called Socrates. Socrates has been implemented in Microsoft SQL Server and is available in Azure as SQL DB Hyperscale. This paper describes the key ideas and features of Socrates, and it compares the performance of Socrates with the previous SQL DB offering 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.

Azure SQL Database and the upcoming release of SQL Server enhance Online Index Rebuild to provide fault-tolerance and allow index rebuild operations to resume after a system failure or a user-initiated pause. SQL Server is the first commercial DBMS to support pause and resume functionality for index rebuilds. This is achieved by splitting the operation into incremental units of work and persisting the required state so that it can be resumed later with minimal loss of progress. At the same time, the proposed technology minimizes the log space required for the operation to succeed, making it possible to rebuild large indexes using only a small, constant amount of log space. These capabilities are critical to guarantee the reliability of these operations in an environment where a) the database sizes are increasing at a much faster pace compared to the available hardware, b) system failures are frequent in Cloud architectures using commodity hardware, c) software upgrades and other maintenance tasks are automatically handled by the Cloud platforms, introducing further unexpected failures for the users and d) most modern applications need to be available 24/7 and have very tight maintenance windows. This paper describes the design of "Resumable Online Index Rebuild" and discusses how this technology can be extended to cover more schema management operations in the future.

Database backups have traditionally been used as the primary mechanism to recover from hardware and user errors. High availability solutions maintain redundant copies of data that can be used to recover from most failures except user or application errors. Database backups are neither space nor time efficient for recovering from user errors which typically occur in the recent past and affect a small portion of the database. Moreover periodic full backups impact user workload and increase storage costs. In this paper we present a scheme that can be used for both user and application error recovery starting from the current state and rewinding the database back in time using the transaction log. While we provide a consistent view of the entire database as of a point in time in the past, the actual prior versions are produced only for data that is accessed. We make the as of data accessible to arbitrary point in time queries by integrating with the database snapshot feature in Microsoft SQL Server.

In order to guarantee durability of transactions (D in the ACID properties) database systems issue a synchronous log write on transaction commit. However, in many scenarios such as queue processing and personal information management systems, durability on commit is not required as the transactions rolled back due to a crash can be reprocessed using the application state. Avoiding such synchronous I/O improves system throughput and response time. Also, when the database is running on a mobile device or a laptop, reduced I/O consumes less power and increases battery life - a significant consideration for mobile users. Transactions that do not require durability can be "lazily committed", i.e. the log is not written synchronously upon commit. If another transaction reads such lazily committed data and performs an independently committed external action based on it, then an inconsistency may result if the effects of the lazily committed transaction are lost in a crash. We present a solution that provides the efficiency of lazily committed transactions and the flexibility for other transactions to read only durably committed data. We demonstrate that even in the presence of a large number of readers requesting durably committed data our approach reduces I/Os significantly.

In this paper we present an efficient method to do online rebuild of a B+-tree index. This method has been implemented in Sybase Adaptive Server Enterprise (ASE) Version 12.0. It provides high concurrency, does minimal amount of logging, has good performance and does not deadlock with other index operations. It copies the index rows to newly allocated pages in the key order so that good space utilization and clustering are achieved. The old pages are deallocated during the process. Our algorithm differs from the previously published online index rebuild algorithms in two ways. It rebuilds multiple leaf pages and then propagates the changes to higher levels. Also, while propagating the leaf level changes to higher levels, level 11 pages are reorganized, eliminating the need for a separate pass. Our performance study shows that our approach results in significant reduction in logging and CPU time. Also, our approach uses the same concurrency control mechanism as split and shrink operations, which made it attractive for implementation.