Dynamic Data Masking (DDM) is an important security feature designed to protect sensitive information in database environments like SQL Server and Azure SQL Database. It works by masking sensitive data from non-privileged users, thus enhancing data security and compliance without altering the actual data. DDM operates by hiding sensitive data in query results, allowing only privileged users to view the unmasked data. It’s especially valuable in environments requiring data protection without compromising user experience.
Author: Yvonne Vanslageren
Speed, Efficiency, and VLDB Backups: Making the Right Moves
Today we will discuss VLDB backups. Handling VLDBs can be challenging for many administrators. Sometimes just completing a full backup in a reasonable amount of time is challenging, not to mention restoring a database to meet your organization’s service level agreements (SLA). There are many options to consider. Some options exist outside of the BACKUP DATABASE statement. They key to improving database backups is to adjust various configurations to increase throughput, increase concurrency, and reduce the amount of data to backup.
Implementing Row-Level Security in SQL Server
Row-level security (RLS) in SQL Server is a feature that allows database administrators to control access to rows in a database table based on the characteristics of the users accessing them. This can be particularly important in environments where data privacy and security are critical. In this blog post, we’ll explore how to implement RLS in SQL Server.
SQL Server AGs: Tackling Missing and Stale Statistics for Readonly Secondaries
In SQL Server’s Always On Availability Groups, understanding the behavior of statistics on secondary replicas is key to maintaining query performance. This post explores the challenges and solutions for managing statistics in read-only secondary databases and snapshots. We delve into two critical scenarios: the creation of statistics in secondary replicas when they are missing on the primary, and the handling of stale statistics due to differences in primary and secondary workloads.
A Faster Future: SQL Server 2022’s Parallel Buffer Scan
The new parallel buffer scan feature in SQL Server 2022 improves the performance of Buffer Pool scan operations on large-memory machines by utilizing multiple CPU cores. Customers running SQL Server on large-memory machines (e.g. TBs of memory) can see up to 4 ~ 20 times faster executions on some scenarios which has been slow due to Buffer Pool scan. Those scenarios include creating a new database, backup/restore operations, AlwaysOn failover, file drop, and DBCC check operations. Internal operations (e.g. checkpoint) that requires Buffer Pool scan will also get the benefits. The parallel scan feature also improves the Buffer Pool scan performance of small databases residing on large-memory machines.
Optimizing SQL Server 2022: Leveraging Auto-Drop Statistics
Auto-Create statistics is a well-known feature critical for the database performance. When one statistic is auto created, changing the table structure is not blocked by the presence of the statistic. An auto-created statistics is also dropped automatically when a schema change happens. On the other hand, if the statistic is created by the user, any schema change will be blocked by the presence of the statistic. The Auto-Drop setting on a statistic is a new SQL Server 2022 feature to change this behavior.
SQL Server 2022: Improving Database Performance with Enhanced Parallel Redo
In the world of database management, SQL Server has consistently pushed the boundaries of performance and efficiency. The release of SQL Server 2022 marks another milestone, particularly in the realm of parallel redo operations. Let’s delve into how SQL Server 2022 transforms the landscape of thread management and batch redo, overcoming the limitations of its predecessors.
The Art of Resolving HADR_SYNC_COMMIT Waits in SQL Server
Navigating the complexities of SQL Server’s Always On Availability Groups can sometimes feel like solving a complex puzzle. One such challenging aspect involves understanding and resolving wait types related to Hadr_sync_commit. These wait types are like intricate clues that can reveal potential performance bottlenecks or issues in your Always On setup.