WEBVTT

00:00:00.000 --> 00:00:09.686
[MUSIC]

00:00:13.045 --> 00:00:15.590
Everybody welcome to another
exciting episode of Data Exposed.

00:00:15.590 --> 00:00:16.470
I'm your host, Scott Klein.

00:00:16.470 --> 00:00:18.580
And with me today
are two awesome guests.

00:00:18.580 --> 00:00:20.200
So, I'm gonna have them
introduce themselves.

00:00:20.200 --> 00:00:21.210
So, why don't you go first?

00:00:21.210 --> 00:00:22.310
And then, we'll go to you.

00:00:22.310 --> 00:00:25.540
>> Okay, Hi,
my name is I'm a Program manager on

00:00:25.540 --> 00:00:29.540
the Database Experimentation Team
within the data group.

00:00:29.540 --> 00:00:30.210
>> Okay.

00:00:30.210 --> 00:00:31.520
>> My name Denay Kurtutlil,

00:00:31.520 --> 00:00:34.050
I am an Engineering Manager in
the Data Experimentation Team.

00:00:34.050 --> 00:00:35.410
>> Okay, great, so
thanks for coming.

00:00:35.410 --> 00:00:36.330
It's our pleasure to have you.

00:00:36.330 --> 00:00:37.900
>> Nice to meet you, Scott.

00:00:37.900 --> 00:00:40.470
>> So, we've heard a lot about,
I've had some people in here talking

00:00:40.470 --> 00:00:43.350
about the data migration assistants
and all these kind of things.

00:00:43.350 --> 00:00:46.140
But I've never heard of the
Database Experimentation Assistant.

00:00:46.140 --> 00:00:47.320
>> That's because it's new.

00:00:47.320 --> 00:00:49.500
>> Okay, good,
then tell us [LAUGH] about it.

00:00:49.500 --> 00:00:51.250
What is this?

00:00:51.250 --> 00:00:56.270
>> This is actually a very new tool
for helping customers migrate from

00:00:57.390 --> 00:01:00.870
a lower version of SQL Server
to a higher version.

00:01:00.870 --> 00:01:02.860
So, you might have heard of
data migration assist and

00:01:02.860 --> 00:01:04.910
other sister tools.

00:01:04.910 --> 00:01:08.560
This is kind of like
a supplement to that.

00:01:08.560 --> 00:01:11.160
So, have you heard of A/B testing?

00:01:11.160 --> 00:01:11.740
>> Yep.

00:01:11.740 --> 00:01:14.190
>> So this is A/B testing for
database systems.

00:01:14.190 --> 00:01:15.440
>> Okay.
>> So that's what it is.

00:01:15.440 --> 00:01:18.630
People have, as you can see
a majority of our SQL customers

00:01:18.630 --> 00:01:21.350
are on 2008 or below and
they want to go to 2016.

00:01:21.350 --> 00:01:25.060
And there today they're hesitant and
migrating due to the complexity and

00:01:25.060 --> 00:01:26.780
the risks that are involved in it.

00:01:26.780 --> 00:01:28.260
>> Okay.
>> So, with this tool will be

00:01:28.260 --> 00:01:32.400
able to get any, understanding any
break and changes that go with it or

00:01:32.400 --> 00:01:34.730
even any performance
implications that can come

00:01:34.730 --> 00:01:36.760
when they move to a newer version.

00:01:36.760 --> 00:01:39.720
And they can upgrade to the newer
version much more with much

00:01:39.720 --> 00:01:40.497
more confidence.

00:01:40.497 --> 00:01:44.940
>> Okay,
I'm gonna put you on the spot.

00:01:44.940 --> 00:01:48.630
But doesn't the migration assistant
also do an analysis of hey,

00:01:48.630 --> 00:01:50.220
breaking changes and
things like that?

00:01:50.220 --> 00:01:53.000
>> Migration assistant kind
of do it more like a role

00:01:53.000 --> 00:01:54.450
spaced engine kind of a thing.

00:01:54.450 --> 00:01:56.600
It doesn't really do
a workload comparison.

00:01:56.600 --> 00:01:59.430
Think about this as actually
trying to look at your workload

00:01:59.430 --> 00:02:00.990
in production and

00:02:00.990 --> 00:02:03.650
trying to see how does your workload
run against a newer version.

00:02:04.670 --> 00:02:08.040
Upgrade is one scenario for us, but
you can think about it as doing many

00:02:08.040 --> 00:02:11.530
different kinds of experiments,
like it can do a feature on and off.

00:02:11.530 --> 00:02:14.500
As a DBA you want to turn on
a feature and off a feature.

00:02:14.500 --> 00:02:17.090
So, it's kind of like
a generic AB testing solution

00:02:17.090 --> 00:02:19.920
Is one of the biggest scenario
right now that we are supporting.

00:02:19.920 --> 00:02:21.590
But same can be used for
other scenarios, too.

00:02:21.590 --> 00:02:25.508
>> To summarize, DMA actually
does static code analysis.

00:02:25.508 --> 00:02:30.530
But as mentioned, it does a lot
more in workload comparison

00:02:30.530 --> 00:02:32.240
using real workloads, too, right.

00:02:32.240 --> 00:02:32.850
>> Okay.

00:02:32.850 --> 00:02:34.960
>> So, that's one of those.

00:02:34.960 --> 00:02:36.320
Okay, cool.

00:02:36.320 --> 00:02:37.990
>> Yeah.
>> Is there a point in time,

00:02:37.990 --> 00:02:38.940
another loaded question,

00:02:38.940 --> 00:02:42.030
maybe a point in time where these
maybe become the same tool?

