This blog post was co-authored by Eric Hudson, Senior Product Marketing Manager, CADD & AI.
We’re excited to announce the preview of Azure SQL Database Managed Instance, a new deployment option in SQL Database that streamlines the migration of SQL Server workloads to a fully managed database service. This new Managed Instance deployment option provides full SQL Server engine compatibility and native virtual network (VNET) support.
“SQL Managed Instance is that happy medium we were looking for. We needed the power and compatibility of SQL Server, but without the management overhead and cost that comes with running VMs 24×7. Not only will we get that power and ease of management, we’ll also be able to use the Azure Hybrid Benefit, which allows us to use our existing SQL Server licensing through Software Assurance. Developing, deploying, and managing our application is getting a whole lot easier and cheaper with Azure and SQL Managed Instance.”
Robert Shurbet, Senior Software Development Professional, Pivot Technology Solutions
Migrate your databases to a fully-managed service
Azure SQL Database is a fully-managed database service, which means that Microsoft operates SQL Server for you and ensures its availability and performance. SQL Database also includes innovative
Azure database services for MySQL and PostgreSQL are fully managed, enterprise-ready services built using community version of MySQL and PostgreSQL database engines respectively. These services come with built-in high availability and ability to elastically scale compute and storage independently in seconds, helping you to easily adjust resources and respond faster to market and customer demands. Additionally, you benefit from unparalleled security and compliance, Azure IP advantage, as well as Azure’s industry leading global reach.
Since we announced these services in preview last year, users have been providing feedback helping drive product improvements and new features. As part of executing on customer feedback, I am really excited to announce the changes to the pricing model that will provide customers with more flexibility and help optimize costs.
Since the preview launch, we have been offering the Basic and Standard pricing tiers. We are continuing with the Basic tier, re-naming Standard to General Purpose and introducing a new premium tier called Memory Optimized to cater to workloads requiring faster in-memory performance. For more information about the General Purpose and Memory Optimized tiers, and when to use them, visit MySQL and PostgreSQL documentation.
Changing from “compute units” to vCores
Beginning today you
This blog post was co-authored by Anitha Adusumilli, Principal Program Manager, Azure Networking.
We are excited to announce the general availability of Virtual Network (VNet) Service Endpoints for Azure SQL Database in all Azure regions. This ability allows you to isolate connectivity to your logical server from only a given subnet or set of subnets within your virtual network. The traffic to Azure SQL Database from your VNet will always stay within the Azure backbone network. This direct route will be preferred over any specific routes that take Internet traffic through virtual appliances or on-premises.
There is no additional billing for virtual network access through service endpoints. Current pricing model for Azure SQL DB applies as is.
VNet service endpoints for SQL Data Warehouse (DW) continues to be in public preview, for all Azure regions.
Firewall rules and VNet Service Endpoints can be used together
Turning on VNet Service Endpoints does not override Firewall rules that you have provisioned on your SQL Server or Database. Both continue to be applicable.
VNet Service Endpoints don’t extend to on-premises. To allow access from on-premises, Firewall rules can be used to limit connectivity only to your public (NAT) IPs.
To enable VNet
Are you building a new application which requires low latency at any scale? Or are you in the process of migrating your NoSQL databases to the cloud? Or looking for the right resources to help you get started with Azure Cosmos DB?
Join us for one or all of a seven-week Azure Cosmos DB technical training series, which explores the capabilities and potential of Azure Cosmos DB. Whether you’re brand new to Azure Cosmos DB or an experienced user, you’ll leave this series with a better understanding of database technology and have the practical skills necessary to get started.
Azure Cosmos DB is the world’s first globally distributed, multi-model database service with native NoSQL support. Designed for the cloud, Azure Cosmos DB enables you to build planet-scale applications that bring data to where your users are with SLA-guaranteed low latency, throughput, and 99.99% availability.
In this training series, you’ll learn everything necessary to get your cloud database up and running. In the first session, we covered a technical overview of Azure Cosmos DB, and, in the following weeks, we’ll progress into deeper topics like migrating Mongo DB applications to Azure Cosmos DB, building serverless applications, and enabling real-time analytics with
The Graphical Execution Plan feature within SQL Server Management Studio (SSMS) is now supported for SQL Data Warehouse (SQL DW)! With a click of a button, you can create a graphical representation of a distributed query plan for SQL DW.
Before this enhancement, query troubleshooting for SQL DW was often a tedious process, which required you to run the EXPLAIN command. SQL DW customers can now seamlessly and visually debug query plans to identify performance bottlenecks directly within the SSMS window. This experience extends the query troubleshooting experience by displaying costly data movement operations which are the most common reasons for slow distributed query plans. Below is a simple example of troubleshooting a distributed query plan with SQL DW leveraging the Graphical Execution Plan.
The view below displays the estimated execution plan for a query. As we can see, this is an incompatible join which occurs when there is a join between two tables distributed on different columns. An incompatible join will create a ShuffleMove operation, where temp tables will be created on every distribution to satisfy the join locally before streaming the results back to the user. The ShuffleMove has become a performance bottleneck for this query:
Azure SQL Data Sync allows users to synchronize data between Azure SQL Databases and SQL Server databases in one-direction or bi-direction. This feature was first introduced in 2012. By that time, people didn’t host a lot of large databases in Azure. Some size limitations were applied when we built the data sync service, including up to 30 databases (five on-premises SQL Server databases) in a single sync group, and up to 500 tables in any database in a sync group.
Today, there are more than two million Azure SQL Databases and the maximum database size is 4TB. But those limitations of data sync are still there. It is mainly because that syncing data is a size of data operation. Without an architectural change, we can’t ensure the service can sustain the heavy load when syncing in a large scale. We are working on some improvements in this area. Some of these limitations will be raised or removed in the future. In this article, we are going to show you how to use data sync to sync data between large number of databases and tables, including some best practices and how to temporarily work around database and table limitations.
Special thanks to MSAsset engineering team’s Peter Liu (Senior Software Engineer), Vijay Kannan (Software Engineer), Sathya Muhandiramalage (Senior Software Engineer), Bryan Castillo (Principal Software Engineer) and Shail Batra (Principal Software Engineering Manager) for sharing their migration story with the Azure SQL Database product team.
Microsoft uses an internally written service called MSAsset to manage all Microsoft data center hardware around the world. MSAsset is used for tracking Microsoft’s servers, switches, storage devices, and cables across the company and requires 24/7 availability to accommodate break-fix requirements.
Before migrating to Azure SQL Database last year, MSAsset’s data tier consisted of a 107 GB database with 245 tables on SQL Server. The database was part of a SQL Server Always On Availability Group topology used for high availability and the scaling out of read-activity.
The MSAsset engineering team faced the following issues:
Aging hardware was not keeping up with stability and scale requirements. There was an increase in high severity data-tier incidents and no database administrator on staff to help with troubleshooting, mitigation, root cause analysis and ongoing maintenance. MSAsset’s database ran on SQL Server 2012. Developers and internal customers were increasingly requesting access to new SQL Server functionality.
After exploring various options
We are very happy to announce the general availability of geo-replication support for Azure Redis Cache. Redis Cache is Microsoft Azure’s Cache-as-a-Service offering, based on the popular open source Redis in-memory key-value store. With geo-replication support, Redis Cache joins a growing list of Azure services that enable developers and IT pros to build disaster recovery plans. This ensures the availability of mission-critical applications running on our cloud, even in the unlikely event of a widespread regional failure. In fact, customers can already design disaster resilient solutions on Azure, using Virtual Machines with Azure Site Recovery, Traffic Manager, and data services such as Cosmos DB, SQL Database, and now Redis Cache.
While announcing the general availability of geo-replication for Redis Cache, we would also like to take the opportunity to express our gratitude to everyone who has participated in the public preview. Your feedback has been invaluable to us and helped validate our implementation. Thank you!
Setting up geo-replication in Redis Cache
Geo-replication is a feature of the premium tier of Azure Redis Cache. You need a pair of premium cache instances before you can use geo-replication. If you already have a premium cache, you just need to add another one
Azure Cosmos DB Graph API is the first cloud database to provide graph functionality over a globally distributed managed service. This has enabled users to explore new ways of consuming their data with the use of the Gremlin language while still benefitting from global distribution, elastic scalability in storage and throughput, guaranteed low latency, consistency models, and enterprise-ready SLAs of Azure Cosmos DB.
In December, Azure Cosmos DB Graph API became generally available. This release includes several critical updates to the performance and latency, as well as expanding the application platforms that can be used with it. Here is a brief recap of the features included in the general availability release of Azure Cosmos DB Graph API.
Increased service performance and stability
Several performance and stability improvements have been applied to the Azure Cosmos DB Graph API service. These updates benefit the Gremlin query processing performance, as well as the connectivity experience when using any of the open-source Gremlin connectors. Additional fixes were also applied to the previously known Gremlin error parsing issues that used to be experienced.
Newly added support for Python and PHP application platforms!
Azure Cosmos DB Graph API now supports connections from Python and PHP applications
After reading this blogpost, you will be able to build your own custom email notifications for SQL Database Automatic tuning recommendations. We have listened to our customers requesting this functionality and have created a custom solution based on readily available technologies on Azure.
SQL Database performance tuning recommendations are generated by Azure SQL Database Automatic tuning. This solution provides peak performance and stable workloads through continuous database performance tuning utilizing Artificial Intelligence (AI).
Tuning recommendations are provided for each individual SQL database on Azure subscription for which Automatic tuning is enabled. Recommendations are related to index creation, index deletion, and optimization of query execution plans. Tuning recommendations are provided only in cases when AI considers them as beneficial to database performance.
Email notifications for Automatic tuning
Some of our customers have indicated a need to receive automated email notifications with suggested SQL Database Automatic tuning recommendations to be able to view and build automated alerts. For example, when the solution recommends that an index should be dropped to improve database performance, some customers would prefer to be notified of such event. Another customer scenario is, for example, emailing automated tuning recommendations to different database administrators in charge of different database