WEBVTT

00:00:00.000 --> 00:00:01.830
>> Servidor SQL 2019 fornece

00:00:01.830 --> 00:00:04.995
Um novo recurso para Linux chamado
Amortecedores de registro persistentes.

00:00:04.995 --> 00:00:06.960
Ele estava disponível para windows antes,

00:00:06.960 --> 00:00:08.385
hoje em dia em Linux também,

00:00:08.385 --> 00:00:10.740
e ajuda-o a eliminar
gargalos que podem

00:00:10.740 --> 00:00:14.130
ocorrer ao esperar por um registro
buffer dois flush para disco.

00:00:14.130 --> 00:00:18.300
Brian está aqui para contar a todos nós.
sobre isso hoje em Dados Expostos.

00:00:18.300 --> 00:00:29.040
[MÚSICA]

00:00:29.040 --> 00:00:32.115
>> Oi, e bem-vindo a outro
episódio de Dados Expostos.

00:00:32.115 --> 00:00:35.220
Eu sou seu anfitrião Jeroen, e
hoje eu tenho Brian comigo

00:00:35.220 --> 00:00:38.460
para falar sobre persistente
Buffers de log na SQL 2019.

00:00:38.460 --> 00:00:40.230
Então, oi, Brian, bem-vindo ao show.

00:00:40.230 --> 00:00:42.195
>> Oi, Jeroen. Obrigado.

00:00:42.195 --> 00:00:46.045
>> Então, o que vamos falar
sobre buffers longos persistentes?

00:00:46.045 --> 00:00:47.160
>> Sim. Então,...

00:00:47.160 --> 00:00:47.685
>> O que é isso?

00:00:47.685 --> 00:00:50.400
>> Tão persistente log
Buffer é um dos que

00:00:50.400 --> 00:00:53.325
chamamos a In-Memory
Família de recursos de banco de dados,

00:00:53.325 --> 00:00:55.965
que inclui In-Memory OLTP,

00:00:55.965 --> 00:00:59.265
Tampão de registro persistente que
Eu vou demonstrar hoje,

00:00:59.265 --> 00:01:01.845
às vezes chamado cauda de log caching,

00:01:01.845 --> 00:01:05.040
um arquivo de dados e log
Iluminação em Linux,

00:01:05.040 --> 00:01:07.470
Pool tampão híbrido em
Linux e Windows,

00:01:07.470 --> 00:01:09.870
e metadados tempdb otimizados de memória.

00:01:09.870 --> 00:01:11.370
>> Ok. Fresco.

00:01:11.370 --> 00:01:17.195
>> Então eu vou mencionar rapidamente
sobre dispositivos de memória persistentes.

00:01:17.195 --> 00:01:19.550
Muitas pessoas não têm
vi-os, mas essencialmente

00:01:19.550 --> 00:01:21.730
estes são dimms regulares que você

00:01:21.730 --> 00:01:26.275
alimentar em seu servidor que
vêm em diferentes capacidades.

00:01:26.275 --> 00:01:30.545
MVDIMM-N, que é um tipo de
tecnologia de memória persistente,

00:01:30.545 --> 00:01:34.325
vem um 8, 16, ou 32
gig capacidade DIMM,

00:01:34.325 --> 00:01:36.980
e, em seguida, as últimas Informações obtidas

00:01:36.980 --> 00:01:41.150
DC Memória persistente vem em
capacidades muito mais elevadas de um 128,

00:01:41.150 --> 00:01:44.810
256 gigabytes, ou 512 dimms gigabyte.

00:01:44.810 --> 00:01:46.820
>> São todos eles
memória persistente. Wow.

00:01:46.820 --> 00:01:48.060
>> Sim. Então você pode,

00:01:48.060 --> 00:01:49.290
em um servidor de soquete nate,

00:01:49.290 --> 00:01:52.370
você pode suportar até 24
terabytes de memória persistente.

00:01:52.370 --> 00:01:53.750
>> Eu posso desbloquear todos os

