>> Welcome back. We're going to talk about
deploying and verifying Azure SQL.
Now, as we've alluded to with
pre-deployment planning and all the different options,
when you actually go and deploy
your Azure SQL Database or Azure SQL Managed Instance,
there's going to be an order at
which you make the various decisions.
Now, for this example,
we're going to walk through
the different blades that you'll actually
see if you pick to deploy using the Azure portal.
Now, the first blade you're going to see is the basics blade.
This is going to ask for things like
your subscription, your resource group,
and depending on if you're deploying
a Managed Instance or an Azure SQL Database,
you're going to have to specify the name of the server.
This is the first time we're mentioning this idea of
a server for Azure SQL Database.
This server is really more of
a logical server or a database server.
The reason we have this is so you can
have something to connect to for starters,
and also it's going to
allow you to group certain databases together
and allow for policies over
all of those databases in the logical server.
We'll try our best to demystify what
this logical server actually is and the different
capabilities that come along with it throughout the series.
Once you pick some of your basics,
including the number of vCores and your size,
and if you're using
Azure SQL Database if you want to opt-in for pools,
you're going to go ahead and select your network connectivity.
Now we're going to dive much deeper into
this in the security module.
But basically you have to decide what
access do you want people to have out the door,
and are there any VNet or firewall rules
that you need to set up initially.
For example, for Azure SQL Managed Instance,
during deployment or before deployment,
you can actually configure
the exact virtual network and
subnet that your Managed Instance will go into.
After that, you are going to have some options for
some different settings depending
on which deployment option you choose.
You'll see there are some lets say DB and some lets say MI.
Some of these things like data source for Azure SQL Database,
you can actually choose to leverage a different database backup,
or the AdventureWorks sample during deployment.
You can also select a few different options.
For example, if you're deploying Azure SQL Managed Instance,
you have a choice of
the server coalition as well as the time zone.
For Azure SQL Database,
you can opt-in for Advanced Data Security.
Advanced Data Security is available
for Azure SQL Managed Instance,
just not as part of the deployment workflow.
Finally, you can add something called tags.
Tags are going to allow you to group resources in Azure together.
For example, I might have an environment tag,
and for the value for that tag,
I might have development or production,
and that can help me keep my workloads separate.
Finally, you're going to have to accept the terms and privacy,
and we encourage you to go read those,
it's very similar to a SQL Server EULA,
except there are also
some key differences related to the Azure marketplace.
Now, after you deploy,
you might be wondering,
what are some of the key implementation details
or what we're doing behind the scenes are.
>> We wanted you to know as you go through the deployment process,
how are we deploying things on the Azure infrastructure?
First of all, you should know that everything we do uses
the Azure Service Fabric as
every service in Azure does, including virtual machines.
If you take a look at Azure SQL Managed Instance,
one of the reasons why the deployment process can
be a little bit longer is we're giving you something
called a dedicated ring or virtual
cluster as you deploy this Instance.
That's so a scale operation or deployment can actually
take a little longer than doing something like a database.
Now, for most cases, each Instance is
its own single virtual machine within this cluster,
and there could be,
depending on the choices you make and how we implement things,
there could be multiple virtual machines per
a given node as we deploy this Instance.
Now, we mentioned before, in the first module,
something called Instance Pools,
and that's where we get things a little bit different,
where we can pack in more than one Instance side of VM,
which gives us those lower vCore choices,
and that's why deployment and pools can be a faster operation.
Now you look at Azure SQL Database.
As Anna mentioned, we have something called a
logical Database Server and a Logical Master even.
Don't think of this as an actual physical SQL Server,
although we really do use
a SQL Server Instance behind the scenes to deploy your database.
In fact, aside them
some smaller choices in a sub-core model say the DTU model,
we deploy a dedicated SQL Instance behind the scenes,
for your Azure SQL Database to keep you isolated and performant,
and more surface area and
instance level diagnostics now light up because we do that.
Even though Azure SQL Database is not
an instance for you to access,
you will use a logical server to make a connection and
some metadata associated with your databases as part of that.
There still is a SQL Instance powering this,
which again gives you things like xEvent and
certain DMVs that you would not normally have.
But if you think about hyperscale,
it's a very interesting implementation we've done,
and will show that a little bit more to you as you
see our availability module,
and even we talk about things like performance.
Thing you need to know about really important is,
today at least when you move to hyperscale, you deploy it.
You cannot change that deployment model,
that's different than all the other different models
we offer in Azure SQL Database.
If you got to go hyperscale, its important you decide ahead of
time that is indeed the model you want to move to,
and the caches you provide early architecture are really
the key to our speed and scalability story.
These caches are actual local disk drives
that serve as a so-called cache.
Because we're in your remote storage for the databases,
we get really amazing functionality from
snapshot backups and restores at lightning speeds.
Some people would ask me, "As you're going to
the process of implementing Azure SQL in the Service Fabric,
how do you provide these limits?"
Well, first of all, you've seen and may have heard of
our feature called Resource Governor in SQL Server,
which that's going to be exposed to you in
Managed Instance to use on your own.
But in Azure SQL Database, for example,
we're going to use Resource Governor behind the scenes to provide
some limitations based on the deployment choices you made.
We're also going to use something called Windows Job Objects.
Windows Job Objects are not a scheduling thing.
Its a property within the Windows operating system where you
can put certain limits on processes.
We'll talk about and show you some examples of how
Windows Job Objects apply
those different resource limits to your deployment choices.
We're going to use other things, we're going to use
File Server Resource Management.
We're going to be able to, within the engine,
control Transaction Log Rates to Transaction Log Governance.
We're going to take advantage of Azure Storage,
which allows you to do limits.
Then finally, some of this information from
a perspective of a Job Object is actually exposed at a DMV.
On the SQL team, we just love exposing
all sorts of details to our customers,
and even in the case of Azure,
we will give you some exposure to those type details.
As Anna and I were talking about this series together,
she asked me this question.
She goes, "When you verify deployment in SQL Server,
what do you do about it, how do you know
it actually got installed?"
What I thought would be interesting to show you is how I
personally would actually verify deployment I've done in Azure.
There's a couple of steps we should take a look at.
First of all, for Managed Instance,
the one thing I would do is I would check the portal or the CLI.
Remember, if you install SQL Server,
you're going to use the SQL Setup program to look at setup logs.
Well, with Azure in the ecosystem,
I'm going to be able to look at
the status of my deployment in the portal,
it's going to show me as a deployment,
that's why we call that deploy.
A deployment status is going to be shown to you,
or the CLI can show that.
We have things called activity logs,
which are part of that Azure ecosystem I talked about,
that can give you details about how this deployment worked.
Now, Managed Instance like a SQL Server,
I don't about you, but I was looking at my ERRORLOG.
What's inside the ERRORLOG to see when this finally
finished to see if it installed or deployed successfully.
Now I might go connect with SSMS,
or run some verify deployment queries,
which I'll show you in a second.
What about for Azure SQL Database,
what do I do differently between that and a Managed Instance?
Well, guess what, it's exactly the same,
except we don't expose
the underlying ERRORLOGS of
the Instance to you in Azure SQL Database.
So you're going to use the same
process that you're going to use with
Managed Instance though to do these verify deployment steps.
Now, what about connecting with SSMS?
You've deployed Azure SQL,
you're ready to go, how do I do it?
We're going to show you some examples.
But you know how simple it can be?
You get your connection with a network to
the Internet through Azure Virtual Machine,
or you're doing it from your own on-premises.
You're going to get the name of a server to connect to,
whether it's your Azure SQL Database logical server,
or it's going to be your Managed Instance.
You're going to use the credentials
you supplied during deployment,
and you're going to be able to connect to that
Azure SQL Database or Managed Instance.
What I easily do with SQL Servers,
I run a few query examples.
These are the queries I run just to check my deployment.
Whether it's looking at the version of the deployment,
looking at the different databases like the system databases,
looking at various objects to make sure
these catalog views are working properly.
There's a series of DMVs I often use to look at
schedulers or the properties of the operating system,
or even just show me the background task are running,
I want to make sure lazy writer is running on my server.
This is going to look very similar to you as
a SQL Server deployment with a few differences.
You're going to be able to use server property to look
at the specific engine addition,
which is going to show you,
is it a database or is Managed Instance versus a SQL Server.
Then finally, we're going to start showing you in this series
how we have some diagnostics that are specific to Azure,
and here's a couple of examples of some DMVs
that we would use that are very specific to the Azure deployment,
and we'll show some examples of what that actually looks like.
Just to summarize what we showed you,
Anna showed you the deployment experience
as you were in the portal,
the different choices you make,
just like you were installing SQL Server.
Then we talked about some of
the implementation details behind the scenes,
so you can have an idea of how we deploy things within
the Azure Service Fabric and
the different virtual machine details
and how we limit certain resources.
Finally, we gave you
our perspective of how we would verify deployment,
whether that's using activity logs,
or things with the Azure infrastructure
are just running some queries from
SSMS to see what this Azure SQL deployment looks like.
Looking forward to talking to you in the next video.