WEBVTT

00:00:00.000 --> 00:00:02.055
>> Recuperação do banco de dados com

00:00:02.055 --> 00:00:05.190
transações de longa duração
tem sido um desafio.

00:00:05.190 --> 00:00:07.050
No SQL Server 2019,

00:00:07.050 --> 00:00:09.780
introduzimos acelerado
recuperação de banco de dados

00:00:09.780 --> 00:00:11.190
para ajudar a resolver esse problema.

00:00:11.190 --> 00:00:13.605
Kevin está aqui para contar.
nós todos sobre isso,

00:00:13.605 --> 00:00:15.390
hoje em Dados Expostos.

00:00:15.390 --> 00:00:26.130
[MÚSICA]

00:00:26.130 --> 00:00:28.755
>> Oi e bem-vindo a outro
episódio de Dados Expostos.

00:00:28.755 --> 00:00:30.745
Eu sou seu anfitrião, Jeroen e hoje,

00:00:30.745 --> 00:00:34.415
temos Kevin conosco para falar sobre
recuperação acelerada do banco de dados.

00:00:34.415 --> 00:00:35.975
Então, dê em quando Kevin dê as boas-vindas ao show.

00:00:35.975 --> 00:00:36.665
>> Obrigado.

00:00:36.665 --> 00:00:39.125
>> Então acelerou a recuperação do banco de dados.

00:00:39.125 --> 00:00:40.750
Então, o que é isso?

00:00:40.750 --> 00:00:41.930
>> Então é uma característica interessante.

00:00:41.930 --> 00:00:43.340
Vamos chamá-lo de ADR para breve.

00:00:43.340 --> 00:00:44.890
>> Ok, claro.

00:00:44.890 --> 00:00:46.970
>> Veio de
olhando para alguns dos

00:00:46.970 --> 00:00:48.530
pontos de dor que os clientes tiveram

00:00:48.530 --> 00:00:51.770
executando bancos de dados e mantendo
eles altamente disponíveis e

00:00:51.770 --> 00:00:53.270
parte disso tem a ver com o tempo que

00:00:53.270 --> 00:00:55.475
leva para trazer um banco de dados on-line.

00:00:55.475 --> 00:00:58.970
Há uma série de fases que
um banco de dados tem que passar,

00:00:58.970 --> 00:01:01.340
e se você tem um longo
transação de execução,

00:01:01.340 --> 00:01:04.010
pode levar muito tempo
para limpar isso e que

00:01:04.010 --> 00:01:07.080
leva à indisponibilidade quando
está fazendo esse processamento.

00:01:07.080 --> 00:01:10.545
>> Certo. Então, sabemos que isso
restaurar é um ponto de dor.

00:01:10.545 --> 00:01:13.530
Trazê-lo de volta é
algo que DBAs,

00:01:13.530 --> 00:01:15.075
Bem, tipo de se preocupar.

00:01:15.075 --> 00:01:16.790
>> Certo. Assim, a equipe olhou

00:01:16.790 --> 00:01:19.520
todo o processo e pensamento
como podemos reimaginá-lo?

00:01:19.520 --> 00:01:21.335
Então eles vieram com ADR,

00:01:21.335 --> 00:01:23.210
é baseado em uma loja de versões.

00:01:23.210 --> 00:01:26.170
Então, todas as mudanças são
versão no banco de dados.

00:01:26.170 --> 00:01:29.920
Isso vive no arquivo
grupo de sua escolha.

00:01:30.140 --> 00:01:34.925
Aproveitando isso, podemos fazer o
processo de recuperação muito mais rápido.

00:01:34.925 --> 00:01:35.600
>> Legal.

00:01:35.600 --> 00:01:40.965
>> Eu tenho alguns slides
que demonstram.

00:01:40.965 --> 00:01:46.515
Então, aqui temos o
processo de recuperação clássico.

00:01:46.515 --> 00:01:48.350
Então começa, a Fase 1 é a análise.

00:01:48.350 --> 00:01:50.360
Então você tem que olhar através
todas as transações

00:01:50.360 --> 00:01:53.020
no registro do último
posto de controle para a frente.

00:01:53.020 --> 00:01:56.150
Refazer são alterações de dados

00:01:56.150 --> 00:01:58.700
que não foi persistido
nos arquivos de dados,

00:01:58.700 --> 00:02:01.850
tem que ser reredone de
o registro de transação,

00:02:01.850 --> 00:02:03.020
todo o caminho através de

00:02:03.020 --> 00:02:05.420
o início dos mais antigos,
transações não comprometidas.