00:02:42.030 --> 00:02:43.440
>> There is.
>> Because if I'm an ISV and

00:02:44.620 --> 00:02:47.570
I'm like okay I've got to run this
tool and I've got to run that tool.

00:02:47.570 --> 00:02:50.620
>> Yeah, there is a lot we've
been thinking about it.

00:02:50.620 --> 00:02:52.440
There is potential for
this to merge.

00:02:52.440 --> 00:02:53.970
>> Okay.
>> In terms of scenario.

00:02:53.970 --> 00:02:55.959
But right now they're
just separate tools.

00:02:57.090 --> 00:02:59.240
But that kind of finishes
the intervent migration.

00:02:59.240 --> 00:02:59.760
>> Yeah, okay.

00:02:59.760 --> 00:03:03.900
And that makes sense because
as we flush out the,

00:03:03.900 --> 00:03:07.870
how do I say this, we flush out the
>> Complexities of each tool.

00:03:07.870 --> 00:03:09.930
>> The complexities of each tool,

00:03:09.930 --> 00:03:12.990
great we got it to a point
where they're baked, good.

00:03:12.990 --> 00:03:13.555
[CROSSTALK] Perfect.

00:03:13.555 --> 00:03:14.150
What's next.

00:03:14.150 --> 00:03:15.180
>> Makes total sense.

00:03:15.180 --> 00:03:19.490
So, let me walk you through the high
level experiment setup here,

00:03:19.490 --> 00:03:21.840
before we dive into the demo.

00:03:21.840 --> 00:03:25.210
So, let's say we have a scenario
where the customer is moving from

00:03:25.210 --> 00:03:25.790
SQL 2008 to 2016.

00:03:25.790 --> 00:03:29.810
So they have a production
environment of 2008,

00:03:29.810 --> 00:03:33.592
which is where we are capturing
all the SQL traces.

00:03:33.592 --> 00:03:34.370
>> Okay.

00:03:34.370 --> 00:03:35.210
>> And which we, and

00:03:35.210 --> 00:03:38.070
then they have a test environment
where they have two instances there.

00:03:38.070 --> 00:03:41.880
One that mimics the SQL
2008 environment.

00:03:41.880 --> 00:03:44.560
As well as on their second
instance would have the SQL 2016,

00:03:44.560 --> 00:03:47.020
which is the target.

00:03:47.020 --> 00:03:49.220
This is A and
B that we are talking about.

00:03:49.220 --> 00:03:53.670
So, we are using DA,
the database To the replay,

00:03:53.670 --> 00:03:57.900
whatever it captured in a to
these two test environments.

00:03:57.900 --> 00:03:58.820
>> Okay, perfect.

00:04:00.140 --> 00:04:03.960
>> Once you have done that, the DEA
processes and analyzes the traces

00:04:03.960 --> 00:04:06.380
that you get out of
>> The A and B,

00:04:06.380 --> 00:04:06.590
>> Okay.

00:04:06.590 --> 00:04:10.170
>> And then, it shows on
a nice UI report, that can

00:04:10.170 --> 00:04:13.200
contain the detailed performance and
errors, error related data.

00:04:13.200 --> 00:04:14.720
>> Let me make sure.
Can we back up real quick?

00:04:14.720 --> 00:04:16.770
And I apologize for
the stupid question.

00:04:16.770 --> 00:04:18.410
So, I've got an A and

00:04:18.410 --> 00:04:20.360
since it's equal to 2008,
>> Right.

00:04:20.360 --> 00:04:20.870
>> Correct.

00:04:20.870 --> 00:04:22.850
>> I'm gonna replay that
against another 2008 instance,

00:04:22.850 --> 00:04:23.140
>> Right.

00:04:23.140 --> 00:04:24.150
>> As well as a 2016 instance?

00:04:24.150 --> 00:04:24.650
>> But, yes.
>> Right.

00:04:24.650 --> 00:04:26.170
But there is a reason why.

00:04:26.170 --> 00:04:27.510
It's a good point actually.

00:04:27.510 --> 00:04:29.140
There's a reason why
we've done that.

00:04:29.140 --> 00:04:32.580
>> Typically in a production
environment, you know, DBAs and

00:04:32.580 --> 00:04:36.540
app owners don't like too much of
a performance overhead of a system.

00:04:36.540 --> 00:04:40.160
So, we want to make the performance
overhead by turning on a capturing

00:04:40.160 --> 00:04:41.345
on the production system minimum.

00:04:41.345 --> 00:04:42.050
>> Okay.
>> So

00:04:42.050 --> 00:04:44.740
what we do in the first step when we
capture the trace in the production

00:04:44.740 --> 00:04:47.670
system, we only capture
a subset of the trace events.

00:04:47.670 --> 00:04:49.650
That just gives me the workload,
that's all we need.

00:04:49.650 --> 00:04:53.190
And the rest of the stuff, we can do
in a non-production environment, but

00:04:53.190 --> 00:04:54.330
still you can do an AB testing,

00:04:54.330 --> 00:04:56.840
comparing apples to apples,
as long as the A primes and

00:04:56.840 --> 00:04:59.230
B are kind of similar hardware
configuration and things like that.

00:04:59.230 --> 00:04:59.780
>> Okay.
>> Yep.

00:04:59.780 --> 00:05:02.430
Excuse me,
comparison of where I'm at, right?

00:05:02.430 --> 00:05:03.970
>> Yeah.
>> On kind of a base level type

00:05:03.970 --> 00:05:04.540
of scenario.

00:05:04.540 --> 00:05:05.250
>> Exactly.
>> Yeah.