00:01:53.750 --> 00:01:55.970
que com esta persistente
tampão de log, certo?

00:01:55.970 --> 00:01:56.570
>> Correto.

00:01:56.570 --> 00:01:57.680
>> Uau.

00:01:57.680 --> 00:02:00.110
>> Registro Persistente
Buffer é projetado para

00:02:00.110 --> 00:02:02.075
resolver um caso de uso específico

00:02:02.075 --> 00:02:07.400
onde você estava incorrendo em desacelerações
ou espera em sua carga de trabalho,

00:02:07.400 --> 00:02:12.385
à espera do tampão de troncos que
está na memória para lavar a disco.

00:02:12.385 --> 00:02:13.005
>> Ok.

00:02:13.005 --> 00:02:16.114
>> Então ele usa o
dispositivo de memória persistente

00:02:16.114 --> 00:02:19.355
em que sabe que uma vez que é
escrito para esse dispositivo,

00:02:19.355 --> 00:02:21.650
que não precisa
para esperar o flush

00:02:21.650 --> 00:02:24.270
porque já está em
um dispositivo persistente.

00:02:24.270 --> 00:02:26.195
>> Em seguida, o dispositivo vai
cuidar do resto.

00:02:26.195 --> 00:02:28.835
>> Sim, o dispositivo vai
em seguida, cuidar do resto

00:02:28.835 --> 00:02:31.730
enquanto você continuar essencialmente
com sua carga de trabalho.

00:02:31.730 --> 00:02:32.180
>> Sim.

00:02:32.180 --> 00:02:35.585
>> Então, quando você está configurando
estes dispositivos no Windows,

00:02:35.585 --> 00:02:41.600
temos algumas recomendações básicas
que você trava páginas na memória,

00:02:41.600 --> 00:02:44.150
você usa os dois megabytes
tamanho da unidade de alocação

00:02:44.150 --> 00:02:46.760
para ntfs que não será padrão.

00:02:46.760 --> 00:02:47.180
>> Ok.

00:02:47.180 --> 00:02:49.715
>> Também você precisa
definir esta bandeira DAX.

00:02:49.715 --> 00:02:51.920
Então DAX é realmente o que nos permite

00:02:51.920 --> 00:02:55.280
tratar uma memória persistente
dispositivo e escrever para ele

00:02:55.280 --> 00:02:57.260
saltando diretamente todos os

00:02:57.260 --> 00:02:59.795
a pilha de kernel que

00:02:59.795 --> 00:03:03.090
você normalmente precisa
quando se lida com arquivos.

00:03:03.090 --> 00:03:05.145
Não estará disponível no GUI,

00:03:05.145 --> 00:03:07.250
para que você terá que usar
alguns PowerShell para isso.

00:03:07.250 --> 00:03:09.560
>> Ok. Está bem. Você vai
nos mostrar como isso funciona, certo?

00:03:09.560 --> 00:03:13.325
>> Sim. Vou mostrar como
estes são configurados.

00:03:13.325 --> 00:03:16.430
Também alguns do seu nível operacional
contadores de disco que você

00:03:16.430 --> 00:03:19.510
pode ser usado para olhar como
estas transferências e assim por diante,

00:03:19.510 --> 00:03:21.830
pode não estar disponível para

00:03:21.830 --> 00:03:24.200
você quando você está trabalhando com
dispositivos de memória persistentes.

00:03:24.200 --> 00:03:28.865
Essa é apenas uma das coisas.
você precisa estar ciente.

00:03:28.865 --> 00:03:29.330
>> Claro.

00:03:29.330 --> 00:03:33.575
>> Estes são novos dispositivos e este
é muito novo rumo emocionante.

00:03:33.575 --> 00:03:33.935
>> Ok.

00:03:33.935 --> 00:03:37.565
>> Então pode haver alguma captura
até fazer no lado de monitoramento.

00:03:37.565 --> 00:03:38.245
>> Claro.

