WEBVTT

00:00:00.000 --> 00:00:10.500
[MÚSICA].

00:00:10.500 --> 00:00:12.270
>> Oi meu nome é Pam,

00:00:12.270 --> 00:00:15.495
e eu sou um gerente de programa com
a equipe de engenharia de servidores da SQL.

00:00:15.495 --> 00:00:17.790
Hoje eu gostaria de fazer
uma demonstração rápida para você

00:00:17.790 --> 00:00:19.800
em um dos novos
recursos do Servidor SQL.

00:00:19.800 --> 00:00:23.310
Memória otimizada para 2019
Metadados tempdb.

00:00:23.310 --> 00:00:26.070
Eu já fiz um
Vídeo de visão geral em

00:00:26.070 --> 00:00:27.480
esta característica onde
Eu falo um pouco.

00:00:27.480 --> 00:00:29.040
sobre alguns dos desafios com

00:00:29.040 --> 00:00:32.295
TempDB desempenho que você
pode ter enfrentado no passado e

00:00:32.295 --> 00:00:35.850
sobre o trabalho que estamos fazendo em 2019
para melhorar o desempenho do TempDB.

00:00:35.850 --> 00:00:38.945
Então eu encorajo você a assistir a isso
vídeo se você ainda não viu.

00:00:38.945 --> 00:00:41.600
O que vamos fazer
nesta demonstração hoje é

00:00:41.600 --> 00:00:45.185
concentrando-se na memória otimizada
Recurso de metadados do TempDB,

00:00:45.185 --> 00:00:46.805
como você o habilita,

00:00:46.805 --> 00:00:47.975
como você iria desabilivá-lo.

00:00:47.975 --> 00:00:49.640
Mas também, como você pode

00:00:49.640 --> 00:00:51.790
dizer se você precisa
ligue esse recurso.

00:00:51.790 --> 00:00:55.600
Você está tendo o problema que
este recurso foi concebido para resolver?

00:00:55.600 --> 00:00:58.770
Então, vamos saltar para o
demo e dê uma olhada.

00:01:00.220 --> 00:01:02.960
Então, eu tenho um caderno aberto aqui em

00:01:02.960 --> 00:01:05.420
Estúdio de Dados Do Azure
com alguns comandos.

00:01:05.420 --> 00:01:09.050
O que vamos começar é correr
a carga de trabalho no Servidor SQL.

00:01:09.050 --> 00:01:14.315
2019 sem habilitar a Memória
Recurso de metadados temporários otimizados

00:01:14.315 --> 00:01:15.560
e vamos tentar dar uma olhada

00:01:15.560 --> 00:01:17.930
esta afirmação de que
pode acontecer em TempDB.

00:01:17.930 --> 00:01:21.050
Então, a primeira coisa que eu sou
vai fazer é começar

00:01:21.050 --> 00:01:24.170
um monitor de desempenho
coleção e coleta

00:01:24.170 --> 00:01:26.120
alguns diferentes
contadores que darão

00:01:26.120 --> 00:01:28.430
nós uma idéia do
desempenho da carga de trabalho.

00:01:28.430 --> 00:01:31.955
Então eu vou usar
a ferramenta de estresse O

00:01:31.955 --> 00:01:34.415
para executar uma carga de trabalho multithreaded.

00:01:34.415 --> 00:01:37.700
Então, eu tenho oito processadores
nesta máquina em particular,

00:01:37.700 --> 00:01:39.950
mas eu estou jogando 100
tópicos simultâneos.

00:01:39.950 --> 00:01:42.350
Então, eu tenho uma carga de trabalho muito ocupado

00:01:42.350 --> 00:01:44.810
aqui e é muito
pesada carga de trabalho tempdb.

00:01:44.810 --> 00:01:47.210
É um procedimento básico armazenado
que cria uma tabela de temperatura,

00:01:47.210 --> 00:01:48.360
colocar alguns dados para ele,

00:01:48.360 --> 00:01:49.805
e, em seguida, seleciona a partir dele.

00:01:49.805 --> 00:01:52.200
Então você pode ver aqui no homem Perf.

00:01:52.200 --> 00:01:54.090
Eu tenho alguns pesos em andamento,

00:01:54.090 --> 00:01:55.740
página trava pesos em andamento.

00:01:55.740 --> 00:01:58.895
Eu também tenho o tempo médio de espera

00:01:58.895 --> 00:02:00.380
listado aqui em Perf homem também.

00:02:00.380 --> 00:02:02.390
Então você pode ver que eu tenho
pesos de trava ponésios

00:02:02.390 --> 00:02:04.775
acontecendo enquanto eu estou
executando esta carga de trabalho.

00:02:04.775 --> 00:02:07.640
Isso não é incomum com um
carga de trabalho fortemente simultânea.