00:05:05.250 --> 00:05:05.820
>> Okay.
Cool.

00:05:05.820 --> 00:05:07.280
>> Glad you caught onto that though.

00:05:07.280 --> 00:05:09.970
>> Okay, yeah,
I looked at that and went, okay,

00:05:09.970 --> 00:05:11.687
why am I re-running this?

00:05:11.687 --> 00:05:13.990
Okay, cuz if I'm asking that,
somebody else is gonna ask that.

00:05:13.990 --> 00:05:15.040
>> Absolutely.
>> I'm gonna ask the,

00:05:15.040 --> 00:05:17.020
I shouldn't call
them dumb questions.

00:05:17.020 --> 00:05:19.388
I'm gonna ask the obvious questions,
cuz [CROSSTALK].

00:05:19.388 --> 00:05:22.285
>> This comes from customer a lot,
so it's about, we did 1.5% is

00:05:22.285 --> 00:05:25.648
the overhead on CPU when we do this
on the production which is kind of

00:05:25.648 --> 00:05:27.960
fairly small actually if
you think about it, yeah.

00:05:27.960 --> 00:05:28.910
>> Okay, but what's nice is that,

00:05:28.910 --> 00:05:30.860
hey when I'm done I get
this nice report that goes,

00:05:30.860 --> 00:05:34.470
hey, here's what
>> Right, that's gonna go?

00:05:34.470 --> 00:05:35.210
>> That's right.

00:05:35.210 --> 00:05:36.730
>> And with that,
we'll pick up the demo.

00:05:36.730 --> 00:05:39.170
>> This is the sort of like
when you enter the DEA,

00:05:39.170 --> 00:05:42.610
on the left side you
see three features.

00:05:42.610 --> 00:05:44.400
Capturing, replaying and analysis.

00:05:44.400 --> 00:05:47.250
All right, and just talked about
that in the architectural items.

00:05:47.250 --> 00:05:49.060
Essentially those
three features there.

00:05:49.060 --> 00:05:51.200
>> Yeah, so this is my initial
2008 instance that I'm gonna

00:05:51.200 --> 00:05:51.820
gather data from.

00:05:51.820 --> 00:05:53.130
>> Exactly.
>> Okay, so here,

00:05:53.130 --> 00:05:56.390
if you come into the capture you
can actually point to a SQL Server

00:05:56.390 --> 00:05:57.210
instance.

00:05:57.210 --> 00:05:59.150
This is my 2008 source here.

00:05:59.150 --> 00:06:02.240
And I can specify how long do I
really want to run this trace for

00:06:02.240 --> 00:06:04.090
and that's here in the duration.

00:06:04.090 --> 00:06:05.960
And then the max file size.

00:06:05.960 --> 00:06:08.480
That's typically the profile
size for a trace.

00:06:08.480 --> 00:06:09.620
I think recommended is 200.

00:06:09.620 --> 00:06:12.140
You can leave it as 200,
unless there's some special needs or

00:06:12.140 --> 00:06:14.470
something like that, and
a name for the trace.

00:06:14.470 --> 00:06:16.290
And when you start it,
what happens is it goes and

00:06:16.290 --> 00:06:18.960
fires a trace capture event
on the SQL Server 2008.

00:06:18.960 --> 00:06:20.060
>> Okay.

00:06:20.060 --> 00:06:22.620
>> So you see here, it's already
started the trace capture.

00:06:22.620 --> 00:06:25.800
You have a nice see how do
you measure progress and

00:06:25.800 --> 00:06:26.540
stuff like that.

00:06:26.540 --> 00:06:28.050
>> Okay.
>> So it's now doing the production

00:06:28.050 --> 00:06:28.820
workload capture.

00:06:28.820 --> 00:06:30.460
It's gonna run for 60 minutes and

00:06:30.460 --> 00:06:33.000
then you will have a trace
by the end of this.

00:06:33.000 --> 00:06:35.800
>> Okay, [LAUGH] so
I do have a question.

00:06:35.800 --> 00:06:38.660
So, is their ability to say hey, let
me just go to the, if I already have

00:06:38.660 --> 00:06:41.730
maybe a trace that I've already
done can I pull it up in here?

00:06:41.730 --> 00:06:43.040
>> Yeah,
you don't have to do the stuff then.

00:06:43.040 --> 00:06:44.400
You can go to the next
step if you have one.

00:06:44.400 --> 00:06:45.790
>> Okay, so
I can start step two and go, okay.

00:06:45.790 --> 00:06:46.480
>> Step two and go from there.

00:06:46.480 --> 00:06:48.040
>> I've already got a trace,
I've already captured.

00:06:48.040 --> 00:06:48.721
>> Yeah.
>> Okay.

00:06:48.721 --> 00:06:49.901
Yeah, you might typically want the

00:06:49.901 --> 00:06:52.811
same work load, but you replay it on
different kinds of configurations

00:06:52.811 --> 00:06:54.321
and stuff like that if you want to.
>> Okay, cool.

00:06:54.321 --> 00:06:55.401
>> That's why you always is always

00:06:55.401 --> 00:06:58.141
decoupled that way.
If people have captured trace

00:06:58.141 --> 00:07:00.380
already, they don't have to go
through the same thing again.

00:07:00.380 --> 00:07:03.650
They can come and replay or
or you know things like that.

00:07:03.650 --> 00:07:04.500
>> Very good, okay, cool.

00:07:04.500 --> 00:07:05.500
Very nice.

00:07:05.500 --> 00:07:09.260
So, going on to the part two and
we just stop the capture here,

00:07:09.260 --> 00:07:12.120
we've got one person complete,
that's good.

