Managed Instance Impressions

Question

Managed Instance Impressions

Steve Jones - SSC Editor

SSC Guru

Points: 736183
More actions
May 27, 2024 at 12:00 am

#4401876

Comments posted to this topic are about the item Managed Instance Impressions

Viewing 11 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic. Login to reply

Jo Pattyn SSC-Dedicated Points: 32345 More actions · Answer 1

We're currently using to much on-premises addons (sql agent, SSRS, SSIS, linked servers). Currently spoiled with our hardware infrastructure.

If we move, it would be Azure SQL for small databases.

mikepetrak Newbie Points: 4 More actions · Answer 2

Thanks for the article, Steve. Good timing. Unfortunately, my first impression of Azure SQL Managed Instance hasn't been a great one so far as we've been trying to do an application from IaaS SQL 2016 Std Ed to AZ MI re-plaftform for months now. We're struggling mainly with excessive initial CompileTime for a dozen stored procedures and queries as well as a long-running and bloating partition maintenance job. I posted the details on DBA StackExchange last week and reached out to #sqlhelp on x.com today. We're still working through this issue with a Microsoft Sev B Support case and are working with level 3 support. I appreciate any help that we can get on this one. Thank you. https://dba.stackexchange.com/questions/339748/azure-sql-managed-instance-1-excessive-initial-compile-times-leading-to-app-ti

Steve Jones - SSC Editor SSC Guru Points: 736183 More actions · Answer 3

You've got a case, so I won't link that, but I might post a note in the MVP list in case anyone has ideas.

Also, dropped a note on Twitter

Johan Bijnens SSC Guru Points: 135369 More actions · Answer 4

IMHO AzureMI have been brought to life to have people be more keen to (try to) migrate and land on an environment they are familiar with.

DBMail needs specific attantion
SQLAgent doesn't hold history as we are used to On-Prem ( you need to persist history yourself )
Still using Trace to file ?
It has evolved vastly ! And still is.
If your usage pattern is 24/7 stable, chances of encountering the effects of throttling are low, but you always need to keep that in mind.
Instances are failed over as MS wishes. If you expect 24/7/365 you may encounter issues.
We've been using SQLMI since 2018 and try to host db with alike usage patterns on them to avoid throttling
AAD-integration has been enhenced over time.
As we are always avoiding linked servers, we don't have issues with it.
Keep in mind you also need to follow SQLMI background evolution (supporting hardware) and migrate if you expect it to perform better for you ( $ )

Johan

Learn to play, play to learn !

Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:

- How to post Performance Problems
- How to post data/code to get the best help[/url]

- How to prevent a sore throat after hours of presenting ppt

press F1 for solution, press shift+F1 for urgent solution 😀

Need a bit of Powershell? How about this

Who am I ? Sometimes this is me but most of the time this is me

3rd Normal Form SSC-Addicted Points: 463 More actions · Answer 5

In working for the State of Wisconsin I do see any advantage of the cloud. For starters we have really good data centers in Madison and Milwaukee that meet or exceed our SLA. The advantage of on-premise is fixed cost over variable cost. We currently have SSD for storage, so no spinning disk and are on the path of updating with new servers and SAN. From my understanding hardware cost keep dropping and the fiber optics between our two data centers are high speed. While I do not understand the licensing aspect completely because State Agencies request from a centralized data center, 8 CPU's with 64 GB and a 1TB of storage is less than $20,000 a year.

When the cloud first came out I was excited and wanted to go to the cloud. I think if one does not have really good data centers, it makes sense. Being a DBA shielded from a lot of the finances in State Government, it really comes down to ROI and politics. Both of those aspects are above my pay grid.

Eric M Russell SSC Guru Points: 125561 More actions · Answer 6

A few years ago, we considered running our data warehouse on Azure Managed Instance and even had running there in parallel for a while. But we ultimately decided for economic reasons to keep it in our data center. That, plus most of our analytic tools like SSAS and other BI processes are also in our data center and network ingress / egress charges and performance was an issue.

"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

TL SSC-Addicted Points: 469 More actions · Answer 7

We were in on the Beta for the managed instances service as we had several groups quite excited about it. Having just completed a lift and shift of five datacenters worth of servers into Azure or AWS it seemed like a logical next step towards being more "cloud native" for some systems. Turned out to not meet their needs at that time. The limitations of the product at the time, combined with a cost / benefit of it just didn't work for us.

sqlrider SSC Enthusiast Points: 104 More actions · Answer 8

At the gigs I've worked at in the last five years, I've seen an increasing number of use cases that fit MI thanks to the expanding feature set, but also found it often hasn't been considered due to the historic limitations giving it a bad rep. And there's still a fair bit of SSIS/SSRS/SSAS around which throws a spanner in the works. My overall impression is it's not used that much compared to IaaS for legacy migrations, and new stuff using Azure SQL DB.

https://sqlrider.net - My technical blog

Steve Jones - SSC Editor SSC Guru Points: 736183 More actions · Answer 9

Steve Jones - SSC Editor

SSC Guru

Points: 736183

May 30, 2024 at 9:44 pm

#4425199

Interesting impressions. Thanks

bperry 32054 Grasshopper Points: 20 More actions · Answer 10

We migrated to SQL MI from SQL Server 2014 on VMs around 2022 and we were really happy with it. We had a few minor SQL Server Agent jobs that we moved to stored procedures invoked by Data Factory. The cost was slightly cheaper than what we were paying, but coming from a small team, we loved not having to manage backups and patching. Honestly, I've never found a foolproof way to manage SQL Agent on an AG, so I was happy to ditch SQL Agent.

The only things I wish we had available was the ability to expand our SQL Server AG to SQL Managed Instance, which after Googling it just now, appears to be available as a Managed Instance link. This either wasn't available or I wasn't aware of it at the time. The second thing would be the ability to enable synchronous commit across two different regions. I understand that most organizations wouldn't want to use that design, but we used it in our SQL Server AG and we never experienced performance issues. We needed a fast response time, but could tolerate the ~100ms overhead it added.