00:03:38.245 --> 00:03:42.580
>> Para Linux, não volátil
controle do dispositivo

00:03:42.580 --> 00:03:45.110
é o utilitário que você
usar para configurar isso.

00:03:45.110 --> 00:03:47.840
Você vai configurá-lo para o modo fsdax,

00:03:47.840 --> 00:03:50.795
use duas falhas de página megabyte enorme,

00:03:50.795 --> 00:03:53.555
definir a sua alocação de blocos
também para dois megabytes.

00:03:53.555 --> 00:03:56.180
Apoiamos xfs ou ext

00:03:56.180 --> 00:04:00.620
para estes são dois apoiados
sistemas de arquivo com DAX.

00:04:00.620 --> 00:04:01.295
>> Ok.

00:04:01.295 --> 00:04:03.050
>> Tão persistente tampão de registro,

00:04:03.050 --> 00:04:05.585
isto já esteve disponível
na verdade, no SQL desde

00:04:05.585 --> 00:04:10.140
SQL 2016 apenas para Windows até agora.

00:04:10.140 --> 00:04:12.470
Com o SQL 2019, também teremos

00:04:12.470 --> 00:04:15.875
este recurso já está disponível
em Linux, bem como no Windows.

00:04:15.875 --> 00:04:18.590
Usa apenas um muito pequeno
quantidade de capacidade,

00:04:18.590 --> 00:04:21.720
o tampão de registro é de apenas 20
megabytes por banco de dados do usuário.

00:04:21.720 --> 00:04:22.355
>> Ok.

00:04:22.355 --> 00:04:26.330
>> Então, realmente não é preciso
até uma enorme quantidade de capacidade,

00:04:26.330 --> 00:04:28.850
e o comportamento que você tem é muito

00:04:28.850 --> 00:04:31.250
semelhante à força
durabilidade atrasada.

00:04:31.250 --> 00:04:31.910
>> Ok.

00:04:31.910 --> 00:04:34.040
>> Então, novamente, você não está esperando

00:04:34.040 --> 00:04:36.890
que log flush para acontecer com o disco

00:04:36.890 --> 00:04:40.040
mas não incentivou nenhum dos riscos que

00:04:40.040 --> 00:04:43.235
você toma o que forçado atrasado
Durabilidade em torno da perda de dados.

00:04:43.235 --> 00:04:45.290
>> Então você pode nos dizer um
pouco mais sobre

00:04:45.290 --> 00:04:47.550
Durabilidade atrasada forçada
para aqueles que são...

00:04:47.550 --> 00:04:48.615
>> Claro, para aqueles-

00:04:48.615 --> 00:04:49.425
>> -não ciente disso?

00:04:49.425 --> 00:04:52.095
>> Sim. Para aqueles que
não são familiares,

00:04:52.095 --> 00:04:53.840
isto é essencialmente

00:04:53.840 --> 00:04:57.260
um compromisso assíncrono
mecanismo no servidor SQL.

00:04:57.260 --> 00:04:57.710
>> Ok.

00:04:57.710 --> 00:05:01.280
>> Então há um casal
de maneiras de fazê-lo.

00:05:01.280 --> 00:05:03.740
Um é permitido, caso em que

00:05:03.740 --> 00:05:07.190
seus compromissos normais
acontecer como você espera,

00:05:07.190 --> 00:05:08.270
você espera pelo flush,

00:05:08.270 --> 00:05:10.455
esperar por eles para ser endurecido no disco,

00:05:10.455 --> 00:05:15.440
ou em um modo forçado onde todos
compromissos se comportam assim.

00:05:15.440 --> 00:05:16.000
>> Ok.

00:05:16.000 --> 00:05:19.220
>> Então, o que permitiu entrar
você especificar em um per

00:05:19.220 --> 00:05:22.880
comprometer a base se você quiser isso
comportamento e isso é permitido,

00:05:22.880 --> 00:05:24.935
não permitido qual é o padrão

00:05:24.935 --> 00:05:27.425
não importa o que você tem em
lá não vai acontecer.