00:07:12.120 --> 00:07:15.460
Going on to the replay part, so
here, there are a couple of steps in

00:07:15.460 --> 00:07:19.960
replaying, basically the first step
is kind of verifying your replaying infrastructure,

00:07:19.960 --> 00:07:20.090
>> Okay

00:07:20.090 --> 00:07:21.720
>> And one key point here is that

00:07:21.720 --> 00:07:23.890
at this, with this release
we dont do the set up

00:07:23.890 --> 00:07:26.860
of the replay infrastructure,
we use distributed replay

00:07:26.860 --> 00:07:28.830
which is already available
part of the SQL installation.

00:07:28.830 --> 00:07:30.920
>> Yeah, the distributed replay
controller or something like that.

00:07:30.920 --> 00:07:31.630
>> Exactly.
Yeah.

00:07:31.630 --> 00:07:33.920
So we do like, verification
of the setup at this point.

00:07:33.920 --> 00:07:36.880
So, here I have given like,
one controller machines and

00:07:36.880 --> 00:07:37.820
four child machines, and

00:07:37.820 --> 00:07:40.390
they're already configured
that way in the setup, right.

00:07:40.390 --> 00:07:43.290
And when I go do next, what's it's
doing, it's kind of like verifying

00:07:43.290 --> 00:07:45.960
hey, is the setup really tight,
do I have access.

00:07:45.960 --> 00:07:46.840
All the child and

00:07:46.840 --> 00:07:50.810
controllers talking to each other,
and things working fine.

00:07:50.810 --> 00:07:52.880
>> All right, so
it said that hey things work fine.

00:07:52.880 --> 00:07:54.610
Now is the time when
it pick the trace.

00:07:54.610 --> 00:07:57.090
This is what we
captured in step one.

00:07:57.090 --> 00:07:58.480
>> Okay.
>> Remember the workload

00:07:58.480 --> 00:07:59.630
capture that we did.

00:07:59.630 --> 00:08:01.820
>> This is where I go
say I already got one.

00:08:01.820 --> 00:08:03.090
>> Exactly, that's correct.

00:08:03.090 --> 00:08:05.545
So, let me just pull
this up from here.

00:08:11.554 --> 00:08:14.481
I wish I had an automated way
to do this but I don't, so.

00:08:16.909 --> 00:08:21.120
>> So, here I give the trace
file that the capture and

00:08:21.120 --> 00:08:25.949
then I say, you store
the pre-processing output here.

00:08:25.949 --> 00:08:26.820
>> Okay.
>> So

00:08:26.820 --> 00:08:28.930
that's basically something to do
with the data play architecture,

00:08:28.930 --> 00:08:31.870
it converts the files into
an optimized file, right.

00:08:31.870 --> 00:08:35.480
And then, it actually goes and
figures out optimized way to

00:08:35.480 --> 00:08:39.000
convert these files from trace
file to a replay file, okay.

00:08:39.000 --> 00:08:40.680
>> And third step was
actually doing a replay.

00:08:40.680 --> 00:08:43.751
And you'll see on the UI there
is options to point a particular

00:08:43.751 --> 00:08:45.057
database and [CROSSTALK].

00:08:45.057 --> 00:08:46.967
>> This is where you go say, hey,

00:08:46.967 --> 00:08:48.850
run it against these-
>> Exactly.

00:08:48.850 --> 00:08:49.450
>> All right.

00:08:49.450 --> 00:08:53.020
>> Yeah, that's where you do the
replay onto the specified databases.

00:08:53.020 --> 00:08:55.950
So for this scenario, where you
are upgrading to 2008 or 16,

00:08:55.950 --> 00:08:58.740
you can do it once fo 2008 and
another time for 2016.

00:08:58.740 --> 00:09:02.021
>> If you remember the architecture
we had two of them.

00:09:02.021 --> 00:09:04.760
One on A and
the other one it's in the B.

00:09:04.760 --> 00:09:06.610
>> Can you do those in parallel, or

00:09:06.610 --> 00:09:09.390
does it run against the A and
then B?

00:09:09.390 --> 00:09:10.970
>> From the UI,
we'll be doing it one at a time.

00:09:10.970 --> 00:09:12.400
>> One at a time.
>> We have a command support

00:09:12.400 --> 00:09:14.770
where you can do it in parallel.

00:09:14.770 --> 00:09:16.990
>> You can kick off for
both instances.

00:09:16.990 --> 00:09:18.010
>> That's good.

00:09:18.010 --> 00:09:19.080
Cool.

00:09:19.080 --> 00:09:20.260
>> So, yeah,
we have the final screen.

00:09:20.260 --> 00:09:21.440
I'm not going too far into it.

00:09:21.440 --> 00:09:22.520
It's gonna take
a little bit of time.

00:09:22.520 --> 00:09:24.250
So, for the interest of time,

00:09:24.250 --> 00:09:26.690
now we can actually point
to the SQL instance.

00:09:26.690 --> 00:09:28.440
And then say, stop my replay.

00:09:28.440 --> 00:09:29.540
>> Okay.
>> And then you file the replay.

00:09:29.540 --> 00:09:30.610
And then you can view the progress,

00:09:30.610 --> 00:09:32.580
just like you saw the progress
in the first one.

00:09:32.580 --> 00:09:33.340
>> So this is where I'd go,

00:09:33.340 --> 00:09:36.360
say here's my 2008 instance
[INAUDIBLE] Exactly.

00:09:36.360 --> 00:09:39.100
>> And then, when it's done,
now I run it against my 2008,

00:09:39.100 --> 00:09:40.610
my 2016 instance.

