WEBVTT

00:00:00.000 --> 00:00:10.830
[MUSIC].

00:00:10.830 --> 00:00:12.060
>> Hi. I'm Anna Thomas,

00:00:12.060 --> 00:00:13.890
and I'm a Data
and Applied Scientist on

00:00:13.890 --> 00:00:15.705
the Azure Data Team working on

00:00:15.705 --> 00:00:18.090
SQL and I'm joined
today by my colleague.

00:00:18.090 --> 00:00:19.575
>> I'm Jeroen ter Heerdt,

00:00:19.575 --> 00:00:22.830
and I'm a Program Manager
in the Azure Data Team too.

00:00:22.830 --> 00:00:24.945
>> We're excited to
have you all today.

00:00:24.945 --> 00:00:26.790
Today, Jeroen is going to talk to

00:00:26.790 --> 00:00:28.740
us a little bit about Hyperscale.

00:00:28.740 --> 00:00:30.810
What are you going
to go through today?

00:00:30.810 --> 00:00:34.080
>> Well, Hyperscale is a new service

00:00:34.080 --> 00:00:37.845
here for Azure SQL that we
just introduced in May.

00:00:37.845 --> 00:00:41.185
Today, I'm going to
show how to migrate

00:00:41.185 --> 00:00:46.525
a database from Azure SQL like
regular Azure SQL to Hyperscale.

00:00:46.525 --> 00:00:49.310
>> Cool, awesome. So
what do you got there?

00:00:49.310 --> 00:00:52.160
>> So the way this works,

00:00:52.160 --> 00:00:53.480
I am in the Azure Portal here,

00:00:53.480 --> 00:00:55.040
let me zoom in a little bit.

00:00:55.040 --> 00:00:57.680
So I'm in the Azure Portal,

00:00:57.680 --> 00:01:00.365
I have a standard SQL database here.

00:01:00.365 --> 00:01:04.190
Very simple one, is general purpose
pricing tier, nothing special.

00:01:04.190 --> 00:01:07.820
I'll take this database and
migrate it to Hyperscale.

00:01:07.820 --> 00:01:09.320
So in order to do that,

00:01:09.320 --> 00:01:10.730
what I do is I click here,

00:01:10.730 --> 00:01:14.785
I go to "Configure",
and on "Configure",

00:01:14.785 --> 00:01:18.155
I can see that my database is
currently in general purpose

00:01:18.155 --> 00:01:20.075
and I can change that by

00:01:20.075 --> 00:01:22.710
going to Hyperscale
over here on the right,

00:01:22.710 --> 00:01:26.320
and then I can make
some configuration changes.

00:01:26.320 --> 00:01:27.460
I can choose, for example,

00:01:27.460 --> 00:01:29.410
the amount of vCores that
I want or the amount

00:01:29.410 --> 00:01:32.050
of read-only replicas that I need.

00:01:32.050 --> 00:01:36.270
So yeah, that's basically
the formula I get.

00:01:36.270 --> 00:01:40.140
>> Jeroen, what is that little
warning sign we're getting?

00:01:40.140 --> 00:01:41.835
>> Yeah, that's
a good one. Good catch.

00:01:41.835 --> 00:01:44.170
The warning sign is actually about

00:01:44.170 --> 00:01:47.710
notifying you that this is
a one-way street you're entering.

00:01:47.710 --> 00:01:49.180
So there's no way once you

00:01:49.180 --> 00:01:51.630
migrated your standard
database to Hyperscale,

00:01:51.630 --> 00:01:54.960
there's no way to go
back at this moment.

00:01:54.960 --> 00:01:57.210
So this is brand new,

00:01:57.210 --> 00:02:00.435
this might change in
the future, but for now,

00:02:00.435 --> 00:02:04.050
there's notices here
to tell you be warned,

00:02:04.050 --> 00:02:07.005
you can't go back after
you went to Hyperscale.

00:02:07.005 --> 00:02:09.390
>> So when I'm testing and stuff,

00:02:09.390 --> 00:02:11.100
should I use a copy?

00:02:11.100 --> 00:02:13.715
>> Yeah, I would definitely
just take a copy.

00:02:13.715 --> 00:02:16.865
It's very easy to take a copy
of any database in Azure.

00:02:16.865 --> 00:02:19.605
So once you have it, click copy

00:02:19.605 --> 00:02:23.025
and migrate to
Hyperscale on the copy.

00:02:23.025 --> 00:02:26.300
Then once you're happy
with how everything works,

