When I go to Comprehensive Database Performance Health Check often we have to make changes in the database as well as various objects like stored procedures or queries. While I like to work in the development environment to validate the checks, often there are no good copies of the database in the development environment. At that time I use this technique of copy database while keeping the database online. This method is very simple and efficient. Let us see that in today’s SQL in Sixty Seconds video.

Here is the video of how to copy database.

There are two important things we need to remember.

First – we need SQL Server agent enabled.

Second – we need to select copy via database object as that is the safest way to copy database.

If you accidentally select detach and attach method, your live production database may go offline for a while and also have service interruption.

Here are my few recent videos and I would like to know what is your feedback about them.

• 9 SQL SERVER Performance Tuning Tips – SQL in Sixty Seconds #168
• Excel – Sum vs SubTotal – SQL in Sixty Seconds #167
• 3 Ways to Configure MAXDOP – SQL in Sixty Seconds #166
• Get Memory Details – SQL in Sixty Seconds #165
• Get CPU Details – SQL in Sixty Seconds #164
• Shutdown SQL Server Via T-SQL – SQL in Sixty Seconds #163
• SQL Server on Linux – SQL in Sixty Seconds 162
• Query Ignoring CPU Threads – SQL in Sixty Seconds 161
• Bitwise Puzzle – SQL in Sixty Seconds 160
• Find Expensive Queries – SQL in Sixty Seconds #159
• Case-Sensitive Search – SQL in Sixty Seconds #158
• Wait Stats for Performance – SQL in Sixty Seconds #157
• Multiple Backup Copies Stripped – SQL in Sixty Seconds #156

