WEBVTT

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

00:00:10.560 --> 00:00:12.975
>> Ei, bem-vindo a um novo
episódio de Dados Expostos.

00:00:12.975 --> 00:00:14.460
Meu nome é Pedro Lopes.

00:00:14.460 --> 00:00:16.920
Eu sou um gerente de programa no
Equipe de engenharia de servidores da SQL.

00:00:16.920 --> 00:00:18.510
Hoje, eu vou estar falando

00:00:18.510 --> 00:00:20.670
sobre inteligente
Banco de dados, especificamente,

00:00:20.670 --> 00:00:23.809
Processamento inteligente de consultas
no SQL Server 2019,

00:00:23.809 --> 00:00:25.925
e também banco de dados SQL Azure.

00:00:25.925 --> 00:00:29.390
Então, vamos chegar a ele. Sql
Servidor 2019 apresenta

00:00:29.390 --> 00:00:31.864
consulta inovadora
melhorias de desempenho

00:00:31.864 --> 00:00:34.655
e eles são os inteligentes
Família de processamento de consultas.

00:00:34.655 --> 00:00:37.820
Estes compõem as últimas
Missão da Microsoft para se certificar de

00:00:37.820 --> 00:00:41.690
que cargas de trabalho paralelas críticas
melhorar ao correr em escala,

00:00:41.690 --> 00:00:45.470
mantendo-se adaptável ao
constantemente mudando o mundo dos dados,

00:00:45.470 --> 00:00:47.855
à medida que os dados se movem e
fora dos bancos de dados.

00:00:47.855 --> 00:00:49.670
Neste vídeo, eu vou te dar

00:00:49.670 --> 00:00:51.980
uma visão rápida do
Mundo inteligente da base de dados

00:00:51.980 --> 00:00:53.030
que realmente dá um salto

00:00:53.030 --> 00:00:56.150
para a frente com o próximo
Servidor SQL 2019,

00:00:56.150 --> 00:00:58.700
e apresentá-lo a um número
de recursos que vamos mergulhar

00:00:58.700 --> 00:01:02.130
em mais profundo em outros
vídeos nesta série.

00:01:03.170 --> 00:01:07.510
Processamento inteligente de consultas
no SQL Server está disponível por

00:01:07.510 --> 00:01:11.245
inadimplência no banco de dados mais recente
configuração de nível de compatibilidade.

00:01:11.245 --> 00:01:13.210
Isso significa que depois de atualizar,

00:01:13.210 --> 00:01:15.130
isso pode estar disponível apenas por

00:01:15.130 --> 00:01:18.000
Virando o interruptor para usar o
última configuração de compatibilidade.

00:01:18.000 --> 00:01:22.030
Processamento inteligente de consultas
também proporciona amplo impacto

00:01:22.030 --> 00:01:23.440
que melhora o desempenho de

00:01:23.440 --> 00:01:26.650
cargas de trabalho existentes com
esforço mínimo de implementação.

00:01:26.650 --> 00:01:28.390
Isso realmente significa que na maioria das vezes,

00:01:28.390 --> 00:01:30.965
não é necessidade zero de
refatorie seu código.

00:01:30.965 --> 00:01:33.310
Processamento de consultas inteligentes melhora

00:01:33.310 --> 00:01:36.190
cargas de trabalho paralelas críticas
ao correr em escala,

00:01:36.190 --> 00:01:39.355
e à medida que os dados fluem e
fora do seu banco de dados,

00:01:39.355 --> 00:01:41.380
vamos nos adaptar a isso e

00:01:41.380 --> 00:01:44.660
manter um nível de
desempenho previsível.

00:01:44.660 --> 00:01:47.450
Por exemplo, aintrodução

00:01:47.450 --> 00:01:49.880
um mecanismo de feedback
no uso da memória,

00:01:49.880 --> 00:01:53.630
podemos garantir que sua carga de trabalho
executa de forma previsível.