00:02:07.640 --> 00:02:11.580
A questão aqui é o que é
estes pesos de trava de página?

00:02:11.580 --> 00:02:12.770
Não sabemos necessariamente.

00:02:12.770 --> 00:02:14.405
Eles poderiam ser de
seu banco de dados de usuários.

00:02:14.405 --> 00:02:16.430
Eles podem ser de TempDB.

00:02:16.430 --> 00:02:18.740
Nós realmente não sabemos apenas
por olhar para o desempenho

00:02:18.740 --> 00:02:21.620
monitorar onde essas travas de página
os pesos estão vindo.

00:02:21.620 --> 00:02:23.210
Então, queremos voltar para

00:02:23.210 --> 00:02:25.850
Estúdio de Dados do Azure e dê uma olhada

00:02:25.850 --> 00:02:27.110
um script que pode nos ajudar

00:02:27.110 --> 00:02:30.880
determinar onde essas páginas
os pesos da trava estão vindo de.

00:02:30.880 --> 00:02:32.230
Parece que minha carga de trabalho acabou.

00:02:32.230 --> 00:02:34.190
Então, eu só vou chutá-lo
recuar novamente para que nós

00:02:34.190 --> 00:02:36.925
pode olhar para o Estúdio de Dados Do Azure.

00:02:36.925 --> 00:02:40.090
Então, vamos voltar aqui.

00:02:42.130 --> 00:02:47.135
Vou fazer essa consulta.
que eu tenho em foco.

00:02:47.135 --> 00:02:51.740
O que esta consulta está fazendo é
olhando para todos os pedidos de

00:02:51.740 --> 00:02:56.510
DM pedido exato que têm
um tipo de peso como página,

00:02:56.510 --> 00:03:00.335
significando algum tipo de
página trava peso.

00:03:00.335 --> 00:03:04.010
O que eu posso ver nos resultados
aqui é que eu realmente tenho

00:03:04.010 --> 00:03:07.295
várias sessões que são
esperando na trava da página.

00:03:07.295 --> 00:03:09.305
Se eu olhar para o recurso de peso,

00:03:09.305 --> 00:03:11.990
Eu posso dizer apenas a partir do peso
recursos em que estão

00:03:11.990 --> 00:03:15.905
TempDB porque o peso
recurso aqui é 2:1:1:20.

00:03:15.905 --> 00:03:17.420
Dois é identificação de banco de dados,

00:03:17.420 --> 00:03:18.665
dois que é TempDB.

00:03:18.665 --> 00:03:23.570
Um é o arquivo número 1 e
então 120 é o número da página.

00:03:23.570 --> 00:03:25.325
Então eu posso dizer que está em TempDB.

00:03:25.325 --> 00:03:30.395
Mas se eu usar essa nova função
chamado dmdb página de informações,

00:03:30.395 --> 00:03:34.039
o que isso me permite fazer
é tomar esse recurso da página

00:03:34.039 --> 00:03:38.330
e quebrá-lo aberto e ver
o que exatamente está nessa página.

00:03:38.330 --> 00:03:41.355
Então, a partir dessa função de informação página DMDB,

00:03:41.355 --> 00:03:44.150
Eu entendo esse objeto
nome e você pode ver

00:03:44.150 --> 00:03:46.810
aqui que o nome do objeto
são objetos de esquema,

00:03:46.810 --> 00:03:48.095
que é uma tabela do sistema.

00:03:48.095 --> 00:03:50.944
Então, este é o TempDB
metadados

00:03:50.944 --> 00:03:52.685
que estávamos falando.

00:03:52.685 --> 00:03:54.754
Este é o problema

00:03:54.754 --> 00:03:58.220
que a memória otimizado TempDB
metadados foram introduzidos para resolver.

00:03:58.220 --> 00:03:59.960
Então, vamos voltar para
nossa janela de comando.

00:03:59.960 --> 00:04:01.115
Podemos ver que acabou.

00:04:01.115 --> 00:04:02.450
Ambas as vezes ele executou,

00:04:02.450 --> 00:04:06.005
demorou cerca de 52 segundos
para executar a carga de trabalho.

00:04:06.005 --> 00:04:09.675
Podemos, naturalmente, ver a página
pesos de trava acontecendo.

00:04:09.675 --> 00:04:12.300
Podemos ver o lote
pedidos por segundo,

00:04:12.300 --> 00:04:14.100
que estão chegando,

00:04:14.100 --> 00:04:18.225
vamos ver aqui, cerca de 350 no máximo.

00:04:18.225 --> 00:04:20.210
Então, isso é sem o
recurso ligado.

00:04:20.210 --> 00:04:22.265
Então, vamos em frente e
ligue o recurso.

00:04:22.265 --> 00:04:23.795
Para fazer isso,

00:04:23.795 --> 00:04:25.925
precisamos permitir que o recurso