Reference: Pinal Dave (http://blog.SQLAuthority.com)

First appeared on Copy Database – SQL in Sixty Seconds #169

Let us learn how to get the last restore date for the backup in SQL Server. Here is a very simple script for the same.

SELECT
[d].[name] AS [Database],
[d].[create_date],
[d].[compatibility_level],
rh.restore_date,
rh.restore_history_id,
rh.restore_type
FROM master.sys.databases d
LEFT OUTER JOIN msdb.dbo.[restorehistory] rh
ON rh.[destination_database_name] = d.Name
ORDER BY [Database], restore_history_id

Well, that’s it. It will give you all the necessary history from the msdb database.

If you want to clear any backup or restore history for the database, you can just run the following simple script and it will remove your history from the msdb database.

Here is an example of how you can remove the history for the AdventureWorks Database.

USE msdb;
GO
EXEC sp_delete_database_backuphistory @database_name = 'AdventureWorks'; 

Well, that’s it for today. Let me know your thoughts about this blog post.

Here are my few recent videos and I would like to know what is your feedback about them. Do not forget to subscribe SQL in Sixty Seconds series.

• MAX Columns Ever Existed in Table – SQL in Sixty Seconds #182
• Tuning Query Cost 100% – SQL in Sixty Seconds #181
• Queries Using Specific Index – SQL in Sixty Seconds #180
• Read Only Tables – Is it Possible? – SQL in Sixty Seconds #179
• One Scan for 3 Count Sum – SQL in Sixty Seconds #178
• SUM(1) vs COUNT(1) Performance Battle – SQL in Sixty Seconds #177
• COUNT(*) and COUNT(1): Performance Battle – SQL in Sixty Seconds #176

Reference: Pinal Dave (http://blog.SQLAuthority.com)

First appeared on SQL SERVER – Get Last Restore Date

A client whom I often help with Comprehensive Database Performance Health Check recently reached out to me with an interesting problem about Source Database in Restoring State.

My client had used SSMS to restore the database based on the original database. After doing a restore, he was very surprised as he was able to successfully use the new database but the original database in the restoring state. It was very much a surprise to him as he had just used a database as a source and it went into restoring state.

Well, this happens when you forget to tick the tail backup option in the SSMS wizard. The fix of this situation is very simple. Just run the following statement and it will immediately fix your source database.

RESTORE DATABASE SourceDBName WITH RECOVERY

Here are my few recent videos and I would like to know what is your feedback about them. Do not forget to subscribe SQL in Sixty Seconds series. I hope you appreciate learning about the Last 5 SQL in Sixty Seconds Video.

• Generate Script of SQL Server Objects – SQL in Sixty Seconds #184
• Prevent Unauthorized Index Modifications – SQL in Sixty Seconds #183
• MAX Columns Ever Existed in Table – SQL in Sixty Seconds #182
• Tuning Query Cost 100% – SQL in Sixty Seconds #181
• Queries Using Specific Index – SQL in Sixty Seconds #180
• Read Only Tables – Is it Possible? – SQL in Sixty Seconds #179
• One Scan for 3 Count Sum – SQL in Sixty Seconds #178
• SUM(1) vs COUNT(1) Performance Battle – SQL in Sixty Seconds #177
• COUNT(*) and COUNT(1): Performance Battle – SQL in Sixty Seconds #176

If you have any questions, you can always reach out to me on Twitter.

Reference: Pinal Dave (http://blog.SQLAuthority.com)

First appeared on SQL SERVER – Source Database in Restoring State

During Comprehensive Database Performance Health Check, I was recently asked if I have a handy script that can help us take compressed backup and uncompressed backup. Well, of course, I have and here it is. The scripts are very simple.

Compressed Backup

BACKUP DATABASE [StackOverflow2010] TO
DISK = N'D:\backup\Compressed-Backup.bak'
WITH COMPRESSION, STATS = 10
GO

Not compressed Backup

BACKUP DATABASE [StackOverflow2010] TO
DISK = N'D:\backup\Uncompressed-Backup.bak'
WITH NO_COMPRESSION, STATS = 10
GO

When you want to restore either of the back-ups, there is no special command for it. The script for the restore operation is the same for both of them. Here is an example of the same.

Restore Backup

RESTORE DATABASE [StackOverflow2010]
FROM DISK = N'D:\backup\Compressed-Backup.bak'
WITH RECOVERY
GO

RESTORE DATABASE [StackOverflow2010]
FROM DISK = N'D:\backup\Uncompressed-Backup.bak'
WITH RECOVERY
GO

Performance Difference

I honestly would not spend too much time discussing the performance between the compress and no compress option as this feature is mainly for saving space in your disk. However, here is the observation if you want to discuss the performance of various options.

Compress Backup is smaller in size but took a long time to take backup, however, it was quicker to restore.

No Compress Backup is of the regular size but was faster to take backup, during restore it took a bit longer than compressed backup.

Well, that’s it for today. Would you like me to build a video on this topic? If yes, let me know and I will build a video on this topic on my SQL in Sixty Seconds channel.

Reference: Pinal Dave (http://blog.SQLAuthority.com)

First appeared on SQL SERVER – Sample Script for Compressed and Uncompressed Backup

During Comprehensive Database Performance Health Check, I was recently asked if I have a handy script that can help us take compressed backup and uncompressed backup. I have blogged about this here: SQL SERVER – Sample Script for Compressed and Uncompressed Backup. Today, we will see a video based on this topic where we will discuss compressed backup and performance.

Lots of people ask me how the performance impact when we are talking about compressed backup or compressed restore. Well, let us see that in today’s video over here.

Let me know what you think of this video.

Here are my few recent videos and I would like to know what is your feedback about them. Do not forget to subscribe SQL in Sixty Seconds series. I hope you appreciate learning about the last few SQL in Sixty Seconds Video.

• Find Missing Identity – SQL in Sixty Seconds #195
• Remove Key Lookup – SQL in Sixty Seconds #194
• Using Stored Procedure in SELECT – SQL in Sixty Seconds #193
• Performance Troubles – Function on Date Variable – SQL in Sixty Seconds #192
• Performance: Between and Other Operators – SQL in Sixty Seconds #191
• Most Used Database Files – SQL in Sixty Seconds #190

Well, that’s it for today. Would you like me to build a video on this topic? If yes, let me know and I will build a video on this topic on my SQL in Sixty Seconds channel.

Reference: Pinal Dave (http://blog.SQLAuthority.com)

First appeared on Compressed Backup and Performance – SQL in Sixty Seconds #196

SQL Server is a powerful database management system, but it can also be complex and prone to mistakes. Whether you’re a seasoned database administrator or a beginner just getting started, it’s essential to be aware of common mistakes and how to avoid them. This blog post will cover 11 tips for avoiding common SQL server mistakes. From indexing to security, these tips will help you optimize your database’s performance and ensure your data’s integrity. So, let’s dive in and see how you can improve your SQL Server skills.

11 Essential Tips for Avoiding Common SQL Server Performance Tuning

1. Ignoring indexing and query optimization: To ensure that your SQL queries are optimized, you should create indexes on frequently searched columns. For example, to create a non-clustered index on the “Name” column in the “Items” table, you can use the following T-SQL:
   

   CREATE NONCLUSTERED INDEX IX_Items_Name ON Items (Name)

2. Over-reliance on hardware upgrades: To avoid over-reliance on hardware upgrades, you should focus on optimizing your database design and schema. For example, you can create a covering index to improve query performance:
   

   CREATE NONCLUSTERED INDEX IX_Orders_CustomerID_OrderDate 
   ON Orders (CustomerID, OrderDate);

3. Not monitoring resource utilization: To monitor resource utilization, you can use SQL Server Performance Monitor. For example, you can track the CPU utilization of your database server by adding the “Processor: % Processor Time” performance counter to the graph:

   PERFMON.EXE

4. Failing to keep statistics updated: To keep statistics updated, you can run the sp_updatestats stored procedure. For example, to update the statistics on the “Items” table, you can use the following T-SQL:

   EXEC sp_updatestats 'Items';

5. Ignoring database design and normalization: To ensure good database design and normalization, you should implement best practices such as using appropriate data types and avoiding data redundancy. For example, to create a new table with a primary key and foreign key relationship, you can use the following T-SQL:

   CREATE TABLE Orders (
     OrderID int PRIMARY KEY,
     CustomerID int FOREIGN KEY REFERENCES Customers (CustomerID),
     OrderDate datetime,
     TotalAmount money
   );

6. Not using appropriate data types and sizes: To use appropriate data types and sizes, you should choose data types based on the data you are storing. For example, to store a small amount of text, you should use the varchar data type instead of the varchar(max) data type:

   CREATE TABLE Items (
     ItemID int PRIMARY KEY,
     Name varchar(100),
     Address varchar(250),
     Phone varchar(20)
   );

7. Neglecting to regularly backup and maintain database integrity: To regularly backup and maintain database integrity, you should create a backup schedule and run regular database maintenance tasks. For example, to create a full backup of the “AdventureWorks” database, you can use the following T-SQL:

   BACKUP DATABASE AdventureWorks 
   TO DISK = 'C:\AdventureWorks_Full.bak'

8. Overusing cursors and temporary tables: To avoid overusing cursors and temporary tables, you should use set-based operations whenever possible. For example, to retrieve the total sales for each customer, you can use the following T-SQL:

   SELECT CustomerID, SUM(TotalAmount) AS TotalSales
   FROM Orders
   GROUP BY CustomerID;
   

9. Not managing data growth and storage space: To manage data growth and storage space, you should implement data archiving and purging strategies. For example, to archive old order data to a separate table, you can use the following T-SQL:

   INSERT INTO ItemArchive (ItemID, CustomerID, ItemDate, TotalAmount)
   SELECT ItemID, CustomerID, OrderDate, TotalAmount
   FROM Items
   WHERE ItemDate < '2021-01-01';
   DELETE FROM Items
   WHERE ItemDate < '2021-01-01';

10. Not securing the database: To secure the database, you should implement appropriate security measures such as using strong passwords, enabling encryption, and restricting access to sensitive data. For example, to create a user with read-only access to the “Items” table, you can use the following T-SQL:

    CREATE USER ItemReader WITHOUT LOGIN;
    GRANT SELECT ON Items TO ItemReader;
    

11. Not testing changes in a development environment: To avoid potential issues in production, it’s essential to test any changes or updates in a development environment first. This can include schema changes, data changes, and application changes. For example, before updating the schema of a production table, you should test the changes in a development environment to ensure that it doesn’t cause any issues:

    -- In development environment
    CREATE TABLE Orders_Dev (
      OrderID int PRIMARY KEY,
      CustomerID int FOREIGN KEY REFERENCES Customers (CustomerID),
      OrderDate datetime,
      TotalAmount money
    );
    -- Test the changes in the development environment
    -- If successful, apply the changes to the production environment

In conclusion, these 11 tips will help you avoid common mistakes in SQL Server and improve the performance and security of your database. By following these guidelines, you’ll be able to make the most of your SQL Server investment and ensure that your data is well-protected and efficiently managed. Whether you’re a beginner or an experienced database administrator, it’s always a good idea to regularly review these tips and ensure you’re up-to-date with the latest best practices. With the right tools and a little knowledge, you can achieve great things with SQL Server and take your database skills to the next level.

As a SQL Server Performance Tuning Expert with over two decades of experience, I understand the importance of a well-performing database. I also understand the frustration that comes with a slow-performing SQL Server. But here’s the good news – you don’t have to suffer any longer. With my Comprehensive Database Performance Health Check, we can work remotely to identify and resolve your biggest performance troublemakers in less than 4 hours. And the best part? You won’t have to share any server credentials with me. Just sit back and watch as I use my expertise to speed up your SQL Server and give you the needed results. Not only will you see immediate results, but you’ll also learn valuable business secrets that will help you fix most problems in the future. So, invest in your SQL Server performance today with my Comprehensive Database Performance Health Check! Connect with me on Twitter.

Reference: Pinal Dave (http://blog.SQLAuthority.com)

First appeared on 11 Essential Tips for Avoiding Common SQL Server Performance Tuning Mistakes

In SQL Server 2022, a new improved backup metadata feature has been introduced, providing enhanced information about backups. One significant addition to the backup metadata is the inclusion of the last valid restore time. This valuable information allows users to identify a safe point in time to restore their databases, even if the backup start and end times differ from the timestamps in the transaction log files. In this blog post, we will explore the importance of this new feature and demonstrate its usage with a code example. While you are at it, do check out Comprehensive Database Performance Health Check.

Importance of Last Valid Restore Time

The last valid restore time provided by the improved backup metadata feature is crucial for ensuring data integrity and recovery. While backup start and end times may vary, the last valid restore time serves as a reference point to safely restore the database to a specific time. This information is especially valuable for point-in-time recovery scenarios, allowing users to restore their databases accurately and reliably.

Script

Here is the script I have used to generate this scenario.

-- Create or recreate the SQLAuthority database
USE master;
IF EXISTS (SELECT 1 FROM sys.databases WHERE name = 'SQLAuthority')
    DROP DATABASE SQLAuthority;
GO
CREATE DATABASE SQLAuthority;
GO
-- Switch to the SQLAuthority database
USE SQLAuthority;
GO
-- Create the Products table
CREATE TABLE Products
(
    ID INT,
    Name NVARCHAR(100),
    CurrentDateTime DATETIME
);
-- Insert initial data into the Products table
INSERT INTO Products (ID, Name, CurrentDateTime)
VALUES
    (1, 'Action Figure', GETDATE()),
    (2, 'Plush Teddy Bear', GETDATE()),
    (3, 'Remote Control Car', GETDATE());
GO
-- Perform a full database backup of SQLAuthority
BACKUP DATABASE SQLAuthority
TO DISK = 'D:\Backup\SQLAuthority_full_backup.bak';
GO
-- Retrieve data from the Products table
SELECT *
FROM Products;
GO
-- Insert additional data into the Products table
INSERT INTO Products (ID, Name, CurrentDateTime)
VALUES
    (4, 'Dollhouse', GETDATE()),
    (5, 'Building Blocks', GETDATE()),
    (6, 'RC Drone', GETDATE());
GO 100
-- Take a transaction log backup of SQLAuthority
BACKUP LOG SQLAuthority
TO DISK = 'D:\Backup\SQLAuthority_log_backup.trn';
GO
-- Query backup metadata from the backupset system table
SELECT bs.database_name,
    BackupStartDate = bs.backup_start_date,
    LastValidRestoreTime = bs.last_valid_restore_time,
    BackupFinishDate = bs.backup_finish_date,
    backuptype = CASE 
        WHEN bs.type = 'D' AND bs.is_copy_only = 0 THEN 'Full Database'
        WHEN bs.type = 'D' AND bs.is_copy_only = 1 THEN 'Full Copy-Only Database'
        WHEN bs.type = 'I' THEN 'Differential database backup'
        WHEN bs.type = 'L' THEN 'Transaction Log'
        WHEN bs.type = 'F' THEN 'File or filegroup'
        WHEN bs.type = 'G' THEN 'Differential file'
        WHEN bs.type = 'P' THEN 'Partial'
        WHEN bs.type = 'Q' THEN 'Differential partial'
        END + ' Backup',
    CASE bf.device_type
        WHEN 2 THEN 'Disk'
        WHEN 5 THEN 'Tape'
        WHEN 7 THEN 'Virtual device'
        WHEN 9 THEN 'Azure Storage'
        WHEN 105 THEN 'A permanent backup device'
        ELSE 'Other Device'
        END AS DeviceType,   
    bs.recovery_model,
    bs.compatibility_level,   
    LatestBackupLocation = bf.physical_device_name,
    backup_size_mb = CONVERT(DECIMAL(10, 2), bs.backup_size / 1024. / 1024.),
    compressed_backup_size_mb = CONVERT(DECIMAL(10, 2), bs.compressed_backup_size / 1024. / 1024.),
    bms.is_password_protected
FROM msdb.dbo.backupset bs
LEFT JOIN msdb.dbo.backupmediafamily bf
    ON bs.[media_set_id] = bf.[media_set_id]
INNER JOIN msdb.dbo.backupmediaset bms
    ON bs.[media_set_id] = bms.[media_set_id]
ORDER BY bs.database_name ASC,
    bs.Backup_Start_Date DESC;

Here is the result which we get.

In the result, you can clearly see that the last valid restore datetime is very much different for the backup start date and backup finish date.

Conclusion

The introduction of improved backup metadata in SQL Server 2022 has enhanced the backup and restore process. The inclusion of the last valid restore time empowers users to restore their databases to a precise point in time, irrespective of differences between backup and log file timestamps. This feature is particularly useful for point-in-time recovery, ensuring data integrity and minimizing potential data loss. By leveraging the code example provided in this blog post, SQL Server users can take advantage of this new feature and enhance their data protection strategies. Understanding these concepts will help you utilize the improved backup metadata feature effectively and ensure the resilience of your SQL Server databases.

Reference: Pinal Dave (http://www.SQLAuthority.com)

First appeared on SQL SERVER 2022 – Last Valid Restore Time – Improved Backup Metadata

During a recent Comprehensive Database Performance Health Check, I encountered an intriguing situation where a client’s msdb database had ballooned in size. After a thorough investigation, it became apparent that the cause was an extensive history of backup operations that had accumulated over a long period. The client had neglected to clean up this history, leading to unnecessary bloat. In this blog post, I’ll share the interesting solution we implemented, which involved deleting backup history based on time and specific databases. Today we are going to discuss Reclaiming Space and Performance: Database Backup History.

Unveiling the Bloated Past

As I delved into the client’s database health check, I discovered that their msdb database had grown significantly due to the accumulation of backup history. It was crucial to tackle this issue head-on to regain valuable space and improve performance.

Two Paths to Clarity

To address the issue, we employed two distinct strategies. First, we opted to delete the entire backup history beyond a certain point—specifically, 90 days ago. This approach aimed to eliminate the oldest entries that were no longer essential for the client’s operations. By freeing up space from this bulk deletion, we set the stage for a more manageable backup history.

The second part of our solution involved selectively deleting backup history for specific non-essential databases. This approach ensured that we retained crucial backup records for vital databases while removing unnecessary entries for less critical ones. The script below demonstrates how we accomplished this:

USE msdb;  
GO  
EXEC sp_delete_backuphistory @oldest_date = '11/15/2022'; 

USE msdb;  
GO  
EXEC sp_delete_database_backuphistory @database_name = 'AdventureWorks';

The Impact on Tables

It’s important to understand which tables are affected by these operations. The stored procedures, sp_delete_backuphistory and sp_delete_database_backuphistory, modify the following tables:

• backupfile
• backupfilegroup
• backupmediafamily
• backupmediaset
• backupset
• restorefile
• restorefilegroup
• restorehistory

By cleaning up the backup and restore history stored within these tables, we were able to significantly reduce the size of the msdb database and optimize its performance.

Benefits of a Leaner Database

With the backup history appropriately pruned, the client’s msdb database experienced a remarkable transformation. The reduced size improved overall performance, ensuring faster backups and restores. Additionally, the streamlined backup history simplified navigation, making it easier for administrators to find relevant information promptly.

Maintenance Matters

This scenario highlights the importance of regular maintenance to prevent database bloat. By periodically cleaning up backup history, organizations can prevent unnecessary resource consumption and maintain a healthier database environment. Implementing scheduled cleanup tasks, along with the occasional selective deletion, ensures that the database remains optimized without compromising vital backup records.

Conclusion

In the world of database management, neglecting to clean up backup history can lead to bloated databases and suboptimal performance. By employing the powerful tools of sp_delete_backuphistory and sp_delete_database_backuphistory, administrators can take control of their backup history and reclaim valuable space. This process not only enhances performance but also improves efficiency and simplifies database management. Remember, a leaner database is a healthier database! I hope you enjoyed this blog post about Reclaiming Space and Performance: Database Backup History. Do subscribe to my youtube channel.

Reference: Pinal Dave (http://www.SQLAuthority.com)

First appeared on SQL SERVER – Reclaiming Space and Performance: Database Backup History

Proper maintenance is absolutely essential for keeping an SQL Server running at its optimal level. A well-maintained SQL Server will experience significantly fewer performance, stability, and data integrity issues. This comprehensive guide explore into some essential maintenance techniques and best practices to ensure your SQL Server deployment continues operating smoothly, efficiently, and securely.

Automating Maintenance Tasks: A Smart Approach to Efficiency

The first step towards effective maintenance is automating routine tasks. Setting up automated jobs for recurring maintenance activities ensures that standard studies are performed consistently and regularly, eliminating the need for manual admin intervention. Here are some of the most important jobs you should consider automating:

• Backups – Configure full, differential, and transaction log backups to run on a pre-set schedule. Regular backups are your first defense against data loss from system failures or unforeseen disasters.
• Integrity Checks – Schedule jobs to perform DBCC CHECKDB periodically. This command helps identify and prevent database corruption issues.
• Reindexing – As time progresses, index fragmentation can degrade query performance. Regularly rebuilding indexes can significantly improve response times.
• Statistics Updates – Outdated statistics can lead to suboptimal query plans. Scheduling periodic statistics updates helps the SQL Server optimizer make more efficient decisions.
• Cleanup Tasks – Automate jobs that perform cleanup activities, such as removing outdated backup files, transaction logs, or orphaned user objects.

Plan to run these critical jobs during off-peak hours, like overnight or during weekends. You can use the SQL Server Agent to create and schedule these jobs. It may also be worth considering maintaining different schedules for development, test, and production environments to minimize potential disruptions.

Monitoring Server Health: Keeping an Eye on Your SQL Server

Active server health monitoring is instrumental in catching minor issues before they escalate into major problems. Tools such as Performance Monitor, Dynamic Management Views, and Extended Events can provide valuable insights into the overall health of your SQL Server instance.

Key performance indicators to monitor include:

• Hardware Utilization – Regularly track CPU, memory, disk I/O, and network usage to identify potential bottlenecks.
• Wait Stats – High wait times can indicate contention and hint at underlying root causes that need attention.
• Client Connections/Requests – Unusual spikes in traffic can act as early warning signs of emerging issues.
• Blocking Queries – Monitor and detect long-running blocks and deadlocks that could impact performance.
• Error Logs – Regularly review logs for error or warning messages that require immediate attention.

Consider setting up alerts for critical metrics that exceed defined thresholds. Early detection of problems can save significant time and resources compared to troubleshooting after a failure.

Managing Indexes: Ensuring Optimal Query Performance

Regular index maintenance becomes a critical server management component as databases grow and evolve over time. Here are some routine index tasks that can help ensure optimal performance:

• Rebuild Indexes – This defragments pages and reduces fragmentation. Focusing on indexes with fragmentation levels over 30% is generally recommended.
• Reorganize Indexes – This is less intensive than a rebuild, and it updates index statistics and pages. Use this for fragmentation levels between 5-30%.
• Remove Unused Indexes – Deleting no longer needed indexes can speed up insert and update operations.
• Analyze Index Usage – Determine which indexes are most and least used to guide your maintenance efforts.
• Review Missing Indexes – Adding indexes to tables where they can improve query performance can be a quick win for performance.
• Update Index Statistics – Outdated index statistics can result in poor query plans. Regularly updating index statistics can help maintain efficient query execution.

Security and Compliance: Securing Your SQL Server Environment

Implementing rigorous security measures and compliance controls is an integral part of SQL Server maintenance:

• Strong Passwords – Enforce the use of complex passwords that are regularly changed. Avoid using common or default passwords.
• Least Privilege – Grant users the minimum permissions necessary for their role. Overprovisioning access can lead to unnecessary security risks.
• Encryption – Use certificates or Transparent Data Encryption (TDE) to encrypt sensitive data at rest and in transit.
• Auditing – Enable auditing to capture critical events like logins and security changes for ongoing monitoring and review.
• Patching – Regularly apply security patches and hotfixes to close potential vulnerabilities.
• Compliance Controls – Adhere to regulations like the General Data Protection Regulation (GDPR), Health Insurance Portability and Accountability Act (HIPAA), or Payment Card Industry Data Security Standard (PCI DSS) as appropriate for your data and industry.

Maintaining a secure and compliant SQL Server environment significantly reduces risk exposure for your organization.

Careful Server Upgrades

When it comes time to upgrade your SQL Server to the latest version, careful planning and preparation are paramount:

• Extensive Testing – Begin by performing upgrades in non-production environments, checking for compatibility issues.
• Database Backups – Always take full backups before proceeding with the upgrade. This acts as a safety net, providing a rollback option in case of failure.
• Application Updates – If necessary, modify applications to work with the new SQL Server version ahead of time to ensure seamless integration.
• Functionality Validation – After completing the upgrade, thoroughly test all operations and performance to ensure everything functions as expected.
• Staged Upgrades – Consider rolling out the upgrades incrementally rather than all at once. This strategy helps to isolate any potential issues and mitigates the risk of widespread disruption.

With careful testing and methodical planning, SQL Server upgrades can be performed seamlessly, even for mission-critical production instances.

Regular maintenance is the key to extracting the maximum lifespan and performance from your SQL Server deployment. By automating what you can, adhering to best practices, and proactively monitoring server health, you can ensure that your databases will continue to run smoothly and efficiently for years to come.

You can always reach out to me on Twitter.

Reference: Pinal Dave (https://blog.sqlauthority.com)

First appeared on SQL Server Maintenance Techniques: A Comprehensive Guide to Keeping Your Server Running Smoothly

At its core, Accelerated Database Recovery is a revolutionary SQL Server feature that dramatically boosts database availability. It’s a game-changer in situations where long-running transactions are involved, as it entirely overhauls the SQL database engine recovery process. ADR’s core benefits include swift and consistent database recovery, immediate transaction rollback, and aggressive log truncation.

The New and Improved ADR in SQL Server 2022

SQL Server 2022 introduces several improvements to ADR, specifically designed to tackle persistent version store (PVS) storage challenges and enhance overall scalability.

User Transaction Cleanup: A More Efficient Approach

ADR’s cleanup process in SQL Server 2022 has been enhanced by enabling user transactions to clean up pages that the regular process could not handle due to conflicts at the table level lock. This ensures the ADR cleanup process no longer becomes indefinitely stalled due to lock acquisition issues, thereby increasing the overall effectiveness and efficiency of the system.

A Leaner Memory Footprint for PVS Page Tracker

SQL Server 2022 employs a clever strategy to decrease the memory footprint required to maintain versioned pages. It achieves this by tracking persisted version store (PVS) pages at the extent level, an optimization that facilitates more efficient management of the SQL Server instance’s memory resources. The ADR cleaner process has been redefined to enhance version cleanup efficiencies. SQL Server 2022 has refined how it tracks and records aborted versions of a page, which significantly improves memory and capacity.

Transaction-level Persisted Version Store (PVS): Bridging the Gap

This new feature empowers ADR to clean up versions linked to committed transactions, regardless of whether the system has aborted transactions. The result is that PVS pages can be deallocated even if the cleanup doesn’t complete a successful sweep. This reduces PVS growth even if ADR cleanup is delayed or fails.

Multi-threaded Version Cleanup: Power in Numbers

SQL Server 2022 has introduced multi-threaded version cleanup, which allows several databases in the same SQL Server instance to be cleaned simultaneously. This enhancement is particularly beneficial when dealing with multiple large databases. The number of threads used for version cleanup can be adjusted for scalability with sp_configure.

EXEC sp_configure 'ADR Cleaner Thread Count', '8'
RECONFIGURE WITH OVERRIDE;

In Conclusion

The enhancements in Accelerated Database Recovery in SQL Server 2022 offer substantial benefits for database administrators and developers. They improve the speed and efficiency of database recovery processes, reduce the memory footprint, and enhance cleanup efficiencies. As SQL Server continues to evolve, we can anticipate further enhancements to ADR and other features that will continue to refine database performance, recovery, and management. You can watch my YouTube videos over here.

Reference: Pinal Dave (https://blog.sqlauthority.com)

First appeared on The Evolution of Accelerated Database Recovery in SQL Server 2022