Azure Data Studio Retirement
We’re announcing the upcoming retirement of Azure Data Studio (ADS) on February 6, 2025, as we focus on delivering a modern, streamlined SQL development experience. ADS will remain supported until February 28, 2026, giving developers ample time to transition. This decision aligns with our commitment to simplifying SQL development by consolidating efforts on Visual Studio Code (VS Code) with the MSSQL extension, a powerful and versatile tool designed for modern developers. Why Retire Azure Data Studio? Azure Data Studio has been an essential tool for SQL developers, but evolving developer needs and the rise of more versatile platforms like VS Code have made it the right time to transition. Here’s why: Focus on innovation VS Code, widely adopted across the developer community, provides a robust platform for delivering advanced features like cutting-edge schema management and improved query execution. Streamlined tools Consolidating SQL development on VS Code eliminates duplication, reduces engineering maintenance overhead, and accelerates feature delivery, ensuring developers have access to the latest innovations. Why Transition to Visual Studio Code? VS Code is the #1 developer tool, trusted by millions worldwide. It is a modern, versatile platform that meets the evolving demands of SQL and application developers. By transitioning, you gain access to cutting-edge tools, seamless workflows, and an expansive ecosystem designed to enhance productivity and innovation. We’re committed to meeting developers where they are, providing a modern SQL development experience within VS Code. Here’s how: Modern development environment VS Code is a lightweight, extensible, and community-supported code editor trusted by millions of developers. It provides: Regular updates. An active extension marketplace. A seamless cross-platform experience for Windows, macOS, and Linux. Comprehensive SQL features With the MSSQL extension in VS Code, you can: Execute queries faster with filtering, sorting, and export options for JSON, Excel, and CSV. Manage schemas visually with Table Designer, Object Explorer, and support for keys, indexes, and constraints. Connect to SQL Server, Azure SQL (all offerings), and SQL database in Fabric using an improved Connection Dialog. Streamline development with scripting, object modifications, and a unified SQL experience. Optimize performance with an enhanced Query Results Pane and execution plans. Integrate with DevOps and CI/CD pipelines using SQL Database Projects. Stay tuned for upcoming features—we’re continuously building new experiences based on feedback from the community. Make sure to follow the MSSQL repository on GitHub to stay updated and contribute to the project! Streamlined workflow VS Code supports cloud-native development, real-time collaboration, and thousands of extensions to enhance your workflows. Transitioning to Visual Studio Code: What You Need to Know We understand that transitioning tools can raise concerns, but moving from Azure Data Studio (ADS) to Visual Studio Code (VS Code) with the MSSQL extension is designed to be straightforward and hassle-free. Here’s why you can feel confident about this transition: No Loss of Functionality If you use ADS to connect to Azure SQL databases, SQL Server, or SQL database in Fabric, you’ll find that the MSSQL extension supports these scenarios seamlessly. Your database projects, queries, and scripts created in ADS are fully compatible with VS Code and can be opened without additional migration steps. Familiar features, enhanced experience VS Code provides advanced tools like improved query execution, modern schema management, and CI/CD integration. Additionally, alternative tools and extensions are available to replace ADS capabilities like SQL Server Agent and Schema Compare. Cross-Platform and extensible Like ADS, VS Code runs on Windows, macOS, and Linux, ensuring a consistent experience across operating systems. Its extensibility allows you to adapt it to your workflow with thousands of extensions. If you have further questions or need detailed guidance, visit the ADS Retirement page. The page includes step-by-step instructions, recommended alternatives, and additional resources. Continued Support With the Azure Data Studio retirement, we’re committed to supporting you during this transition: Documentation: Find detailed guides, tutorials, and FAQs on the ADS Retirement page. Community Support: Engage with the active Visual Studio Code community for tips and solutions. You can also explore forums like Stack Overflow. GitHub Issues: If you encounter any issues, submit a request or report bugs on the MSSQL extension’s GitHub repository. Microsoft Support: For critical issues, reach out to Microsoft Support directly through your account. Transitioning to VS Code opens the door to a more modern and versatile SQL development experience. We encourage you to explore the new possibilities and start your journey today! Conclusion Azure Data Studio has served the SQL community well,but the Azure Data Studio retirement marks an opportunity to embrace the modern capabilities of Visual Studio Code. Transitioning now ensures you’re equipped with cutting-edge tools and a future-ready platform to enhance your SQL development experience. For a detailed guide on ADS retirement , visit aka.ms/ads-retirement. To get started with the MSSQL extension, check out the official documentation. We’re excited to see what you build with VS Code!Announcing Azure SQL Migration extension for Azure Data Studio - public preview
Use the Azure SQL Migration extension for Azure Data Studio to migrate to either Azure SQL Managed Instance (Platform-as-a-Service) or to SQL Server on Azure Virtual Machines (Infrastructure-as-a-Service). As part of this Public Preview announcement, the extension will support migrations for both online (for migrations that require minimal downtime) and offline (for migrations where downtime persists through the duration of the migration) modes that suit the requirements of various applications.
Simplify Azure SQL Virtual Machines HA and DR configuration by adopting multi subnet approach
SQL Server on Azure Virtual Machines is the best option to migrate your SQL Server workloads maintaining complete SQL Server compatibility and operating system level access. It is ideal destination for lift and shift or rehost migration approach. At the outset, High Availability (HA) & Disaster Recovery (DR) technologies for Azure SQL VMs are no different than on-premises world with following options: Always on Availability Groups (AG) Always On Failover Cluster Instances (FCI) Log Shipping Backup & Restore Azure Site Recovery (Azure only) Choosing an HA & DR technology for the database depends on the application’s business requirements for Recovery Time Objective (RTO) and Recovery Point Objective (RPO). While it’s the same SQL Server running on Azure virtual machines, there are some Azure infrastructure specific nuances when configuring HA & DR. Currently, for AG listener and FCI there is a dependency on Azure Load Balancer to get floating IP functionality within a single subnet, due to lack of Address Resolution Protocol (ARP) in public cloud. We do understand that Azure Load Balancer does introduce additional management and operational overhead for connecting to AG listener and FCI. Azure Load Balancer also induces failover latency of 10 seconds for the load balancing probe (2 unhealthy threshold at 5 second interval being the minimum) to detect the new SQL Server primary. To address this challenge, we did release an alternative way of using Distributed Network Name (DNN) for AG listener and FCI that avoids the need of having Azure Load Balancer. But DNN does come with following limitations: Works only on SQL Server versions starting with either SQL Server 2019 CU8 and later, SQL Server 2017 CU25 and later, or SQL Server 2016 SP3 and later on Windows Server 2016 and later. DNN AG listener MUST be configured with a unique port. The port cannot be shared with any other connection on any replica. DNN AG listener cannot use SQL Server default port of 1433 There are additional considerations when using DNN with AG. In case of FCI, even after creating DNN the original virtual network name (VNN) and virtual IP cannot be deleted as they are necessary components of the FCI infrastructure. In addition, there is another step needed to prevent the VNN virtual IP address from being assigned to another resource in Azure as a duplicate. There are additional considerations when using DNN with FCI. Now, you can simplify Azure SQL VM HA & DR configuration by deploying VMs in multiple subnets and thus eliminate the need for an Azure Load Balancer. Multi subnet configuration helps to match on-premises experience for connecting to your AG listener or FCI. Multi subnet configuration works natively on all supported versions of SQL Server & Windows Server simplifying deployment, maintenance and improving failover time and is Generally Available (GA). Here's a reference architecture for typical AG with two replicas SQL-VM-1 and SQL-VM-2 in two separate subnets SQL-Subnet-1 and SQL-Subnet-2 respectively thus achieving multi subnet configuration. Figure 1: Typical multi subnet AG configuration with two replicas. In multi subnet configuration each AG replica or FCI node will be in separate subnet. These subnets can be Within a virtual network in one region (Typical HA scenario) In different virtual network across Azure regions (Typical DR scenario) Prerequisite for multi subnet approach is Secondary IP and having MultiSubnetFailover=True in connection string. By using Secondary IP, Windows Server Failover Cluster and SQL Server leverages OR Dependency for cluster IP and AG Listener IP/ FCI virtual IP as shown below thus completing eliminating the need for Azure Load Balancer. Figure 2: Windows Server 2016 Failover Cluster leveraging OR Dependency between secondary IPs. Figure 3: AG listener cluster resource leveraging OR Dependency between secondary IPs. Figure 4: AG listener in SSMS is mapped to the two secondary IPs. Figure 5: SQL Server FCI Virtual Network Name (VNN) leveraging OR Dependency between secondary IPs. Here’s a table showing various approaches for Azure SQL VM HA & DR configuration and multi subnet is highly recommended as it offers simplicity without any limitations and failover latency. To summarize, multi subnet configuration greatly simplifies HA and DR for Azure SQL VMs, and we hope you take advantage of it. Review following articles for detailed step by step guidance of setting up AG and FCI. Tutorial: Prerequisites for AG in multiple subnets - SQL Server on Azure VM | Microsoft Docs Tutorial: Configure availability group in multiple subnets - SQL Server on Azure VM | Microsoft Docs Prepare virtual machines for an FCI - SQL Server on Azure VM | Microsoft Docs Create an FCI with Azure shared disks - SQL Server on Azure VM | Microsoft Docs Frequently asked questions reg secondary IP and multi subnet configuration How many secondary IPs are needed for an AG listener? To create an AG listener, you need a dedicated secondary IP per each replica VM. Is there a limit for number of secondary IPs? Yes, there is a limit on the number of private IPs - 256 private IPs per NIC, 256 private IPs per VM. Is assigning and un assigning secondary IP to a VM NIC an online operation with no impact to VM? Yes, secondary IP Assignment has no impact on the VM. Is there any perf impact to VM’s network traffic when multiple secondary private IPs are assigned? No. The total VM bandwidth is shared among all the IP addresses. Any implication of VM size (VM series) and resize (VM scale up and scale down) on secondary IP? None How does public IP for secondary IP work? You can assign a public IP for any private IP on the NIC, however, traffic usually goes outbound from the primary Public IP: Multiple IP addresses for Azure virtual machines - Portal | Microsoft Docs Can public IP for secondary IP be used for AG listener or FCI to enable connectivity to SQL Server originating from internet? Yes, this is just like any other public IP Any orthogonality issue with other networking features like Accelerated Networking, VNET peering in same/different region, Express Route, Inter VM traffic in multi subnet etc.? None Is there any cost associated with secondary IP? Not with private IP but with Public IP Pricing - Virtual Machine IP Address Options | Microsoft Azure Are the secondary IPs used for cluster and AG listener/FCI reserved? Yes, when a secondary IP configuration is saved then the IP is reserved and won’t be assigned to any other VM/device.
Beat SQL Server 2008/R2 End of Support by moving to Azure VM for three years of free security update
Today, On July 9, 2019, support for SQL Server 2008 and 2008 R2 ended. But there is still time to protect those workloads by rehosting to Azure SQL Database Managed Instance to run on latest version of SQL Server or to SQL Server virtual machines to get three years of automated Extended Security Updates at no additional charge and upgrade to a newer version when ready.Considerations of Data Partitioning on Spark during Data Loading on Clustered Columnstore Index
In this article, we have used Azure Databricks spark engine to insert data into SQL Server through a parallel stream (multiple threads loading data into a table) using a single input file. The destination could be a Heap, Clustered Index* or Clustered Columnstore Index. This article is to showcase how to take advantage of a highly distributed framework provided by spark engine by carefully partitioning the data before loading it into a Clustered Columnstore Index of a relational database like SQL Server or Azure SQL Database.Azure Monitor SQL Insights – Preview
Azure Monitor SQL insights (Preview) Comprehensive and reliable monitoring is a top priority for all SQL customers. The Azure SQL and Azure Monitor teams are proud to announce the preview of Azure Monitor SQL insights: a new, Azure-native monitoring experience for almost any SQL deployment in Azure.