00:02:26.300 --> 00:02:27.860
you can then change
the connection string in

00:02:27.860 --> 00:02:30.740
your application to point to
this new Hyperscale version.

00:02:30.740 --> 00:02:32.150
>> Awesome. Cool. Thanks.

00:02:32.150 --> 00:02:37.615
>> So what I'll do is I'll
click here on I understand

00:02:37.615 --> 00:02:41.690
to let the portal know that I read

00:02:41.690 --> 00:02:43.415
the notice and I understand what

00:02:43.415 --> 00:02:46.535
the issue is or what I'm
getting myself into.

00:02:46.535 --> 00:02:49.729
Then I'll have to choose
the compute generations,

00:02:49.729 --> 00:02:51.859
I'll always go with the latest Gen5,

00:02:51.859 --> 00:02:54.980
and I can change the vCores
to virtual cores,

00:02:54.980 --> 00:02:56.495
the amount of replicas that I want,

00:02:56.495 --> 00:02:58.145
and I'll click "Apply".

00:02:58.145 --> 00:03:00.590
Then what will happen
is that the database is

00:03:00.590 --> 00:03:03.205
now migrating to Hyperscale.

00:03:03.205 --> 00:03:04.125
>> That's it.

00:03:04.125 --> 00:03:05.940
>> That's it. So easy.

00:03:05.940 --> 00:03:09.780
>> Oh, wow. So what types
of use cases would I want

00:03:09.780 --> 00:03:11.160
to- why would I want to move to

00:03:11.160 --> 00:03:13.695
Hyperscale while we're
letting it switch over?

00:03:13.695 --> 00:03:17.440
>> Sure. Well, the biggest reason
is actually scale,

00:03:17.440 --> 00:03:19.310
so either scale in terms of

00:03:19.310 --> 00:03:23.095
storage or scale in terms
of query performance.

00:03:23.095 --> 00:03:25.620
So Azure SQL itself

00:03:25.620 --> 00:03:30.275
has approximately four
terabyte file size limit.

00:03:30.275 --> 00:03:33.865
If you have a database larger
than that, what do you do?

00:03:33.865 --> 00:03:36.275
Well, Hyperscale is your answer.

00:03:36.275 --> 00:03:38.390
So if you have let's
say, I don't know,

00:03:38.390 --> 00:03:41.810
40 terabyte database, or
40 terabyte data warehouse,

00:03:41.810 --> 00:03:44.590
or 40 terabyte whatever database,

00:03:44.590 --> 00:03:48.345
hyperscale can then host
that database for you.

00:03:48.345 --> 00:03:50.235
Then with the read-only replicas,

00:03:50.235 --> 00:03:53.465
you get even more query performance
over all of that mass of data.

00:03:53.465 --> 00:03:57.240
So those are the two main reasons
due to migrate to Hyperscale.

00:03:57.240 --> 00:03:59.420
>> Is there a certain
number of read-only

00:03:59.420 --> 00:04:02.360
replicas that I get with
Hyperscale or can I configure it?

00:04:02.360 --> 00:04:03.560
>> You can configure it, it's

00:04:03.560 --> 00:04:06.410
between zero to four,
so you can choose.

00:04:06.410 --> 00:04:08.260
I think by default it goes to one,

00:04:08.260 --> 00:04:10.650
but you can dial it back
to zero if you don't

00:04:10.650 --> 00:04:12.810
want any read-only replicas,

00:04:12.810 --> 00:04:14.970
you can change it later as well,

00:04:14.970 --> 00:04:16.800
you can up the vCores,

00:04:16.800 --> 00:04:19.220
you can change or lower
the number of replicas.

00:04:19.220 --> 00:04:22.090
So those two settings you
can change after deployment.

00:04:22.090 --> 00:04:27.000
>> Awesome. Cool. So hopefully,

00:04:27.000 --> 00:04:28.500
that was useful for you all.

00:04:28.500 --> 00:04:30.360
Thanks for joining us today,

00:04:30.360 --> 00:04:31.950
and if you're interested in

00:04:31.950 --> 00:04:34.170
Hyperscale feel free
to leave us a like,

00:04:34.170 --> 00:04:35.320
subscribe to our channel,

00:04:35.320 --> 00:04:38.090
even leave us a comment
on what you're most

00:04:38.090 --> 00:04:41.460
excited about Hyperscale and
tune in next time. Thank you.

00:04:41.460 --> 00:04:53.470
[MUSIC]