00:09:40.610 --> 00:09:41.170
>> Exactly.

00:09:41.170 --> 00:09:42.080
>> Okay.
>> That is correct.

00:09:42.080 --> 00:09:43.700
All right, and
then when I'm done where do I see

00:09:43.700 --> 00:09:44.860
the output of the results?

00:09:44.860 --> 00:09:47.700
>> So now, you have two traces
captured from both that's replaced.

00:09:47.700 --> 00:09:50.190
>> Okay.
>> And go to the third step.

00:09:50.190 --> 00:09:52.310
We have a new analysis here.

00:09:52.310 --> 00:09:55.460
So this is where you provide if you
see here trace from source server

00:09:55.460 --> 00:09:57.560
and trace from target server.

00:09:57.560 --> 00:10:00.690
So this is where you provide
your 2008 and 2016 trace files.

00:10:00.690 --> 00:10:06.076
>> The two,
not the source one, the two.

00:10:06.076 --> 00:10:07.064
>> The A prime and the B.

00:10:07.064 --> 00:10:07.825
>> The B prime, okay.

00:10:07.825 --> 00:10:08.411
>> Right.

00:10:08.411 --> 00:10:08.971
>> Gotcha.

00:10:08.971 --> 00:10:12.258
>> Yeah, and then you provide that
and then you point to the SQL Server

00:10:12.258 --> 00:10:15.340
instance where you want to
put the analysis reports in.

00:10:15.340 --> 00:10:17.170
And you get the data, yeah.

00:10:17.170 --> 00:10:18.670
So, let me show you what we have.

00:10:18.670 --> 00:10:21.099
Like an example of some
tests that we've done.

00:10:31.008 --> 00:10:34.260
So, this is how you would
view existing reports.

00:10:34.260 --> 00:10:36.860
These are all the reports
that were generated before.

00:10:36.860 --> 00:10:39.067
Which is one of them
the next gonna show you,

00:10:39.067 --> 00:10:42.481
so this is the insights that you'll
get into workload comparison.

00:10:42.481 --> 00:10:45.026
>> Yeah, I'm gonna ask you
that right when you start

00:10:45.026 --> 00:10:45.851
>> I was going to say,

00:10:45.851 --> 00:10:47.920
can we save those reports,
that type of thing.

00:10:47.920 --> 00:10:48.623
>> Exactly.

00:10:48.623 --> 00:10:49.138
>> Okay.

00:10:49.138 --> 00:10:50.652
>> If you point to a DB instance,

00:10:50.652 --> 00:10:52.900
it will pull up all
the things you have done.

00:10:52.900 --> 00:10:55.800
>> So, if you notice all
the reports are created with

00:10:55.800 --> 00:10:58.800
the prefix analysis, and the name
that you have given in the previous

00:10:58.800 --> 00:10:59.960
screen that Nick was showing you.

00:10:59.960 --> 00:11:03.030
So, it will pull up everything
from that database.

00:11:03.030 --> 00:11:03.530
>> Okay.
Cool.

00:11:04.640 --> 00:11:08.390
The first thing you see here is
a representation of your workload.

00:11:08.390 --> 00:11:10.490
Now, there are two kind of
balls here, the blue balls and

00:11:10.490 --> 00:11:11.630
the green balls.

00:11:11.630 --> 00:11:16.160
Blue balls mean queries that we
have seen for the first time,

00:11:16.160 --> 00:11:19.250
while green balls mean queries
that we have previously seen and

00:11:19.250 --> 00:11:21.240
we've already evaluated that.

00:11:21.240 --> 00:11:23.590
So, it kind of shows how your
workload progresses, and

00:11:23.590 --> 00:11:25.670
this is kind of like
a test workload.

00:11:25.670 --> 00:11:27.040
So you see as time progresses,

00:11:27.040 --> 00:11:29.910
most of the queries
are already evaluated.

00:11:29.910 --> 00:11:34.380
So the goal is to give an insight to
hey, have you captured like a good

00:11:34.380 --> 00:11:37.980
amount of your workload, or
is your workload still going on?

00:11:37.980 --> 00:11:39.120
>> Yeah.
>> Do we need to capture for

00:11:39.120 --> 00:11:39.790
a little bit longer?

00:11:39.790 --> 00:11:42.370
So that's the kind of insight that
we wanna provide from this workload

00:11:42.370 --> 00:11:43.150
representation.

00:11:43.150 --> 00:11:44.870
>> Okay, so this is the hey,

00:11:44.870 --> 00:11:46.810
have I captured enough
>> Exactly.

00:11:46.810 --> 00:11:48.590
>> Information to be able
to make a good decision.

00:11:48.590 --> 00:11:50.470
>> Correct.
>> This will kind of help people

00:11:50.470 --> 00:11:52.530
like financial institutions for

00:11:52.530 --> 00:11:55.540
example like they have pick
hours at like 3AM to 5AM.

00:11:55.540 --> 00:11:56.140
>> Okay.

00:11:56.140 --> 00:11:56.980
>> Now that's or

00:11:56.980 --> 00:11:59.270
I'm just saying it out like I
don't know what their pick hours.

00:11:59.270 --> 00:11:59.950
>> Right.
>> But

00:11:59.950 --> 00:12:02.750
that's what they want to target in
order to get that real workload

00:12:02.750 --> 00:12:03.470
representation.

00:12:03.470 --> 00:12:05.250
>> Okay,
did we I think we cover that here.

00:12:05.250 --> 00:12:05.800
>> Yeah.
>> Is that?

00:12:05.800 --> 00:12:06.310
>> Correct.

