>> Hello everyone, I'm Colin Murphy.
I'm a Senior Product Marketing Manager at Microsoft.
I'm joined here today by Alain,
Senior Program Manager with Azure SQL Database. Alain, welcome.
>> Thank you very much for having me.
>> Today, Alain is going to teach us something very, very simple.
Just basic native backup and restore
in Azure SQL Database Managed Instance.
>> Yes, thanks Colin.
So essentially, what we are going to look at today is how we do
native backup restores from On-Prem into Managed Instance,
and the major reason why this is important is because
this functionality wasn't previously
supported in Azure SQL Database.
So it really is a big enabler for customers that are trying to
migrate legacy applications that
have databases that are sitting in SQL Server today.
So if we come and look at the code here,
you'll see in my Management Studio,
I'm connected to two different databases.
So the one here is a SQL 2017 that's running on a VM.
Now, that VM could be
On-Premise or it could be in Azure as it is in this case.
We can very that quite easily.
You can see here, if I run this you can see, oh,
I'm in the wrong context,
let's get rid of this one. Run that.
You'll see here that this is my SQL Database MI demo,
but this is the VM and it is running SQL Server 2017.
So the first thing that you've got to do when you're doing
these backups is you have to go create credentials.
So your credentials are essentially a way for
SQL to understand how to get into a blobstore.
The reason that that's important is because we only
support backups and restores from URL for Managed Instance.
So you can see here that I have credentials into this blob
over here which is basically
the SQL DB-MI store in the backups folder specifically.
So all I have to do is execute the backup script,
to go do a backup of this tutorial database and
it'll go do it straight into that blobstore.
Now, we can also go look here
just so that we can show you what it
looks like when it hits Managed Instance.
We can go and look this database that we just did a backup of
is sitting in compatibility 110.
So it's older than the instance that it's running in.
If we then come over to our Managed Instance,
and we can look at that quite easily,
you'll see here we are connected to a managed instance.
You can see that by the way that that name is structured,
but you can also see by the version that this is SQL Azure.
So it's an evergreen environment.
It's running the latest SQL Codebase.
There is no more additions or versions like 2017 or anything.
So the first thing we're going to do,
we're just going to make sure that the database doesn't exist.
Then exactly the same thing as I did with the SQL 2017 Instance,
we can come look here and you'll see I have the credentials for
that exact same Blobstore
where we did the backup to, sitting over there.
Then we can run very simply
a restore operation like that from the Blobstore.
This will take a little bit of time to run because essentially,
it has to go fetch and it has to validate that backup.
Then the minute that backup has been restored,
we can go and look at the same characteristics that we
did on the SQL 2017 Server.
You'll see that Managed Instance has actually maintained
the compatibility level of that database which is scoped down.
So that's a very important key differentiator,
especially for customers who are trying to
bring their legacy applications up with them into Azure.
So maintaining the older versions of SQL,
is a really big part of Managed Instance and how
we try and make it easy for customers to move up into Azure.
So we just have to wait,
it's probably going to take a while like 10 seconds or so.
>> So Alain, this is just a great way for doing,
like just the offline migration for Legacy System,
and then my question is we're doing it to a URL,
that's mainly for security reasons because
Managed Instance is an Athena, correct?
>> Well, that's part of it.
The security is definitely a part
of it which is why we use the URLs.
But the other bigger part of it is really around because
Managed Instance is isolated inside its own vNet,
it has no way of
understanding how to connect to
a file store like you would in traditional SQL.
So in normal SQL, you would be able to say, "Oh, well,
I want to go store my backup on
this network drive and then be able to restore from it."
Managed Instance wouldn't know how to get there,
because it doesn't reside on
normal infrastructure like a normal database would.
>> Make sense.
>> So here on the demo, you can now see we finished,
took about a minute or so to run that backup.
Then if we can look and we do
the exact same query that we did on the previous one,
you'll see the tutorial databases back online now,
and we've preserved the compatibility at 110 for this database.
Really, it's that simple.
It's not harder than that to do native backup restores.
So you can easily move existing data assets,
you can move them up into the Cloud,
and there's no more additional overhead than
what you would have done for years On-Prem using SQL Server.
>> All right. Thanks Alain. Thank you everyone.
So thanks Alain for showing us how easy it is to
do backups on Azure SQL Database Managed Instance.
So hope you like this,
and like us and subscribe to this channel.
We'll share the URL with you where you
can learn more information. Thank you very much.
[MUSIC]