MODIFY FILE failed for database ‘tempdb’, file id 1. Size of file (41435136 KB) is greater than MAXSIZE (26214400 KB). (Microsoft SQL Server, Error: 5040)


Introduction:

In the dynamic realm of Azure SQL Managed Instances, configuring database file sizes is a routine task. However, challenges can arise, as I recently encountered while attempting to modify the Tempdb database file size. This blog post details the steps taken to address a perplexing error message that surfaced during this process.

Problem Statement:
The objective was straightforward: adjusting the maximum file size of the Tempdb database on an Azure SQL Managed Instance to 25 GB.

However, both through the graphical user interface (GUI) and Transact-SQL (T-SQL) commands, an error persisted:

TITLE: Microsoft SQL Server Management Studio
——————————
Alter failed for Database ‘tempdb’.  (Microsoft.SqlServer.Smo)
For help, click: https://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=16.100.47008.0&EvtSrc=Microsoft.SqlServer.Management.Smo.ExceptionTemplates.FailedOperationExceptionText&EvtID=Alter+Database&LinkId=20476
——————————
ADDITIONAL INFORMATION:
An exception occurred while executing a Transact-SQL statement or batch. (Microsoft.SqlServer.ConnectionInfo)
——————————
MODIFY FILE failed for database ‘tempdb’, file id 1. Size of file (41435136 KB) is greater than MAXSIZE (26214400 KB). (Microsoft SQL Server, Error: 5040)
For help, click: https://docs.microsoft.com/sql/relational-databases/errors-events/mssqlserver-5040-database-engine-error
——————————

The error surfaced when attempting the operation through the graphical user interface (GUI), and repeating the process using Transact-SQL (T-SQL) resulted in the identical error.

The error notification suggests that the existing size of the Tempdb database file (tempdev) exceeds the size I intended to establish. Contrary to this indication, the actual size of tempdev is only 16 MB, and my intention was to set the Maximum File size to 25 GB.

The error message indicates that the file size is reported as 41,435,136 KB, equivalent to 39.5 GB. Attempting to establish the Maximum file size of Tempdev below 39.5 GB resulted in an error. However, setting it to 40 GB proved successful.

This particular Azure SQL Managed Instance is of the Business Critical tier with 80 Vcores and includes 4 replicas. To delve deeper into the issue, I connected to the read replica of this managed instance through a query window, utilizing the ApplicationIntent=ReadOnly parameter.


I’ve established a connection to the user database JBSWiki to confirm that I am indeed connected to the Read Replica, as verified by executing the following query:

SELECT DATABASEPROPERTYEX(DB_NAME(), 'Updateability');

Upon execution, you will observe the result as READ_ONLY, affirming your connection to the Read Replica. It’s crucial to note that running the same query under the context of Tempdb will display READ_WRITE. To avoid confusion, ensure the query is executed on a user database to validate your connection to a Read Replica.

-> I executed below query to check the tempdb size on Read replica,

use tempdb
select file_id, type, type_desc, name, physical_name, size, max_size, growth, is_percent_growth from sys.database_files

-> Below is the output,

The size of tempdev on the read replica was configured at 39.5 GB, creating complications when attempting to adjust the Maximum file size on the Azure SQL Managed Instance. To address this, I reduced the size of tempdb on the read replica to 15 GB using DBCC SHRINKFILE. Following this adjustment, I successfully set the Maximum File size of the Tempdb data file to 25 GB.

Summary:
Navigating the nuances of database file sizes in an Azure SQL Managed Instance, particularly when dealing with read replicas, demands a comprehensive approach. Verifying the reported sizes, understanding the intricacies of database contexts, and proactive measures such as shrinking the Tempdb on read replicas are pivotal for resolving challenges like the ‘MODIFY FILE failed’ error. This journey underscores the significance of a meticulous troubleshooting process, ensuring a smooth configuration experience within the Azure SQL environment.

Thank You,
Vivek Janakiraman

Disclaimer:
The views expressed on this blog are mine alone and do not reflect the views of my company or anyone else. All postings on this blog are provided “AS IS” with no warranties, and confers no rights.

ALWAYS ON – Troubleshooting Availability Group Database Stuck in Initializing / In Recovery Mode

Introduction

In this blog post, we will discuss an issue encountered with an Always On Availability Group where a database remained stuck in the Initializing / In Recovery state on the secondary replica after a failover. We will explore the steps taken to resolve the problem and provide insights into the underlying causes.

Issue

During a failover from the primary to the secondary replica in an Always On Availability Group, one particular database entered the Initializing / In Recovery state on the secondary replica. Despite restarting SQL services and attempting to suspend data movement, the database remained stuck in this state.