00:12:06.310 --> 00:12:08.020
>> Okay.
>> So this insights will help them

00:12:09.800 --> 00:12:10.910
capture at the right time.

00:12:10.910 --> 00:12:11.980
>> Okay, perfect.

00:12:11.980 --> 00:12:12.950
>> Yeah.

00:12:12.950 --> 00:12:15.410
>> And then this is what we see.

00:12:15.410 --> 00:12:19.200
We provide a confidence of analysis
of what queries errored out,

00:12:19.200 --> 00:12:22.060
what queries degraded, what queries
improved and things like that when

00:12:22.060 --> 00:12:25.410
we do an experimentation between two
different versions of SQL Server.

00:12:25.410 --> 00:12:27.140
>> So, this block here,
the red block,

00:12:27.140 --> 00:12:30.000
actually shows the queries
that errored out.

00:12:30.000 --> 00:12:30.998
>> So let's get into that.

00:12:30.998 --> 00:12:35.750
>> Wait, can you I'm gonna
ask you another obvious or

00:12:35.750 --> 00:12:37.800
maybe not obvious question.

00:12:37.800 --> 00:12:38.360
>> Sure.
>> So,

00:12:38.360 --> 00:12:40.850
we ran the test against SQL 16.

00:12:40.850 --> 00:12:41.920
>> Right.

00:12:41.920 --> 00:12:44.290
>> So,
I've got query procedures that ran.

00:12:44.290 --> 00:12:47.910
So, the red says, there's queries
that came from [INAUDIBLE]

00:12:47.910 --> 00:12:49.860
2008 that have errored on 2016.

00:12:49.860 --> 00:12:51.781
>> Okay.
[CROSSTALK] There are two,

00:12:51.781 --> 00:12:53.635
three possibilities, right?

00:12:53.635 --> 00:12:57.160
One is queries that worked fine
in 2008, but errored out in 2016.

00:12:57.160 --> 00:12:57.900
>> Okay.

00:12:57.900 --> 00:13:00.660
>> And one is like,
things that worked fine on,

00:13:00.660 --> 00:13:03.840
well didn't work fine on 2008,
but started working fine on 2016.

00:13:03.840 --> 00:13:05.150
That's possible too.

00:13:05.150 --> 00:13:05.680
>> Yeah.

00:13:05.680 --> 00:13:07.490
>> So we kind of show all
the combinations here.

00:13:07.490 --> 00:13:08.600
>> Okay.

00:13:08.600 --> 00:13:10.470
So, for
example if you go in here, right?

00:13:10.470 --> 00:13:13.060
There are three things,
existing errors, new errors and

00:13:13.060 --> 00:13:13.990
resolved errors.

00:13:13.990 --> 00:13:15.750
>> Okay.
>> Existing errors is you know these

00:13:15.750 --> 00:13:19.290
errors we seen in 2008 and we're
kind of seeing it in 2016 as well.

00:13:19.290 --> 00:13:20.770
>> Okay.
>> New errors are like we

00:13:20.770 --> 00:13:23.054
didn't see this but
we're now seeing it in 2016.

00:13:23.054 --> 00:13:24.552
>> Some physical change.

00:13:24.552 --> 00:13:27.540
>> Some change and some keywords not
being supported and stuff like that.

00:13:27.540 --> 00:13:29.800
And resolve the errors,
the things we saw in 2008,

00:13:29.800 --> 00:13:31.480
erring out but got resolved in 2016.

00:13:31.480 --> 00:13:34.980
>> Okay.
>> So this is both, we do for

00:13:34.980 --> 00:13:38.340
example if you look at some of
the errors, compute keyboard, right.

00:13:38.340 --> 00:13:40.905
We stopped supporting compute
keyboard from awesome tells

00:13:40.905 --> 00:13:41.715
them 12 one words.

00:13:41.715 --> 00:13:45.765
>> So, at least DMA kind of tells
you here is the issue that we found, okay

00:13:45.765 --> 00:13:46.465
>> Yeah, exactly.

00:13:46.465 --> 00:13:49.115
So it kind of tells you from
a workload perspective.

00:13:49.115 --> 00:13:51.995
And you can drill down and see like
more details on the editors and

00:13:51.995 --> 00:13:53.905
things like that.

00:13:53.905 --> 00:13:58.525
I come back to the main page and

00:13:58.525 --> 00:14:01.550
going back to the legal queries,
I mean.

00:14:01.550 --> 00:14:03.082
So, in also DBA and

00:14:03.082 --> 00:14:05.980
App I'm trying to figure out what
is impact of running my workload.

00:14:05.980 --> 00:14:09.690
How much performance hit
am I cutting by doing this?

00:14:09.690 --> 00:14:11.900
So, this view kind of give you that.

00:14:11.900 --> 00:14:16.180
So we can see queries,
the mean durations of the AB and

00:14:16.180 --> 00:14:18.310
the duration difference and
the presentation difference.

00:14:18.310 --> 00:14:20.370
Let me pick something that's
a little bit significant.

00:14:22.180 --> 00:14:23.020
Maybe one of these.

00:14:25.620 --> 00:14:27.220
So, we build down
from the query here.

00:14:27.220 --> 00:14:30.140
One thing to notice is
the query is normalized.

00:14:30.140 --> 00:14:31.620
The parameters are taken off.

00:14:31.620 --> 00:14:34.540
That makes sure that we are sort of

00:14:34.540 --> 00:14:37.710
hashing the same query
without any parameters.

00:14:38.960 --> 00:14:42.050
And it tells you how many times
it got a secure A and B, the mean