00:01:53.630 --> 00:01:58.190
Se uma determinada execução de consulta fosse
talvez pegar muita memória,

00:01:58.190 --> 00:01:59.750
podemos corrigi-lo e

00:01:59.750 --> 00:02:02.375
aumentar a conmoeda
fator de seu banco de dados.

00:02:02.375 --> 00:02:06.020
Se uma determinada execução de capital próprio
não recebe memória suficiente e

00:02:06.020 --> 00:02:09.560
acaba usando IO adicional
todo é conhecido como um derramamento,

00:02:09.560 --> 00:02:11.315
então também podemos descobrir que

00:02:11.315 --> 00:02:13.565
e corrigir a situação
para que a operação

00:02:13.565 --> 00:02:15.260
executa na memória e

00:02:15.260 --> 00:02:18.200
executa como esperado em
execuções subsequentes.

00:02:18.200 --> 00:02:20.540
Esse recurso agora está habilitado para

00:02:20.540 --> 00:02:22.835
todos os modos de execução em
o centro de banco de dados.

00:02:22.835 --> 00:02:27.170
Modo de lote para mais armazém de dados
e cargas de trabalho analíticas,

00:02:27.170 --> 00:02:31.410
e modo de linha para o seu modo
cargas de trabalho críticas da OLTP.

00:02:31.700 --> 00:02:34.640
Também vamos para novas áreas

00:02:34.640 --> 00:02:37.220
que estamos chamando
processamento de consultas aproximadas.

00:02:37.220 --> 00:02:40.640
Por exemplo, pense em um cenário
onde uma empresa ferroviária mantém

00:02:40.640 --> 00:02:42.350
faixa de números de bilhetes que são

00:02:42.350 --> 00:02:44.935
comprado e usado no
todo o sistema ferroviário.

00:02:44.935 --> 00:02:47.030
Eles acompanham isso.
a fim de implementar

00:02:47.030 --> 00:02:49.730
algumas medições de controle de fluxo
quando é necessário,

00:02:49.730 --> 00:02:52.610
talvez, adaptando o
horários dos trens,

00:02:52.610 --> 00:02:53.630
ou o número de comboios

00:02:53.630 --> 00:02:55.810
o sistema para atender ao
necessidades do momento.

00:02:55.810 --> 00:02:58.920
Esta informação também é
atualizado em um painel

00:02:58.920 --> 00:03:02.530
que as pessoas no centro da cidade
Central pode dar uma olhada.

00:03:02.530 --> 00:03:04.220
Agora, neste cenário, parte de

00:03:04.220 --> 00:03:06.830
a carga de trabalho será certamente
para executar uma consulta que é

00:03:06.830 --> 00:03:09.020
constantemente olhando para a obtenção

00:03:09.020 --> 00:03:12.005
a contagem de linha de todos os
bilhetes que são vendidos e usados,

00:03:12.005 --> 00:03:14.600
e isso é provavelmente
vindo de um muito

00:03:14.600 --> 00:03:17.605
grande estável, talvez, com
bilhões e bilhões de linhas.

00:03:17.605 --> 00:03:20.540
Agora, esta consulta recorrente
normalmente, ascoisas

00:03:20.540 --> 00:03:23.735
recursos consideráveis
seu servidor, ou seja, memória.

00:03:23.735 --> 00:03:25.639
Se for executado repetidamente,

00:03:25.639 --> 00:03:26.690
pode realmente afetar

00:03:26.690 --> 00:03:28.900
as características de desempenho
do seu banco de dados.

00:03:28.900 --> 00:03:30.670
No entanto, neste cenário,

00:03:30.670 --> 00:03:32.750
a empresa ferroviária
não precisa necessariamente

00:03:32.750 --> 00:03:35.830
uma contagem real de todos os
bilhetes que são vendidos e usados.

00:03:35.830 --> 00:03:37.790
Mas muito alto
aproximação é suficiente

