[MUSIC]
>> Hello, everyone. My name is Colin Murphy,
Product Marketing Manager at Microsoft.
I'm joined again today by Raj. Hi Raj, welcome.
>> How are you?
>> Okay, thanks. Raj is going to give
us a little bit more of a deeper dive into some of the tools,
one of the tools and services to help you move your databases.
So hypothetical, if I had
a SQL Server 2008 R2 just end of support,
what would be one of the main tools I'd use
to assess how I was going to migrate?
>> Sounds good. So before I go to the tools,
let me introduce myself quickly.
My name is Raj Pochiraju,
Principal Engineering Architect in Azure data engineering.
My core focus is to
build the tools and services that help customers
to do the seamless migrations from
their on-premises databases to Azure database platforms.
As part of that, we
built the assessment tools and as well as the migration tools,
so customers can use the assessment tools to really assess
their on-premises databases and really understand
what it really takes to migrate them to the Azure,
what specific target that is good fit for
them and all that assessment that they will get.
So in today specifically to answer your question,
I have a tool called Data Migration Assistant
tool that really help customers
to take a look at it and assess
their on-premises databases based on the workload characteristics.
This tool really helps them to find out
what specific Azure database platform is
a good fit for them
so that they can be able to migrate with less effort,
and also it provides all the different things that they need to
fix if needed after the migration is done.
So it gives you a competency of report and all that.
So the tool that I'm going to be talking about,
the Data Migration Assistant tool as you see here.
This is the tool which is publicly
downloadable from Microsoft Download Center.
This tool has been there for 2016 August timeframe.
Since then, our customers use it to
assess more than two million databases.
So I already downloaded this tool,
and then it's pretty easy to do an assessment with my tool.
You just click on this plus button here.
There are a couple of options, one is assessment and migration.
Probably, a test assessment here,
and you provide your source step as SQL Server.
We also help you to assess if you are
migrating from AWS RDS SQL Server as well.
Then you want to migrate to Managed Instance,
for example, you create that project.
There are a couple of options here.
One is the check database compatibility,
where we look at all your schema of
your database and find out if there are any compatibility issues.
That means if there is any legacy syntax that is being in use.
>> Like CLR, if I got some CLR.
>> Yes, CLR and non-ANSI joins,
this kind of stuff.
>> Detect all this.
>> Yes, detect and then we'll also provide
you whether it is a migration blocker
or is something that you can address it later point of time.
Each time, we also provide you
a comprehensive recommendations how to fix it as well.
>> That's very useful.
>> Yeah. Then a check feature parity option,
this is more to look at beyond your SQL database,
but also any other features that are being used at
the SQL Instance level like linked servers,
SSIS packages for ETL jobs,
and SQL Server agent jobs.
We look at those ones as well and find out if there are
any issues in those objects that cannot be migrated.
Not only that, we also integrated this with Azure migrate hub,
which provides a holistic view off
your migrations including servers,
applications, and as well as databases.
There you can really see the relative readiness
of your databases migrating to Azure,
the low-hanging fruits that you can migrate
the specific databases with less effort.
So you can see that as well in my demo.
>> Oh wow, okay.
>> Yeah. Then you select this one,
and then you simply connect to your SQL Server.
Just in this case, MySQL Instance is 2008 to command you.
>> A pretty common one.
>> Pretty common one, and then click on that.
You just select all DBs,
if you want to migrate them entire sequence instance.
We also provided an option here,
if there are any queries that are directly coming
from the app layer or the database layer.
So you can collect some traces representing
your workload in the form of
the extended events or in the form of the sequel cases,
and then bring those traces here so that we can analyze.
So you will have a single view where we assess
your schema and we assess your application error as well.
That way we'll know the
various places that you need to fix the things.
I'm just going to click "Add. " In case
if you have multiple sequence instances,
you can now use this Add sources button to add that as well,
and then you just click the assessment thereafter.
Depending on the size of your schema,
this assessment might take a little longer,
but what I'm going to be doing,
I'm going to be taking you to
the existing assessment that I already did.
So I'm going to delete this assessment,
and then this is my existing assessment here,
I'm going to open that up.
As you see here, this is a specific database that I have.
So in the feature parity,
I got only one issue reported.
Though, we support agent jobs onto the managed instance.
At the same time, the specific job type which is partial,
we don't support that yet.
This feature is coming in later releases of the amide.
But for now, I want to flag that.
>> Does it give me a work around,
which it is probably let's say it can support?
>> It gives you a workaround.
First of all, you might want to investigate if
this Powershell script is still relevant for your apps.
I see a lot of customers especially with the legacy script,
those scripts are not in use.
But they're still sitting in your schema just
because they don't like that that is legacy applications.
This PowerShell script, you can
really convert into native SQL if it is possible
or use some other ways that you want to mitigate that,
or you can use the Azure native jobs in an elastic jobs,
that has much more extensive feature
set that will help you to convert these jobs.
Then if you look at the compatibility issues, for particularly,
I'm going to look at the HR database maybe inventory,
inventory database looks, let me click on that.
As you see here, there are no breaking changes for
inventory, it's pretty clear.
If I look at HR DB,
also it looks way pretty clear for you.
So the way that you look at these one is
that you look at
the breaking changes is one category
where you want to pay attention to it.
>> Because obviously, there's one
there, it's just not going to work.
>> Not going to work. The others,
once you fix them after the migration,
the next category that you are going to be looking at
the behavioral changes. I want to see if
>> Can you give me an example of a behavior change?
>> Yeah, I'm going to try to get that one like HR,
yeah, so here is the thing.
So I got some breaking changes here,
especially non-ANSI joins, the legacy joins.
These joints are not supported anymore with
the latest versions of the SQL
Server no matter where you are going,
whether you're upgrading to those in 16 and
above or you're migrating to the Cloud, these will break.
So we also give you a recommendation how to
fix that with the example,
where how the query can be converted into
the ANSI style join, which is being supported.
>> All this is very useful.
>> Yeah.
>> Wow.
>> So those are the highest priority that you want to do.
There is another category called behavioral changes,
they'll continue to work,
they're not going to break or anything.
But their behavior could be little different.
So in this case, the queries might perform little less optimized
is because of the some of the recent changes
that we made to the query optimizer. So it all depends.
>> So that's part of your phase if you want to migrate it,
you want to do some optimization after the fact?
>> Right. But breaking changes are
the ones that you would want to focus first, right?
>> Okay.
>> Couple of servers that I assess and then I was able to find
out some databases that I can migrate to,
some I might not,
maybe I should go to the VM stuff.
That analysis is pretty easy if you're
dealing with only a couple of instances.
But what if you have hundreds of
SQL Servers and you want to understand which of
these databases ready to go to MI
versus I need to stick with the VM, how do you know?
For that, we recently introduced a feature
called upload the results to the Azure migrate hub,
which provides say a unique summary view
of all these databases and
their relative readiness of those databases.
So you simply click on this,
and then it will give you an option to log on to the Azure portal,
where you create an Azure migrate project up front,
and then it will ask you to pick up
the specific subscription where that migration project is there,
and then you also pick up the resource group where you
want to upload these ones.
Once you do that, I know it's taking a little longer.
But you just pick the specific subscription ID here.
>> Quite a few there.
>> Yeah, quite a few. I'm asking my engineering
to give an ability to filter
out some of these subscriptions there.
So you just simply click "Upload. "
Once you upload, you can
see this kind of a view on the Azure Migrate.
These are all the SQL Server Instances that I got.
Each of the SQL Instances,
the relative readiness of those instance going
into the Platform as a Service.
Otherwise, it can easily go to
the SQL Servers which are running on the VMs.
>> I like the percentages, you have the 83.33333.
>> We are pretty accurate on that.
This is just coming out of the new build that we have.
>> But that's a great feature if you've got like you said,
migration system tool is really useful for like,
you said a handful of databases when you get to like hundreds.
>> Yeah. So you can see a single view here.
For example, if you want to investigate further
why this instance is only 83 percent ready,
then you can go to that instance and then it
will start all the DBs that are there.
As you look at here, most of
these DBs are ready to migrate to Platform as a Service,
so you see yes, yes, yes right here see,
ready for Azure SQL DB,
and there is only one database which is Archive DB,
which is not ready to go to migrate to manage instance,
but it is ready to go to the VM.
>> Got you.
>> So there are couple of migration blockers there.
If you really want to understand those migration blockers,
you can always go to the specific DMA assessment that you did.
For example, the Archive in this case.
There are a couple of migration blockers it is listing,
which is mainly the file stream feature that is being
in use which is not supported on the managed instance yet.
For that reason, we mark the database is
not ready to migrate to PaaS,
instead, they can migrate to VM.
So this kind of a view really helps you to find out
the low hanging fruits that you can migrate to PaaS
so that you can use them to migrate to PaaS.
>> That's a really great tool for the IT pros
that are managing larger databases.
>> It has some review where the CTO
and the decision-makers can look at it at a very high level.
But a DBA who really wants to do the migrations,
they can drill down to the specifics as well.
>> Perfect.
>> Maybe next time, I'll showcase
you the actual migration, how it works.
>> Let's do that next time.
Well, thank you Raj.
Thank you everyone. This was
an overview of the database migration system,
the free tool, right?
>> Yeah.
>> We'll see you next time.
>> Thank you so much for the time.
>> Thank you.
[MUSIC]