00:02:05.420 --> 00:02:07.790
Então é aí que a longa duração
transações realmente machucá-lo.

00:02:07.790 --> 00:02:08.560
>> Certo, exatamente.

00:02:08.560 --> 00:02:12.170
>> Pode levar um minuto para
uma hora ou mais, às vezes.

00:02:12.170 --> 00:02:14.660
Então, a Fase 3 é desfazer,

00:02:14.660 --> 00:02:17.270
onde você desfaz todas as transações que

00:02:17.270 --> 00:02:20.975
não foram cometidos antes do
tempo que você olha para a frente.

00:02:20.975 --> 00:02:23.285
No momento em que a leitura termina,

00:02:23.285 --> 00:02:25.375
o banco de dados está parcialmente disponível.

00:02:25.375 --> 00:02:28.670
O que isso significa é que você pode
acessar o banco de dados, mas

00:02:28.670 --> 00:02:33.270
quaisquer dados que não estavam bloqueados
das transações originais,

00:02:33.270 --> 00:02:34.320
estará preso agora.

00:02:34.320 --> 00:02:36.200
Assim, mesmo que haja
ninguém fazê-los,

00:02:36.200 --> 00:02:39.230
você não pode acessar esses dados
até desfazer completa.

00:02:39.230 --> 00:02:41.930
>> Então, basicamente, isso é
um processo de longa duração

00:02:41.930 --> 00:02:45.835
e só depois
chegamos à Fase 3,

00:02:45.835 --> 00:02:47.900
Eu posso começar a fazer

00:02:47.900 --> 00:02:49.580
tudo o que eu queria com
o banco de dados de novo, certo?

00:02:49.580 --> 00:02:50.165
>> Certo.

00:02:50.165 --> 00:02:53.585
>> Então me diga como foi.

00:02:53.585 --> 00:02:55.865
>> Na parte inferior, você vê apenas

00:02:55.865 --> 00:02:59.145
registro de registro com registro diferente
eventos no registro de registro de registro.

00:02:59.145 --> 00:03:00.165
>> Claro.

00:03:00.165 --> 00:03:02.190
>> ADR muda muito isso.

00:03:02.190 --> 00:03:03.750
Temos a loja de versão de processamento.

00:03:03.750 --> 00:03:06.375
Você vai vê-lo referenciado como PVS.

00:03:06.375 --> 00:03:09.464
Quando colocamos isso nas prévias,

00:03:09.464 --> 00:03:11.915
Pvs viveu no grupo de arquivos primários

00:03:11.915 --> 00:03:13.820
e não há capacidade
para mudar isso.

00:03:13.820 --> 00:03:16.780
Então isso aconteceu, foi aí que
todas essas versões vividas.

00:03:16.780 --> 00:03:19.550
Temos feedback que
clientes gostariam de

00:03:19.550 --> 00:03:22.280
ser capaz de especificar qual
grupo de arquivo que vive dentro

00:03:22.280 --> 00:03:26.180
Eu tenho um grupo de arquivos em massa ou
grupo de arquivo muito rápido, o que quer.

00:03:26.180 --> 00:03:27.740
Então, agora você está com

00:03:27.740 --> 00:03:31.130
o candidato de libertação e com
a versão GA quando ele sai,

00:03:31.130 --> 00:03:33.910
você será capaz de especificar qual
grupo de arquivo e alterá-lo,

00:03:33.910 --> 00:03:35.880
há processo para
mudando-o também.

00:03:35.880 --> 00:03:38.120
Mas vamos passar por isso.
o processo de recuperação

00:03:38.120 --> 00:03:39.755
Parece que com ADR.

00:03:39.755 --> 00:03:42.110
Então começa com a análise,

00:03:42.110 --> 00:03:45.695
que permanece inalterada a partir de
o que você tinha antes.

00:03:45.695 --> 00:03:47.015
>> É o mesmo comportamento, certo?

00:03:47.015 --> 00:03:49.805
>> Certo. Nós introduzimos
o conceito de um sLog.

00:03:49.805 --> 00:03:52.705
Um sLog é um registro na memória

00:03:52.705 --> 00:03:55.640
que registra apenas aqueles
transações do sistema

00:03:55.640 --> 00:03:57.005
que não pode ser versionado.

00:03:57.005 --> 00:03:59.150
Assim, a maioria das versões de dados que você pode

00:03:59.150 --> 00:04:01.715
mudança antes e depois
fotos dos dados.

00:04:01.715 --> 00:04:04.070
Então, algumas mudanças de esquema,