00:14:42.050 --> 00:14:45.710
durations, the CPUs, the reads,
the writes, and things like that.

00:14:45.710 --> 00:14:49.430
It can also give you
a comparison of the query plans.

00:14:49.430 --> 00:14:52.300
Now, for this portion we
have compiled query plans.

00:14:52.300 --> 00:14:53.520
>> Okay.

00:14:53.520 --> 00:14:56.870
>> But if you look at the compiled
query plans you can still see there

00:14:56.870 --> 00:15:00.570
is a difference in terms of how
the compiled query plans are.

00:15:00.570 --> 00:15:07.140
So for example for A it's showing
an average duration of 47,847.

00:15:07.140 --> 00:15:08.545
And for B, it's showing much more.

00:15:08.545 --> 00:15:10.490
>> Right.
>> That's the compile credit plan,

00:15:10.490 --> 00:15:13.780
and the actual execution data
also say the same thing.

00:15:13.780 --> 00:15:16.790
If you look at it here,
you can see that the duration for

00:15:16.790 --> 00:15:19.620
B, the dotted lines,
blue lines in the top,

00:15:19.620 --> 00:15:23.345
is much higher than the non-dotted
blue line, the bold blue lines.

00:15:23.345 --> 00:15:24.560
>> Okay.
>> And you can see there's

00:15:24.560 --> 00:15:26.640
a difference in also CPU usage.

00:15:26.640 --> 00:15:28.440
The B's actually using
a little more CPUs.

00:15:28.440 --> 00:15:28.970
For this credit,

00:15:28.970 --> 00:15:31.550
you see a difference in performance
in terms of degradation.

00:15:31.550 --> 00:15:32.050
>> Okay.
>> Yeah.

00:15:32.050 --> 00:15:32.730
And this is,

00:15:32.730 --> 00:15:36.710
I guess, is the ammunition
to figure out why it

00:15:36.710 --> 00:15:37.870
degredated and say hey,
>> Yeah.

00:15:37.870 --> 00:15:38.995
>> That's correct, right.

00:15:38.995 --> 00:15:41.920
>> Cuz it's kind of interesting
cause you know we had a couple-

00:15:41.920 --> 00:15:44.430
Bob Ward on here he goes,
SQL16 is just faster.

00:15:44.430 --> 00:15:45.220
And we look at this and

00:15:45.220 --> 00:15:47.090
I'm like well,
>> Yeah.

00:15:47.090 --> 00:15:49.330
>> In some cases it's not,
>> Yeah, exactly.

00:15:49.330 --> 00:15:50.010
So what happened?

00:15:50.010 --> 00:15:52.000
>> They might have to go ahead and
tweak the query plan.

00:15:52.000 --> 00:15:52.860
Tweak the query plan, yeah.

00:15:52.860 --> 00:15:54.490
And then fix it before
they can upgrade.

00:15:54.490 --> 00:15:55.350
>> Right. Okay, >> Right.

00:15:55.350 --> 00:15:56.260
>> And that makes sense because,

00:15:56.260 --> 00:15:57.630
like you said there's
somethings that

00:15:58.640 --> 00:15:59.960
don't translate well-
>> Exactly.

00:15:59.960 --> 00:16:04.040
>> To 16 because of keyword
segregator and things like that.

00:16:04.040 --> 00:16:07.150
>> Right. Sure. >> Correct,
yeah and we're working on more data

00:16:07.150 --> 00:16:12.100
into it as we see more
data that can be helpful.

00:16:12.100 --> 00:16:14.330
>> Can this tool at some point,

00:16:14.330 --> 00:16:17.310
it doesn't support Azure SQL DB
does it at this point?

00:16:17.310 --> 00:16:18.650
Or is it just on premises.

00:16:18.650 --> 00:16:20.650
>> It doesn't support
Azure SQL DB right now.

00:16:20.650 --> 00:16:23.200
But it does support SQL on VMs.

00:16:23.200 --> 00:16:24.750
Though it could be the scenario.

00:16:24.750 --> 00:16:25.520
>> It's the same.

00:16:25.520 --> 00:16:27.860
>> Yeah SQL and SQL on VMs.

00:16:27.860 --> 00:16:29.150
>> Would there be plans?

00:16:29.150 --> 00:16:32.010
Because maybe if I'm thinking
about hey I do want to go.

00:16:33.380 --> 00:16:34.800
Because if I'm an ISV or

00:16:34.800 --> 00:16:37.150
something like that I'd
love to go to Azure SQL DB.

00:16:37.150 --> 00:16:38.950
but is my workload
going to translate, and

00:16:38.950 --> 00:16:42.290
maybe what service tier in Azure SQL
database do I need to pick to

00:16:42.290 --> 00:16:44.290
have this same workload performance?

00:16:44.290 --> 00:16:45.240
>> Yeah.
>> Is that kind of?

00:16:45.240 --> 00:16:46.620
>> Yes.
Those are things we have

00:16:46.620 --> 00:16:47.280
talked about and it's.

00:16:47.280 --> 00:16:47.780
>> Okay.
>> Exactly.

00:16:47.780 --> 00:16:48.510
>> I'm not asking for

00:16:48.510 --> 00:16:49.170
a road map.
>> Yeah.

00:16:49.170 --> 00:16:50.320
>> Or a date, or anything like that.

00:16:50.320 --> 00:16:52.350
>> Right. No. >>
>> It's been on our minds, and

00:16:52.350 --> 00:16:53.190
we've been talking about it.

00:16:53.190 --> 00:16:54.430
>> And
it's a really valid scenario, too.

00:16:54.430 --> 00:16:56.060
>> Yeah, it's a valid scenario.