Resolution

  1. Logging off users and restarting SQL services: Initially, all users were logged off from the secondary replica, and the SQL services on the replica were restarted. However, these steps did not resolve the issue.
  2. Suspending data movement: The next approach involved suspending the data movement of the problematic database from the SQL Server Management Studio on the secondary replica. However, this operation resulted in a “lock request time out period exceeded” error.
  3. Identifying the blocking process: To investigate further, a query was executed to identify any blocking processes using the following query:
    SELECT * FROM sysprocesses WHERE blocked > 0
    It was discovered that the DB Startup thread for the specific database was blocking the SPID attempting to suspend data movement.
  4. Checking recovery status: The SQL Server error log was examined to determine if the database’s recovery had completed. The log indicated that recovery for the database had finished in 43 seconds, with no user action required.
    Recovery completed for database JB_DB (database ID 7) in 43 second(s) (analysis 64 ms, redo 324 ms, undo 0 ms.) This is an informational message only. No user action is required.
  5. Analyzing DB Startup thread wait type: Monitoring the DB Startup thread revealed that it was in a wait state with the HADR_RECOVERY_WAIT_FOR_UNDO type. This wait type occurs when the secondary database is waiting for the reverting and initializing phases to synchronize with the primary database after failover.
  6. Monitoring undo progress: The “Log remaining for undo” performance monitor counter was used to track the amount of log in kilobytes remaining for the undo phase. Surprisingly, the counter showed 0, indicating that there was nothing to undo, and the recovery completed message in the SQL Server error log confirmed that the undo took 0 milliseconds.
  7. Failing over to another synchronous secondary replica: To further troubleshoot the issue, a failover was performed from the primary replica to another synchronous secondary replica. This time, all databases returned to a synchronized state without any issues.
  8. Restarting SQL Server Instance on Primary Replica if there are no additional synchronous secondary replica: If there are no additional synchronous secondary replica to failover the primary replica, you need to restart the SQL Server Instance on Primary Replica a a workaround for this issue.

Summary

The issue of a database stuck in the Initializing / In Recovery state after an Always On Availability Group failover was resolved by failing over to another synchronous secondary replica. Although the root cause and exact timing of the issue remain unknown, this blog post aims to provide guidance and assistance to others who may encounter similar challenges within the community. This problem has been identified as a bug and is documented here.

Thank You,
Vivek Janakiraman

Disclaimer:
The views expressed on this blog are mine alone and do not reflect the views of my company or anyone else. All postings on this blog are provided “AS IS” with no warranties, and confers no rights.

Always Encrypted: Securing Your SQL Server Data for the Future

Introduction

In today’s digital landscape, data security is a top priority for businesses and organizations of all sizes. With the rise of cyber threats and data breaches, it’s crucial to implement robust security measures to protect sensitive information. One of the most effective ways to achieve this is through database encryption.

SQL Server Always Encrypted is a powerful feature in Microsoft’s SQL Server that provides enhanced security for sensitive data stored in databases. In this blog, we’ll dive deep into the background of Always Encrypted, the challenges and opportunities it presents, best practices for implementation, future outlook, and more.

Background

Database encryption has been around for decades, but it has traditionally been a complex and challenging process to implement. Older encryption techniques require complex key management and can impact performance. Moreover, encryption is typically applied at the server level, making it vulnerable to insider attacks or unauthorized access by administrators.

SQL Server Always Encrypted was introduced in SQL Server 2016 as a response to these challenges. Always Encrypted uses client-side encryption to protect sensitive data stored in databases. With client-side encryption, data is encrypted on the client side before being sent to the server, so the server doesn’t have access to the unencrypted data.

Challenges and Opportunities

One of the most significant challenges of database encryption is balancing security with performance. Encryption can cause a significant impact on database performance, especially when dealing with large volumes of data. Always Encrypted addresses this challenge by using client-side encryption, which ensures that encryption and decryption are handled by the client, not the server.

Always Encrypted also presents a unique opportunity for businesses and organizations to secure sensitive data in a way that was previously difficult or impossible to achieve. For example, in the healthcare industry, Always Encrypted can be used to protect patient data stored in electronic health records (EHRs). Similarly, in the financial industry, Always Encrypted can be used to secure sensitive financial data such as credit card numbers, social security numbers, and bank account information.

Best Practices

Implementing Always Encrypted in SQL Server requires careful planning and execution. Here are some best practices to keep in mind:

Use the latest version of SQL Server: Always Encrypted was first introduced in SQL Server 2016, and subsequent versions have improved on the feature. Always use the latest version of SQL Server to take advantage of the latest security enhancements.

Use column-level encryption: Always Encrypted allows for column-level encryption, which means you can selectively encrypt only the columns that contain sensitive data. This reduces the performance impact of encryption and makes it easier to manage encrypted data.

Use a key management system: Always Encrypted relies on key management to encrypt and decrypt data. Use a key management system to securely store and manage encryption keys.

Test performance before deployment: Always Encrypted can impact database performance, especially when dealing with large volumes of data. Before deploying Always Encrypted, test its performance in a test environment to ensure it won’t cause issues in production.

Future Outlook

As cyber threats continue to evolve, the need for advanced database encryption techniques like Always Encrypted will only increase. Microsoft is continually working to enhance the security features of SQL Server, and Always Encrypted is no exception. In the future, we can expect to see more enhancements to Always Encrypted, such as support for additional encryption algorithms and key management systems.

Conclusion

SQL Server Always Encrypted is a powerful feature that provides enhanced security for sensitive data stored in databases. With client-side encryption, data is encrypted before being sent to the server, ensuring that the server never has access to the unencrypted data. Implementing Always Encrypted requires careful planning and execution, but it provides significant benefits in terms of data security. SQL Server Always Encrypted is an essential feature for organizations that need to protect sensitive data stored in their SQL Server databases. While there are challenges to implementing the feature, following best practices and ensuring compatibility with all applications and tools can help organizations successfully implement SQL Server Always Encrypted and improve their data security.

Thank You,
Vivek Janakiraman

Disclaimer:
The views expressed on this blog are mine alone and do not reflect the views of my company or anyone else. All postings on this blog are provided “AS IS” with no warranties, and confers no rights.