00:03:37.790 --> 00:03:40.280
para desencadear todos os
tomada de decisão necessária.

00:03:40.280 --> 00:03:42.935
É aqui que se aproxima
contagem distinta vem,

00:03:42.935 --> 00:03:45.500
permitindo uma consulta
para obter repetidamente

00:03:45.500 --> 00:03:48.185
a contagem aproximada
de bilhetes vendidos e usados

00:03:48.185 --> 00:03:51.080
sem os graves impactos
o desempenho do seu banco de dados que

00:03:51.080 --> 00:03:55.420
sua consulta de contagem normal
levaria hoje.

00:03:55.640 --> 00:03:58.695
Ao ativar o modo batch na Row Store,

00:03:58.695 --> 00:03:59.950
nós efetivamente desencadear

00:03:59.950 --> 00:04:02.150
o modo de processamento que é
especialmente otimizado

00:04:02.150 --> 00:04:05.975
para cargas de trabalho analíticas sobre
qualquer tabela em seu banco de dados.

00:04:05.975 --> 00:04:08.180
Isso significa que mesmo
para cenários onde

00:04:08.180 --> 00:04:10.385
um índice de loja de coluna
não seria uma opção,

00:04:10.385 --> 00:04:14.395
o motor do banco de dados ainda pode
execute isso de forma otimizada.

00:04:14.395 --> 00:04:17.375
Por sua vez, isso abre o escopo de

00:04:17.375 --> 00:04:20.630
recursos como a adesão adaptativa
para ser usado por sua carga de trabalho.

00:04:20.630 --> 00:04:24.170
A desadesão adaptativa, que é apenas
disponível no modo lote pode

00:04:24.170 --> 00:04:28.940
agora ser aproveitado em todos os
tabelas e a maioria de suas cargas de trabalho.

00:04:29.590 --> 00:04:33.170
Também abordamos alguns dos
mais recorrentes anti-padrões

00:04:33.170 --> 00:04:36.260
que se tornam um problema para
cargas de trabalho gerenciadas do Servidor SQL.

00:04:36.260 --> 00:04:38.150
O uso da tabela
Variáveis e o uso

00:04:38.150 --> 00:04:40.105
de Scalar UDFs, por exemplo,

00:04:40.105 --> 00:04:42.440
e agora podemos desbloquear novos níveis de

00:04:42.440 --> 00:04:46.375
otimização de consultas que foram
não é possível até recentemente.

00:04:46.375 --> 00:04:49.310
Tudo isso, nós vamos
discutir mais profundamente e com

00:04:49.310 --> 00:04:51.080
demonstrações nos próximos vídeos em

00:04:51.080 --> 00:04:53.270
a série sobre o
banco de dados inteligente,

00:04:53.270 --> 00:04:56.020
especificamente inteligente
processamento de consultas.

00:04:56.020 --> 00:04:59.505
Mas se você quiser saber
mais sobre isso hoje,

00:04:59.505 --> 00:05:04.200
então, por favor, vá para este aka.ms/IQP

00:05:04.200 --> 00:05:06.899
URL onde você vê todos
a documentação

00:05:06.899 --> 00:05:09.535
em Consulta Inteligente
Processamento em bancos de dados SQL.

00:05:09.535 --> 00:05:13.100
Se você quiser experimentar alguns
destes por si mesmo agora,

00:05:13.100 --> 00:05:16.040
temos também demonstrações que
você pode olhar se você

00:05:16.040 --> 00:05:18.980
ir ao nosso repositório GitHub
e a URL curta seria

00:05:18.980 --> 00:05:22.430
estar aka.ms/IQPDemos onde você vai

00:05:22.430 --> 00:05:25.900
ser capaz de olhar para todos estes
características e experiência por si mesmo.

00:05:25.900 --> 00:05:27.795
Então, novamente, tome cuidado.

00:05:27.795 --> 00:05:28.980
Falarei com você em breve.

00:05:28.980 --> 00:05:43.780
[MÚSICA].