Azure SQL DB Managed Instances: We’re All GUIDs

Six is having problems adjusting to his clone status

Some funny things happen when you create databases up in a Managed Instance.

For Instance (HEH!), you may expect this to yield some fruitful results, but it Manages (HAH!) to defy logic.

But we get blank results! Mon Dieu!

But YourMom will faithfully be in sys.databases for you to not call for 3 months.

When we look that up in sys.master_files by database_id, we get back a Funky Bunch®

Your databases automagickally get created with an XTP file. For those of you unfamiliar, that’s Hekaton, AKA In-Memory OLTP, AKA IMOLTP, aka Xtreme Transaction Processing.

You can just smell the Monster Energy drink pee from here.

On the plus side, this prevents you for turning Auto Close on.

On the down side, you uh might accidentally use Hekaton. Be careful out there!

No more problems on the way

People who write scripts to analyze database-level metrics across DMVs (ahem) will have to make big adjustments to tie some of this stuff together. At least database_id seems to be in tact, but this could make some things awkward.

But then again, maybe the kind of people who write those kind of reports aren’t yearning for Cloud VMs where you drop your database off and feel a slight pang of guilt before going on vacation.

Like a retirement home for databases.

Thanks for reading!

Brent says: I was working on getting sp_Blitz to work with these guids, and squirreled away in the documentation is a note that they expect to change at least some stuff back to the database name before General Availability. I’m not sure if this means all of the DMVs, though (like msdb.dbo.backupset.)