Introducing new update policy for Azure SQL Managed Instance
We’re excited to introduce the new update policy SQL Server 2025 for Azure SQL Managed Instance. Now in preview, SQL Server 2025 update policy brings you the latest SQL engine innovation while retaining database portability to the new major release of SQL Server. Update policy is an instance configuration option that provides flexibility and allows you to choose between instant access to the latest SQL engine features and fixed SQL engine feature set corresponding to 2022 and 2025 major releases of SQL Server. Regardless of the update policy chosen, you continue to benefit from Azure SQL platform innovation. New features and capabilities not related to the SQL engine – everything that makes Azure SQL Managed Instance a true PaaS service – are successively delivered to your Azure SQL Managed Instance resources. Update policy for each modernization strategy Always-up-to-date is a “perpetual” update policy. It has no end of lifetime and brings new SQL engine features to instances as soon as they are available in Azure. It enables you to always be at the forefront – to quickly adopt new yet production-ready SQL engine features, benefit from them in everyday operations and keep a competitive edge without waiting for the next major release of SQL Server. In contrast, update policies SQL Server 2022 and SQL Server 2025 contain fixed sets of SQL engine features corresponding to the respective releases of SQL Server. They’re optimized to fulfill regulatory compliance, contractual, or other requirements for database/workload portability from managed instance to SQL Server. Over time, they get security patches, fixes, and incremental functional improvements in form of Cumulative Updates, but not new SQL engine features. They also have limited lifetime, aligned with the period of mainstream support of SQL Server releases. As the end of mainstream support for the update policy approaches, you should upgrade instances to a newer policy. Instances will be automatically upgraded to the next more recent policy at the end of mainstream support of their existing update policy. What’s new in SQL Server 2025 update policy In short, instances with update policy SQL Server 2025 benefit from all the SQL engine features that were gradually added to the Always-up-to-date policy over the past few years, and not available in the SQL Server 2022 update policy. Let’s name few most notable features, with complete list available in the update policy documentation: Optimized locking Mirroring in Fabric Regular expression functions Vector data type and functions JSON data type and aggregate functions Invoking HTTP REST endpoints Best practices with Update policy feature Plan for the end of lifetime of SQL Server 2022 update policy if you’re using it today, and upgrade to a newer policy on your terms before automatic upgrade kicks in. Make sure to add update policy configuration to your deployment templates and scripts, so that you don’t rely on system defaults that may change in the future. Be aware that using some of the newly introduced features may require changing the database compatibility level. Summary and next steps Azure SQL Managed Instance just got new update policy SQL Server 2025. It brings the same set of SQL engine features that exist in the new SQL Server 2025 (currently in preview). Consider it if you have regulatory compliance, contractual, or other reasons for database/workload portability from Azure SQL Managed Instance to SQL Server 2025. Otherwise, use the Always-up-to-date policy which always provides the latest features and benefits available to Azure SQL Managed Instance. For more details visit Update policy documentation. To stay up to date with the latest feature additions to Azure SQL Managed Instance, subscribe to the Azure SQL video channel, subscribe to the Azure SQL Blog feed, or bookmark What’s new in Azure SQL Managed Instance article with regular updates.
Introducing the Azure SQL hub: A simpler, guided entry into Azure SQL
Choosing the right Azure SQL service can be challenging. To make this easier, we built the Azure SQL hub, a new home for everything related to Azure SQL in the Azure portal. Whether you’re new to Azure SQL or an experienced user, the hub helps you find the right service quickly and decide, without disrupting your existing workflows. For existing users: Your current workflows remain unchanged. The only visible update is a streamlined navigation pane where you access Azure SQL resources. For new users: Start from the Azure SQL hub home page. Get personalized recommendations by answering a few quick questions or chatting with Azure portal Copilot. Or compare services side by side and explore key resources, all without leaving the portal. This is one way to find it: Searching for "azure sql" in main search box or marketplace is also efficient way to get to Azure SQL hub Answer a few questions to get our recommendation and use Copilot to refine your requirements. Get a detailed side-by-side comparison without leaving the hub. Still deciding? Explore a selection of Azure SQL services for free. This option takes you straight to the resource creation page with a pre-applied free offer. Try the Azure SQL hub today in the Azure portal, and share your feedback in the comments!
How to setup alerts for deadlocks using Log Analytics
Managed Instance diagnostic events do not support sending deadlock information to Log Analytics. However, through auditing, it's possible to query failed queries along with their reported error messages—though this does not include deadlock XML. We will see how we can send information to Log Analytics and setup an alert for when a deadlock occurs. Step 1 - Deploy Log Analytics Create a Log Analytics workspace if you currently don't have one Create a Log Analytics workspace Step 2 - Add diagnostic setting On the Azure Portal, open the Diagnostic settings of your Azure SQL Managed Instance and choose Add diagnostic setting Select SQL Security Audit Event and choose has destination your Log Analytics workspace Step 3 - Create a server audit on the Azure SQL Managed Instance Run the query below on the Managed Instance Rename the server audit and server audit specification to a name of your choice. CREATE SERVER AUDIT [audittest] TO EXTERNAL_MONITOR GO -- we are adding Login audit, but only BATCH_COMPLETED_GROUP is necessary for query execution CREATE SERVER AUDIT SPECIFICATION audit_server FOR SERVER AUDIT audittest ADD (SUCCESSFUL_LOGIN_GROUP), ~ ADD (BATCH_COMPLETED_GROUP), ADD (FAILED_LOGIN_GROUP) WITH (STATE = ON) GO ALTER SERVER AUDIT [audittest] WITH (STATE = ON) GO Step 4 - Check events on Log Analytics It may take some time for records to begin appearing in Log Analytics. Open your Log Analytics workspace and choose Logs To verify if data is being ingested, run the following query in Log Analytics and wait until you start getting the first results: Make sure that you change servername with your Azure SQL Managed Instance name AzureDiagnostics | where LogicalServerName_s == "servername" | where Category == "SQLSecurityAuditEvents" | take 10 Example: Step 5 - (Optional) Create a deadlock event for testing Create a deadlock scenario so you can see a record on log analytics. Example: Open SSMS and a new query window under the context of a user database (you can create a test database just for this test). create a table on a user database and insert 10 records: create table tb1 (id int identity(1,1) primary key clustered, col1 varchar(30)) go insert into tb1 values ('aaaaaaa') go 10 You can close the query window or reuse for the next step. Open a new query window (or reuse the first query window) and run (leave the query window open after executing): begin transaction update tb1 set col1 = 'bbbb' where id = 1 Open a second query window and run (leave the query window open after executing): begin transaction update tb1 set col1 = 'bbbb' where id = 2 Go back to the first query window opened and run (the query will be blocked - will stay executing): update tb1 set col1 = 'bbbb' where id = 2 Go back to the second query window opened and run (this transaction will be victim of deadlock): update tb1 set col1 = 'bbbb' where id = 1 You can rollback and close all windows after the deadlock exception. Step 6 - (Optional) Check the deadlock exception on Log Analytics Note: the record can take some minutes to appear on Log Analytics Use the query below to obtain the Deadlock events for the last hour (we are looking for Error 1205) Make sure that you change servername with your Azure SQL Managed Instance name AzureDiagnostics | where TimeGenerated > ago(1h) | where LogicalServerName_s == "servername" | where Category == "SQLSecurityAuditEvents" | where succeeded_s == "false" | where additional_information_s contains "Err 1205, Level 13" Step 7 - Use query to Create an Alert Use the query below to create an Alert on Azure Log Analytics Make sure that you change servername with your Azure SQL Managed Instance name. The query checks for deadlocks that occurred on the previous hour. AzureDiagnostics | where TimeGenerated > ago(1h) | where LogicalServerName_s == "servername" | where Category == "SQLSecurityAuditEvents" | where succeeded_s == "false" | where additional_information_s contains "Err 1205, Level 13" Run the query and click on New alert rule Create the alert with the desired settingsPreparing for the Deprecation of TLS 1.0 and 1.1 in Azure Databases
Microsoft announced the retirement of TLS 1.0 and TLS 1.1 for Azure Services, including Azure SQL Database, Azure SQL Managed Instance, Cosmos DB, and Azure Database for MySQL by August 31, 2025. Customers are required to upgrade to a more secure minimum TLS protocol version of TLS 1.2 for client-server connections to safeguard data in transit and meet the latest security standards. The retirement of TLS 1.0 and 1.1 for Azure databases was originally scheduled for August 2024. To support customers in completing their upgrades, the deadline was extended to August 31, 2025. Starting August 31, 2025, we will force upgrade servers with minimum TLS 1.0 or 1.1 to TLS 1.2, and connections using TLS 1.0 or 1.1 will be disallowed, and connectivity will fail. To avoid potential service interruptions, we strongly recommend customers complete their migration to TLS 1.2 before August 31, 2025. Why TLS 1.0 and 1.1 Are Being Deprecated TLS (Transport Layer Security) protocols are vital in ensuring encrypted data transmission between clients and servers. However, TLS 1.0 and 1.1, introduced in 1999 and 2006 respectively, are now outdated and vulnerable to modern attack vectors. By retiring these versions, Microsoft is taking a proactive approach to enhance the security landscape for Azure services such as Azure databases. Security Benefits of Upgrading to TLS 1.2 Enhanced encryption algorithms: TLS 1.2 provides stronger cryptographic protocols, reducing the risk of exploitation. Protection against known vulnerabilities: Deprecated versions are susceptible to attacks such as BEAST, POODLE, and others TLS 1.2 addresses. Compliance with industry standards: Many regulations, including GDPR, PCI DSS, and HIPAA, mandate the use of secure, modern TLS versions. How to Verify and Update TLS Settings for Azure Database Services For instructions on how to verify your Azure database is configured with minimum TLS 1.2 or upgrade the minimum TLS setting to 1.2, follow the respective guide below for your database service. Azure SQL Database and Azure SQL Managed Instance The Azure SQL Database and SQL Managed Instance minimum TLS version setting allows customers to choose which version of TLS their database uses. Azure SQL Database To identify clients that are connecting to your Azure SQL DB using TLS 1.0 and 1.1, SQL audit logs must be enabled. With auditing enabled you can view client connections: Connectivity settings - Azure SQL Database and SQL database in Fabric | Microsoft Learn To configure the minimum TLS version for your Azure SQL DB using the Azure portal, Azure PowerShell or Azure CLI: Connectivity settings - Azure SQL Database and SQL database in Fabric | Microsoft Learn Azure SQL Managed Instance To identify clients that are connecting to your Azure SQL MI using TLS 1.0 and 1.1, auditing must be enabled. With auditing enabled, you can consume audit logs using Azure Storage, Event Hubs or Azure Monitor Logs to view client connections: Configure auditing - Azure SQL Managed Instance | Microsoft Learn To configure the minimum TLS version for your Azure SQL MI using Azure PowerShell or Azure CLI: Configure minimal TLS version - managed instance - Azure SQL Managed Instance | Microsoft Learn Azure Cosmos Database The minimum service-wide accepted TLS version for Azure Cosmos Database is TLS 1.2, but this selection can be changed on a per account basis. To verify the minimum TLS version of the minimalTlsVersion property on your Cosmos DB account: Self-serve minimum tls version enforcement in Azure Cosmos DB - Azure Cosmos DB | Microsoft Learn To configure the minimum TLS version for your Cosmos DB account using the Azure Portal, Azure PowerShell, Azure CLI or Arm Template: Self-serve minimum tls version enforcement in Azure Cosmos DB - Azure Cosmos DB | Microsoft Learn Azure Database for MySQL Azure Database for MySQL supports encrypted connections using TLS 1.2 by default, and all incoming connections with TLS 1.0 and TLS 1.1 are denied by default, though users are allowed to change the setting. To verify the minimum TLS version configured for your Azure DB for MySQL server tls_version server parameter using the MySQL command-line interface: Encrypted Connectivity Using TLS/SSL - Azure Database for MySQL - Flexible Server | Microsoft Learn To configure the minimum TLS version for your Azure DB for MySQL server using the MySQL command-line interface: Configure Server Parameters - Azure Portal - Azure Database for MySQL - Flexible Server | Microsoft Learn If your database is currently configured with a minimum TLS setting of TLS 1.2, no action is required. Conclusion The deprecation of TLS 1.0 and 1.1 marks a significant milestone in enhancing the security of Azure databases. By transitioning to TLS 1.2, users can ensure highly secure encrypted data transmission, compliance with industry standards, and robust protection against evolving cyber threats. Upgrade to TLS 1.2 now to prepare for this change and maintain secure, compliant database connectivity settings.Breaking Limits: Full-Length SQL Audit Statements Now Supported for Azure SQL DB
We’re excited to announce a major enhancement to SQL auditing in Azure SQL Database, the removal of the 4,000-character truncation limit for audit records. What’s Changed? Previously, audit records were limited to storing 4,000 characters for fields like statement and data_sensitivity_information. Any content beyond that threshold was truncated, potentially leaving out critical details from lengthy queries or sensitive data traces. With this update, statements are no longer truncated. Audit logs now capture the entire content of auditable actions, ensuring complete visibility and traceability for security and compliance teams. Why It Matters Improved Security & Compliance: Full-length statements provide better context for threat detection and forensic analysis. Enhanced Customer Experience: No more guessing what was left out—customers get the full picture. Feature Parity with SQL Server and Managed Instance: This update brings Azure SQL Database in line with SQL Server and Managed Instance capabilities, ensuring consistency across environments.Enhanced Server Audit for Azure SQL Database: Greater Performance, Availability and Reliability
We are excited to announce a significant update to the server audit feature for Azure SQL Database. We have re-architected major portions of SQL Auditing resulting in increased availability and reliability of server audits. As an added benefit, we have achieved closer feature alignment with SQL Server and Azure SQL Managed Instance. Database auditing remains unchanged. In the remainder of this blog article, we cover Functional changes Changes Affecting customers Sample queries Call for action Implementation and Notification Time-based Filtering Functional Changes In the current design when server audit is enabled, it triggers a database level audit and executes one audit session for each database. With the new architecture, enabling server audit will create one extended event session at the server level that captures audit events for all databases. This optimizes memory and CPU and is consistent with how auditing works in SQL Server and Azure SQL Managed Instance. Changes Affecting Customers Folder Structure change for storage account Folder structure change for Read-Only replicas Permissions required to view Audit logs One of the primary changes involves the folder structure for audit logs stored in storage account containers. Previously, server audit logs were written to separate folders, one for each database, with the database name serving as the folder name. With the new update, all server audit logs will be consolidated into a single folder which is ‘Master’ folder. This behavior is the same as Azure SQL Managed Instance and SQL Server For Read-Only database replicas, which previously had their logs stored in a read-only folder, those logs will now also be written into the Master folder. You can retrieve these logs by filtering on the new column ‘is_secondary_replica_true’. Please note that the audit logs generated after deployment will adhere to the new folder structure, while the existing audit logs will stay in their current folders until their retention periods expire. Sample Queries To help you adopt these changes in your workflows, here are some sample queries: Current New To Query audit logs for a specific database called "test" SELECT * FROM sys.fn_get_audit_file ('https://testaudit.blob.core.windows.net/sqldbauditlogs/auditpoc/test/ SqlDbAuditing_ServerAudit_NoRetention/2023-01-29/07_06_40_590_0.xel', default, default) SELECT * FROM sys.fn_get_audit_file ('https://testaudit.blob.core.windows.net/sqldbauditlogs/auditpoc/master/SqlDbAuditing_ServerAudit_NoRetention/2023-01-29/07_06_40_590_0.xel', default, default) WHERE database_name = 'test'; To query audit logs for test database from read only replica SELECT * FROM sys.fn_get_audit_file ('https://testaudit.blob.core.windows.net/sqldbauditlogs/auditpoc/test/SqlDbAuditing_ServerAudit_NoRetention/2023-01-29/RO/07_06_40_590_0.xel', default, default) SELECT * FROM sys.fn_get_audit_file ('https://testaudit.blob.core.windows.net/sqldbauditlogs/auditpoc/master/SqlDbAuditing_ServerAudit_NoRetention/2023-01-29/07_06_40_590_0.xel', default, default) WHERE is_secondary_replica_true = 'true'; Permissions Control database on user database VIEW Database SECURITY AUDIT permission in User Databases Implementation and Notifications We are rolling out this change region-wise. Subscription owners will receive notifications with the subject “Update your scripts to point to a new folder for server level audit logs” for each region as the update is implemented. It is important to update any scripts that refer to the folder structure to retrieve audit logs based on the database name for the specific region. Note that this change applies only to server-level auditing; database auditing remains unchanged. Call for Action These actions apply only to customers who are using storage account targets. No action is needed for customers using Log Analytics or Event hubs. Folder references: Change the reference for audit logs from the database name folder to the Master folder and use specific filters to retrieve logs for a required database. Read -Only Database Replicas: Update references for audit logs from the Read-Only replica folder to the Master folder and filter using the new parameter as shown in the examples. Permissions: Ensure you have the necessary control server permissions to review the audit logs for each database using fn_get_audit_file. Manual Queries This update also applies to manual queries where you use fn_get_audit_file to retrieve audit logs from the storage account Time-based filtering To enhance your ability to query audit logs using filters, consider using efficient time-based filtering with the fn_get_audit_file_v2 function. This function allows you to retrieve audit log data with improved filtering capabilities. For more details, refer to the official documentation here.
Do you need more memory on Azure SQL Managed Instance?
Azure SQL Managed Instance is a fully-managed SQL Server database engine where you can easily choose size of the instance with the amount of resources you want to use. Sometime it is hard to determine what instance size you need to use for your workload and one of the criteria might be the amount of memory that you need. This article enables you to check do you have enough memory on your Azure SQL Managed Instance.Increase data file size to improve HammerDB workload performance on General Purpose Managed Instance
The General Purpose tier of Managed Instance uses Azure Premium Storage to store database files. In Azure Premium Storage IO performance depends on the file size. Increasing file size might be an easy way to improve your performance. In this post you will see how to increase performance of HammerDB workload from 20K transactions/minute to 100K-300K transactions/minute by increasing the database file size.