00:05:27.425 --> 00:05:27.905
>> Claro.

00:05:27.905 --> 00:05:30.170
>> Então forçou todos
compromissos se comporta maqui.

00:05:30.170 --> 00:05:32.285
>> Ok. Então, em um persistente
baixo nível é muito

00:05:32.285 --> 00:05:34.890
semelhante, mas não inteiramente o mesmo.

00:05:34.890 --> 00:05:37.215
>> Muito semelhante, mas
não é inteiramente o mesmo,

00:05:37.215 --> 00:05:39.845
porque temos o
dispositivo de memória persistente,

00:05:39.845 --> 00:05:42.965
colocamos nosso tampão de log lá,

00:05:42.965 --> 00:05:46.640
e uma vez que escrevemos lá, sabemos
que persistiu e nós

00:05:46.640 --> 00:05:50.360
não têm qualquer risco de perda de dados
no caso de um acidente de servidor,

00:05:50.360 --> 00:05:53.000
falha de energia, qualquer coisa
dessa natureza,

00:05:53.000 --> 00:05:56.570
podemos recuperar dos dados
o dispositivo de memória persistente.

00:05:56.570 --> 00:05:57.920
>> Ok. Fresco.

00:05:57.920 --> 00:06:00.230
>> Na verdade, é muito simples.

00:06:00.230 --> 00:06:01.640
Muitas pessoas não percebem,

00:06:01.640 --> 00:06:04.355
você simplesmente adicionar um arquivo de registro

00:06:04.355 --> 00:06:07.580
de 20 megabytes no
dispositivo de memória persistente,

00:06:07.580 --> 00:06:10.370
SQL Servidor will
reconhecer este dispositivo,

00:06:10.370 --> 00:06:13.265
e tratá-lo-á como o amortecedor do registro.

00:06:13.265 --> 00:06:14.405
>> É muito simples

00:06:14.405 --> 00:06:15.665
>> Realmente tão simples.

00:06:15.665 --> 00:06:16.205
>> Uau.

00:06:16.205 --> 00:06:19.550
>> Sim, e como podemos ver
aqui estão tampão log sentado em

00:06:19.550 --> 00:06:23.090
nossa memória de classe de armazenamento
que é PMM às vezes

00:06:23.090 --> 00:06:26.480
chamamos de classe de armazenamento
memória e em alguns lugares

00:06:26.480 --> 00:06:30.405
mas a mesma coisa e a nossa
registros de registro estão lá,

00:06:30.405 --> 00:06:31.950
e como mencionei,

00:06:31.950 --> 00:06:33.200
não temos que esperar.
para eles através

00:06:33.200 --> 00:06:36.365
liberado para o principal
arquivo de registro de transação.

00:06:36.365 --> 00:06:37.010
>> Legal.

00:06:37.010 --> 00:06:41.875
>> Então eu vou mudar
rapidamente para a minha demonstração aqui.

00:06:41.875 --> 00:06:42.990
>> Sim.

00:06:42.990 --> 00:06:46.280
>> Primeiro eu vou mostrar
que configurámos

00:06:46.280 --> 00:06:49.310
aqui nossos dispositivos de memória persistentes.

00:06:49.310 --> 00:06:50.945
Como mencionei, estes
são dimms regulares,

00:06:50.945 --> 00:06:53.180
você pode ver as di do dispositivo lá.

00:06:53.180 --> 00:06:56.405
Nós configuramos dois
dispositivos um por nó NUMA.

00:06:56.405 --> 00:06:56.855
>> Ok.

00:06:56.855 --> 00:07:01.565
>> Interleaved através dos dispositivos
em DIMMs naquele nó NUMA.

00:07:01.565 --> 00:07:05.330
Portanto, este é o recomendado
maneira que dizemos para configurá-lo.

00:07:05.330 --> 00:07:06.410
>> Ok.

00:07:06.410 --> 00:07:08.950
>> Mais uma vez, podemos ver que