00:16:56.060 --> 00:16:58.110
>> Yeah.
It's a push toward pass and sass,

00:16:58.110 --> 00:16:58.830
things like that.

00:16:58.830 --> 00:16:59.330
>> Exactly.

00:16:59.330 --> 00:17:00.870
>> We could see that kinda going.

00:17:00.870 --> 00:17:01.900
>> Exactly. Totally.

00:17:01.900 --> 00:17:02.630
>> Okay, cool.

00:17:02.630 --> 00:17:03.960
This is awesome.

00:17:03.960 --> 00:17:05.630
I love the from a perspective.

00:17:05.630 --> 00:17:08.970
And I think my initial question was,
Both the DMA.

00:17:10.180 --> 00:17:11.370
There's a-
>> DA.

00:17:11.370 --> 00:17:11.910
>> DA.

00:17:11.910 --> 00:17:15.305
It does not stand for
a government agency.

00:17:15.305 --> 00:17:17.720
[LAUGH] It does not stand for that.

00:17:17.720 --> 00:17:20.240
But I can see these tools
kind of coming together,

00:17:20.240 --> 00:17:22.130
cuz they both compliment
each other very well.

00:17:22.130 --> 00:17:22.920
>> Absolutely.

00:17:22.920 --> 00:17:23.650
>> Yes.
>> Right?

00:17:23.650 --> 00:17:25.800
But I think what the DMA
does not have is,

00:17:25.800 --> 00:17:28.690
when you look at it from a From
my work load perspective.

00:17:28.690 --> 00:17:29.620
>> Correct.

00:17:29.620 --> 00:17:32.840
>> So, what are the things
I need to fix for my query?

00:17:32.840 --> 00:17:36.990
And can my tap in, now that I'm
talking about it, can is there a way

00:17:36.990 --> 00:17:40.880
to tap in to the query store in 16
and go maybe utilize some of that?

00:17:40.880 --> 00:17:43.560
I don't know, it's kinda
thinking out loud a little bit.

00:17:43.560 --> 00:17:44.440
>> Yeah.
I think definitely.

00:17:44.440 --> 00:17:46.220
I think those are the things
we're looking into.

00:17:46.220 --> 00:17:47.030
>> Okay.

00:17:47.030 --> 00:17:48.980
>> Yeah,
we're having discussions about that. Cool.

00:17:48.980 --> 00:17:50.760
>> So this is just a rerun of it.

00:17:50.760 --> 00:17:51.420
>> Okay.
>> I think I

00:17:51.420 --> 00:17:54.710
was telling you earlier,
we went out live last week.

00:17:54.710 --> 00:17:55.210
>> Okay.

00:17:55.210 --> 00:17:59.510
>> We announced the technical
preview at the past week.

00:17:59.510 --> 00:18:00.100
>> Okay.
>> So

00:18:00.100 --> 00:18:02.050
it's available to the public view,
and

00:18:02.050 --> 00:18:04.030
it's downloadable from
the download center.

00:18:04.030 --> 00:18:05.850
>> Okay.
>> So people can take a look at it,

00:18:05.850 --> 00:18:06.630
use it.

00:18:06.630 --> 00:18:08.320
Give us any feedback.

00:18:08.320 --> 00:18:08.910
All that stuff.
>> So

00:18:08.910 --> 00:18:11.410
in the description of the show
we'll put the link to the download.

00:18:11.410 --> 00:18:12.710
>> Great.
>> Absolutely.

00:18:12.710 --> 00:18:14.825
>> And what's the best way for
them to provide feedback?

00:18:14.825 --> 00:18:17.905
>> [INAUDIBLE]
>> There is a DA feedback at

00:18:17.905 --> 00:18:19.630
Microsoft.com, there
is an alias there.

00:18:19.630 --> 00:18:20.530
>> Okay.

00:18:20.530 --> 00:18:24.390
>> We'll also have a
>> Link from the tool that we need

00:18:24.390 --> 00:18:26.240
to add on-
>> Okay, so

00:18:26.240 --> 00:18:27.110
put all that information-
>> And

00:18:27.110 --> 00:18:31.070
we've already started seeing a lot
of downloads since last week.

00:18:31.070 --> 00:18:33.000
And also we had a few feedback.

00:18:33.000 --> 00:18:33.970
>> Yeah, absolutely.

00:18:33.970 --> 00:18:36.270
>> So people have been
playing around it for-

00:18:36.270 --> 00:18:37.610
>> Well, you're in SQL pass, right.

00:18:37.610 --> 00:18:39.110
So, all of this people
are going to say, new tool!

00:18:39.110 --> 00:18:39.890
Let me download it.

00:18:39.890 --> 00:18:41.320
>> Yeah.
>> Exactly.

00:18:41.320 --> 00:18:43.160
Awesome, this is fantastic,
thanks for coming.

00:18:43.160 --> 00:18:44.050
>> Thank you.

00:18:44.050 --> 00:18:48.020
>> We appreciate your time, we'd
love to have you back kinda around

00:18:48.020 --> 00:18:52.600
GA when there's new features that
come out because I think is you take

00:18:52.600 --> 00:18:57.790
some of this feedback and improve
the tool cuz it's already awesome,

00:18:57.790 --> 00:19:01.030
that we'd love to
>> Kind of what's new in this tool.

00:19:01.030 --> 00:19:01.908
>> Sounds good.
>> Cool.

00:19:01.908 --> 00:19:03.404
>> Hey everybody,
thanks for watching and

00:19:03.404 --> 00:19:04.372
we'll see you next time.

00:19:04.372 --> 00:19:14.372
[MUSIC]