00:04:04.070 --> 00:04:06.195
algumas coisas assim,
não pode ser versionado.

00:04:06.195 --> 00:04:06.570
>> Claro.

00:04:06.570 --> 00:04:07.890
>> Então, esses são registrados no sLog.

00:04:07.890 --> 00:04:09.195
Então a idéia é que é,

00:04:09.195 --> 00:04:11.580
alguns significativos.

00:04:11.580 --> 00:04:13.920
>> Haverá um pequeno
conjunto de projeções, certo?

00:04:13.920 --> 00:04:17.525
>> Então parte da análise
e refazer fase é

00:04:17.525 --> 00:04:23.100
recriar esses logs na memória
dos registros de registro de transação.

00:04:23.230 --> 00:04:25.850
Então refaça do sLog,

00:04:25.850 --> 00:04:28.300
é apenas alavancar a loja versão.

00:04:28.300 --> 00:04:31.195
Porque temos antes e depois
versões de todas essas linhas,

00:04:31.195 --> 00:04:34.010
por isso, é muito rápido e
então você refazer de

00:04:34.010 --> 00:04:38.905
o registro apenas do
último ponto de verificação para a frente.

00:04:38.905 --> 00:04:42.810
Nesse ponto, seu banco de dados
está totalmente disponível.

00:04:43.420 --> 00:04:46.910
Desfazer está apenas revertendo

00:04:46.910 --> 00:04:48.875
as versões para que você apenas

00:04:48.875 --> 00:04:51.710
apontar para a versão anterior
em vez da versão atual.

00:04:51.710 --> 00:04:55.345
Você não tem que desfazer fisicamente
a transação e o inverso.

00:04:55.345 --> 00:04:59.825
>> Então, isso vai ser maneira
mais rápido do que o mais velho normalmente?

00:04:59.825 --> 00:05:01.880
>> Muito mais rápido. Tínhamos um cliente

00:05:01.880 --> 00:05:04.280
o laboratório dentro do último par de
semanas que fizeram alguns testes com

00:05:04.280 --> 00:05:10.050
ADR e eles tinham um muito
carga de trabalho de atualização ativa.

00:05:10.050 --> 00:05:13.065
Eles tinham uma longa duração
transação com ele.

00:05:13.065 --> 00:05:14.430
Eles fizeram isso, isso,

00:05:14.430 --> 00:05:17.450
e fez uma reversão do que
transação de longa duração.

00:05:17.450 --> 00:05:20.555
Sem ADR, levou cerca de um
minuto e meio para fazer isso.

00:05:20.555 --> 00:05:24.765
>> O que ainda não é
Muito ruim, mas tudo bem, muito tempo.

00:05:24.765 --> 00:05:26.190
>> Sim. Nos seus negócios,

00:05:26.190 --> 00:05:28.105
faz uma grande diferença.

00:05:28.105 --> 00:05:30.680
Então eles tentaram novamente
esse mesmo cenário

00:05:30.680 --> 00:05:32.780
com ADR e o tempo que levou

00:05:32.780 --> 00:05:36.720
para fazer essa recuperação foi de zero segundos.

00:05:36.720 --> 00:05:38.505
Eles não podiam medir
Foi tão rápido.

00:05:38.505 --> 00:05:40.110
>> Isso é impressionante.

00:05:40.110 --> 00:05:43.580
>> Então, para eles, eles estão de volta
na linha que muito mais rápido,

00:05:43.580 --> 00:05:47.425
o que faz uma grande diferença
também porque em seus negócios,

00:05:47.425 --> 00:05:49.560
quaisquer interrupções é uma perda de receita.

00:05:49.560 --> 00:05:51.375
>> Então milissegundos contam, certo?

00:05:51.375 --> 00:05:52.230
>> Muito mesmo.

00:05:52.230 --> 00:05:53.880
>> Então, se pudermos ajudar este cliente

00:05:53.880 --> 00:05:55.575
mudou-se de um minuto e meio,

00:05:55.575 --> 00:05:58.305
você disse para basicamente zero,

00:05:58.305 --> 00:05:59.895
Isso é impressionante. Tão uau.

00:05:59.895 --> 00:06:02.930
Assim, todos os nossos clientes

00:06:02.930 --> 00:06:05.810
são provavelmente querendo
tente isso e habilite isso.

00:06:05.810 --> 00:06:08.450
Então, você pode me dizer como eu faço isso?

00:06:08.450 --> 00:06:09.470
Eu tenho um banco de dados agora,

00:06:09.470 --> 00:06:12.995
Eu tenho isso no normal
recuperação, então o que eu faço?