00:07:08.950 --> 00:07:12.920
nosso valor DAX está habilitado
é verdade aqui,

00:07:12.920 --> 00:07:17.464
e se quisermos usar o nosso mais velho
utilitário tipo linha de comando,

00:07:17.464 --> 00:07:21.830
podemos conseguir esse pouco.
pouco mais informações aqui e nós podemos

00:07:21.830 --> 00:07:26.450
ver que definimos a alocação
tamanho da unidade para dois megabytes.

00:07:26.450 --> 00:07:28.640
>> Como você acabou de descrever.
Deveria ser.

00:07:28.640 --> 00:07:31.505
>> Sim. Como eu acabei de fazer
descrito e bastante

00:07:31.505 --> 00:07:36.185
simples, apenas adicionar o
arquivo de registro, como mencionei,

00:07:36.185 --> 00:07:38.205
e nós apenas criamos e

00:07:38.205 --> 00:07:40.700
independentemente do tamanho que você
colocá-lo aqui nós vamos realmente

00:07:40.700 --> 00:07:42.860
integrado para usar 20 megabytes

00:07:42.860 --> 00:07:46.025
mas basta ir em frente e
digamos que 20 megabytes se sentam.

00:07:46.025 --> 00:07:47.975
>> Sim. Só para ter certeza.

00:07:47.975 --> 00:07:50.960
>> Sim, e é realmente tão simples.

00:07:50.960 --> 00:07:52.550
>> Uau. Está bem.

00:07:52.550 --> 00:07:54.200
Então isso é impressionante.

00:07:54.200 --> 00:07:56.900
Então, basicamente, eu posso desbloquear
todos estes novos tecnológicos com

00:07:56.900 --> 00:07:58.580
um buffer de log persistente por apenas

00:07:58.580 --> 00:08:00.650
executando comando muito simples, certo?

00:08:00.650 --> 00:08:01.055
>> Sim.

00:08:01.055 --> 00:08:02.930
>> Claro. Você tem que fazer isso.
configurar o dispositivo primeiro,

00:08:02.930 --> 00:08:05.965
e depois disso é feito
em SQL você acabou de adicionar um registro.

00:08:05.965 --> 00:08:09.350
>> Sim, e este tipo

00:08:09.350 --> 00:08:12.725
de tecnologia é realmente
permitindo um novo nível de

00:08:12.725 --> 00:08:15.020
armazenamento ajudando a remover alguns dos

00:08:15.020 --> 00:08:17.075
o tradicional
gargalos que vemos

00:08:17.075 --> 00:08:19.640
no SQL Server com cargas de trabalho de alta gama.

00:08:19.640 --> 00:08:22.220
>> Certo. Tão grande inovação, mas

00:08:22.220 --> 00:08:24.710
então feito de uma maneira muito simples

00:08:24.710 --> 00:08:26.570
para o usuário e para
a configuração.

00:08:26.570 --> 00:08:29.360
>> Sim. Construímos inteligência
em SQL Server para

00:08:29.360 --> 00:08:32.240
reconhecer esses dispositivos
e comportar-se em conformidade.

00:08:32.240 --> 00:08:34.295
>> Sim. Muito legal. Bem
obrigado por compartilhar.

00:08:34.295 --> 00:08:34.895
>> Obrigado.

00:08:34.895 --> 00:08:36.560
>> Eu acho que isso foi muito útil,

00:08:36.560 --> 00:08:37.910
muito interessante, pelo menos para mim.

00:08:37.910 --> 00:08:40.490
Espero que isso tenha sido útil e
interessante para você também.

00:08:40.490 --> 00:08:43.065
Por favor, inscreva-se, tipo,
comentário sobre o vídeo,

00:08:43.065 --> 00:08:44.660
e espero vê-lo da próxima vez

00:08:44.660 --> 00:08:47.040
outro episódio de
Dados expostos. Thansk.

00:08:47.040 --> 00:09:01.630
[MÚSICA]