00:04:25.925 --> 00:04:29.090
Servidor SQL e também precisamos
para reiniciar o servidor.

00:04:29.090 --> 00:04:34.250
Esta configuração do servidor alterar
comando aqui requer um reinício.

00:04:34.250 --> 00:04:38.875
Então vamos definir essa memória
Metadados temporários otimizados.

00:04:38.875 --> 00:04:43.540
Então eu vou em frente e
reiniciar o servidor.

00:04:44.360 --> 00:04:48.025
Então, uma vez que eu faço isso,

00:04:48.025 --> 00:04:50.810
Eu vou ser capaz de voltar

00:04:50.810 --> 00:04:54.155
para o Azure Data Studio e
executar outro comando,

00:04:54.155 --> 00:04:57.470
selecionar a propriedade do servidor
comando para ver se

00:04:57.470 --> 00:05:01.160
o TempDB otimizado para a memória
recurso de metadados está em.

00:05:01.160 --> 00:05:03.265
Então, vamos executar este comando.

00:05:03.265 --> 00:05:07.245
Você pode vê-lo executado
e o recurso está agora em.

00:05:07.245 --> 00:05:10.565
É um deles. Então, vamos em frente.
e executar a nossa carga de trabalho novamente.

00:05:10.565 --> 00:05:13.470
Vamos começar o homem Perf.

00:05:16.490 --> 00:05:19.350
Vamos começar a nossa carga de trabalho novamente.

00:05:19.350 --> 00:05:20.775
As mesmas cargas de trabalho exatas.

00:05:20.775 --> 00:05:24.130
Mesmo procedimento armazenado, 100 fios.

00:05:24.130 --> 00:05:27.080
Você pode notar algo
diferente em Perf homem imediatamente.

00:05:27.080 --> 00:05:29.900
Em primeiro lugar, as solicitações de lote
por segundo é muito maior.

00:05:29.900 --> 00:05:34.520
Vamos até mais de 500.

00:05:34.520 --> 00:05:36.320
Pode até ir um pouco mais alto.

00:05:36.320 --> 00:05:37.580
Vou deixar isso correr por um tempo,

00:05:37.580 --> 00:05:40.790
mas também observe essas páginas
os pesos da trava desapareceram.

00:05:40.790 --> 00:05:42.605
Chega de pesos de trava de página.

00:05:42.605 --> 00:05:45.740
Se voltarmos aos Dados Do Azure
Studio e eu comandamos esse comando.

00:05:45.740 --> 00:05:48.990
novamente para olhar para as sessões.

00:05:48.990 --> 00:05:52.310
Observe que não há sessões
que estão esperando na trava da página.

00:05:52.310 --> 00:05:55.865
Nós eliminamos completamente
a página trava pesos.

00:05:55.865 --> 00:05:57.590
Se eu voltar para o homem perf,

00:05:57.590 --> 00:06:00.005
Yep, minha carga de trabalho já está terminada.

00:06:00.005 --> 00:06:02.990
Para que você possa ver que eu tenho
melhoria da entrada.

00:06:02.990 --> 00:06:05.675
Eu eliminei aqueles
página trava pesos.

00:06:05.675 --> 00:06:07.580
Se eu descer para a minha carga de trabalho,

00:06:07.580 --> 00:06:10.130
agora está concluída em 35 segundos

00:06:10.130 --> 00:06:13.760
contra os 52 segundos
sem o recurso.

00:06:13.760 --> 00:06:19.220
Portanto, esse recurso é projetado
para permitir que você ajude a escala

00:06:19.220 --> 00:06:23.240
até o seu tempdb pesado
cargas de trabalho controversas

00:06:23.240 --> 00:06:25.400
sem fazer qualquer
alterações de código em tudo.

00:06:25.400 --> 00:06:28.085
Você simplesmente liga a configuração,

00:06:28.085 --> 00:06:31.640
reiniciar o servidor e, em seguida, você
pode ter melhorado imediatamente

00:06:31.640 --> 00:06:33.770
através da entrada e menos
pesos de trava de página

00:06:33.770 --> 00:06:36.320
em suas cargas de trabalho controversas tempdb.

00:06:36.320 --> 00:06:38.300
Então, espero que isso ajude você a aprender

00:06:38.300 --> 00:06:40.790
um pouco mais sobre o
recurso, como você iria usá-lo,

00:06:40.790 --> 00:06:42.860
como você saberia se
você precisa ligá-lo

00:06:42.860 --> 00:06:45.020
ou não e você fica um pouco mais

00:06:45.020 --> 00:06:46.970
animado com as melhorias
que estão chegando

00:06:46.970 --> 00:06:49.610
SQL Server 2019 Muito obrigado.

00:06:49.610 --> 00:07:04.210
[MÚSICA]