00:06:12.995 --> 00:06:14.585
>> Então, com o banco de dados Azure SQL,

00:06:14.585 --> 00:06:16.775
é por padrão globalmente.

00:06:16.775 --> 00:06:19.130
Tem sido por padrão
globalmente durante meses.

00:06:19.130 --> 00:06:20.540
Então você não precisa
fazer qualquer coisa lá.

00:06:20.540 --> 00:06:22.520
Você já se aproveitou disso.

00:06:22.520 --> 00:06:23.740
>> Legal.

00:06:23.740 --> 00:06:26.940
>> Para bancos de dados do servidor SQL,

00:06:26.940 --> 00:06:29.060
é fora por padrão, porque há

00:06:29.060 --> 00:06:31.610
algumas sobrecarga na faixa de

00:06:31.610 --> 00:06:35.880
um a cinco por cento para
manter o controle das versões.

00:06:36.190 --> 00:06:41.015
Então você teria que ligá-lo e
isso é apenas, alterar conjunto de banco de dados,

00:06:41.015 --> 00:06:42.635
recuperação acelerada de banco de dados é igual a

00:06:42.635 --> 00:06:46.410
em e opcionalmente com
grupo de arquivo é igual.

00:06:46.410 --> 00:06:47.310
>> Alguma coisa.

00:06:47.310 --> 00:06:49.810
>> Sim. Então, ddl muito simples.

00:06:49.810 --> 00:06:51.710
>> Então o que acontece?

00:06:51.710 --> 00:06:54.410
>> Então ele começa a rastrear
versões e você recebe o benefício.

00:06:54.410 --> 00:06:55.970
>> Legal. Isso é direto,

00:06:55.970 --> 00:06:58.065
imediato, ou é assim,

00:06:58.065 --> 00:06:59.250
há um reinício necessário.

00:06:59.250 --> 00:07:01.740
>> Sem reinício. Você está apenas online.

00:07:01.740 --> 00:07:03.705
>> Legal. Tão uau.

00:07:03.705 --> 00:07:05.160
Então, basicamente, isso é como

00:07:05.160 --> 00:07:08.545
uma tecnologia muito legal para
restaurar um banco de dados muito rapidamente.

00:07:08.545 --> 00:07:10.730
Mais alguma coisa que eu recebo com isso?

00:07:10.730 --> 00:07:12.140
Quero dizer, isso é realmente
muito impressionante, mas

00:07:12.140 --> 00:07:13.580
estes são como benefícios extras.

00:07:13.580 --> 00:07:15.590
>> Então há um benefício extra em

00:07:15.590 --> 00:07:19.115
que por causa do caminho
reutilizar as versões,

00:07:19.115 --> 00:07:22.470
não temos que manter como
muito registro de transações on-line.

00:07:22.470 --> 00:07:24.920
Então você pode truncar o
registro de transação muito mais

00:07:24.920 --> 00:07:28.725
agressivamente até o último
posto de controle do que antes.

00:07:28.725 --> 00:07:30.530
O que significa, se você tiver
tem a situação,

00:07:30.530 --> 00:07:32.540
temos uma longa duração
transação que está mantendo você

00:07:32.540 --> 00:07:34.460
de ser capaz de truncar

00:07:34.460 --> 00:07:36.620
seu registro e a transação
log começa a explodir,

00:07:36.620 --> 00:07:38.665
isso não acontece.
com ADR ligado.

00:07:38.665 --> 00:07:41.400
>> Então, basicamente, isso é
o benefício extra.

00:07:41.400 --> 00:07:43.650
Nenhuma transação longa
log arrastando junto.

00:07:43.650 --> 00:07:44.505
>> Exatamente.

00:07:44.505 --> 00:07:45.990
>> Eu sei o que vou fazer,

00:07:45.990 --> 00:07:47.660
Quero dizer mysql servidor foi ir para

00:07:47.660 --> 00:07:49.760
acelerar um banco de dados
recuperação agora.

00:07:49.760 --> 00:07:51.470
Depois deste vídeo, eu vou fazer isso.

00:07:51.470 --> 00:07:52.805
Muito obrigado por compartilhar.

00:07:52.805 --> 00:07:53.345
>> Obrigado.

00:07:53.345 --> 00:07:55.940
>> Obrigado por explicar.
Isso foi muito claro.

00:07:55.940 --> 00:07:57.575
Obrigado por assistir.

00:07:57.575 --> 00:08:00.990
Por favor, como e se inscrever e
ficar atento para o próximo. Thansk.

00:08:00.990 --> 00:08:13.210
[MÚSICA]