SQL SERVER - Dicas que todo DEV deveria conhecer part-5

Nesta sequencia de tópicos abordaremos algumas dicas, que todo desenvolvedor deveria ter a oportunidade de conhecer. Todo desenvolvedor que programa em T/SQL, precisa estar atento a algumas "tips" do SQL Server que podem facilitar em seu dia-a-dia na empresa.

Dicas part-1 Transaction Log
Dicas part-2 Variáveis ​​table e JOIN's & Criação de tabelas dentro de stored procedures
Dicas part-3 Keywords performance
Dicas part-4 Ad Hoc Queries (Forced Parameteeterization)

Parte 5 - SET DEADLOCK_PRIORITY

Evite deadlock's para transações mais importantes, com a mínima alteração de código.

Hoje vamos aprender hoje como reduzir o impasse em transações importantes, com a mínima alteração de código. O requisito, não importa o que aconteça, não desejamos que essa transação entre em conflito (bloqueio). Outro requisito importante é, que não podemos alterar a regra de negocio, modificações profundas no código do sistema, sem compreender a lógica de negócios.

Nosso primeiro objetivo é, entender o que está criando o deadlock?
Depois de investigar, sempre descobrimos concorrências simultâneas em uma ou mais tabelas especificas.

De fato, a melhor solução é SEMPRE é reescrever o código para que não exista o deadlock,
mas nem sempre é possível como uma solução imediata.

Isso nos leva a apenas uma solução rápida; Definir a prioridade do deadlock.

1	SET DEADLOCK_PRIORITY HIGH;

Esta instrução quando "setada", especifica a real importância da sessão atual.

Se a sessão estiver em conflito com outra transação. Esta declaração SET certifica-se de que
a transação importante deste conteudo, não entrará em deadlock, porem as outras transações ficam em espera com uma maior frequência.

Neste cenário, o hint descrito nesta postagem reduziu o impasse para a transação importante,
mas não reduziu o número total do bloqueios. Portanto, use a técnica somentos nos casos extremamente especiais, quando não é possivel alteração de codigo, conforme detalhamos anteriormente.

Curiosidade:

• Se ambas as sessões tiverem a mesma prioridade de deadlock, a instância do SQL Server escolhe a sessão que é menos dispendiosa para ser revertida como a vítima de deadlock. Por exemplo, se ambas as sessões tiverem definido sua prioridade de deadlock como HIGH, a instância escolherá como uma vítima a sessão que calcula ser menos dispendiosa para reverter. O custo é determinado comparando o número de bytes de log gravados naquele ponto em cada transação.

Você usa deadlock priority na sua lógica de negócios?
Compartilhe sua experiência nos comentários.

Grande abraços

SQL SERVER - Dicas que todo DEV deveria conhecer part-4

    Nesta sequencia de tópicos abordaremos algumas dicas, que todo desenvolvedor deveria ter a oportunidade de conhecer. Todo desenvolvedor que programa em T/SQL, precisa estar atento a algumas "tips" do SQL Server em seu dia-a-dia na empresa.

Dicas part-1 Transaction Log
Dicas part-2 Variáveis ​​table e JOIN's & Criação de tabelas dentro de stored procedures
Dicas part-3 Keywords performance

Parte 4 - Ad Hoc Queries (Forced Parameterization)

Uma Consulta Ad Hoc é um tipo de consulta SQL em um banco de dados que é criada na hora,
no momento em que surge uma necessidade, a partir de um requisito específico.

Ad hoc é uma expressão em latim que significa “para este propósito“.  Ou seja, a consulta é criada apenas para satisfazer aquela necessidade específica, aquele propósito, em um momento específico.

(Que não seja generalista, Que não seja utilizável em mais de um caso) e que não é salva no cache do SGBD como por exemplo fazemos com estored procedures, funções ou scripts, para que sejam reutilizados posteriormente.


É interessante notar que em ambientes onde queries Ad Hoc representam um percentual considerável do workload total,  quantidade de compilações pode se tornar um problema, independente do tamanho do servidor.

O motivo é simples, o SQL Server, por padrão, produz diferentes planos de execução para cada query Ad Hoc

Por exemplo:

Query 1

SELECT ColunaA, ColunaB, ColunaC FROM Tabela WHERE ColunaA = 'X'

Aqui o SQL compilaria e guardaria no cache o plano de execução utilizado para encontrar registros onde o valor = X.

Query 2

SELECT ColunaA, ColunaB, ColunaC FROM Tabela WHERE ColunaA = 'Y'

Bem, numa execução parametrizada (Uma stored procedure, por exemplo), o SQL Server simplesmente poderia reutilizar o plano da primeira query já que a mudança foi mínima (apenas o valor utilizado no filtro), porém a engine relacional entende como uma nova query, ou seja,
durante o processo de otimização da query o Query Optmizer recebe um cache miss, que basicamente indica que não há um plano de execução existente para esta query e ele então é responsável por gerar e armazenar esse novo plano no cache, mesmo sendo praticamente igual ao plano anterior.

Quais opções eu tenho para diminuir o número de compilações?

Bem, se você acredita que a grande maioria das suas queries utilizam planos similares para serem executadas, Não faça o simplista SELECT * FROM puro, você poderia utilizar a opção system stored procedure sp_executesql. Quando utilizada, você está basicamente forçando a parametrização da query especifica.


** Por complexidade, estamos detalhando aos desenvolvedores apenas o Forced Parameterization, sem a necessidade de ativar o "optimize for ad hoc workloads" por Database, que ficaria sob responsabilidade mais detalhadas dos encarregados pela Base de dados (DBA's).

Por exemplo:

 EXECUTE sp_executesql  N'SELECT ColunaA, ColunaB, ColunaC FROM Tabela WHERE ColunaA = @valor', N'@valor varchar(1)', @valor = 'X'; 

Nesta execução, se observarmos o plano armazenado em cache seria algo mais ou menos assim:

SELECT ColunaA, ColunaB, ColunaC FROM Tabela WHERE ColunaA = @valor.

Ou seja, não há um valor específico armazenado junto ao plano, o que faz com que a próxima execução, independente do parâmetro utilizado, encontre um plano satisfatório já armazenado em cache.

Há uma pequena linha entre essa opção ser boa ou não para um determinado ambiente,
já que um plano pode ser realmente bom para várias queries e aí reduzir o número de compilações e consequentemente o tempo de CPU (e memória consumida) ou impactar várias das queries porque cada uma gosta de um plano específico tudo uma questão de Testar.

Boa sorte, uma reflexão por Jack Li;

"If things don’t work out, it’s easy to back it out. Over the course of troubleshooting performance issues, I have used this trick many times." Jack Li


Fique por dentro, e acompanhas essas e outras dicas aqui no blog.
Grande abraços a todos.

SQL SERVER - Dicas que todo DEV deveria conhecer part-3

    Nesta sequencia de tópicos abordaremos algumas dicas, que todo desenvolvedor deveria ter a oportunidade de conhecer. Todo desenvolvedor que programa em T/SQL, precisa estar atento a algumas "tips" do SQL Server em seu dia-a-dia na empresa.

Dicas part-1 Transaction Log
Dicas part-2 Variáveis ​​table e JOIN's & Criação de tabelas dentro de stored procedures

Part-3 Keywords que você deveria esquecer (ao menos evitar ao máximo) rs

SELECT * FROM – Evite asterisco, especifique as colunas necessárias, asterisco deve ser evitado pelo simples motivo de que é muito inútil retornar mais colunas do que o necessário, usando esse recurso. Pense no volume de dados, e aumento exponencial deste. Sendo retornados em toda chamada sem necessidade, é sobrecarregar a base de dados atoa. Outro problema é que, o interpretador SQL deve buscar no esquema da tabela as colunas que deveram de ser retornadas, antes de realizar a consulta propriamente dita.

IN – se você quer retornar os registros cujas condições são múltiplos identificadores, como todos os empregados cujos IDs sejam 1,3,7,45,100, você irá usar um IN, certo?


O problema aqui é que o IN é interpretado pelo motor de busca como uma junção de OR

Ou seja, WHERE ID IN (1,3,7,45,100)
é a mesma coisa que WHERE ID=1 OR ID=3 OR ID=7 OR ID=45 OR ID=100

Isto Não chega a ser um problema em uma consulta com poucas dezenas de valores no IN, mas tome cuidado quando você chega nas centenas deles. Já experimentamos outras abordagens com tabelas temporárias, tabelas em memória, entre outras, com resultados semelhantes. Por estes motivos muitos casos são mais eficientes tratamento na camada de aplicação e filtro, do que a sobrecarga no banco de dados fugindo do uso excessivo de IN.


Bônus: Dica rápida ...

Qual instrução é melhor para o desempenho - SELECT ou SET? SQL Server
Confere lá https://scriptsemsql.blogspot.com/2018/03/qual-e-melhor-para-o-desempenho-select.html

Fique por dentro, acompanhe essas e outras dicas aqui no blog.
Grande abraço.

SQL SERVER - Dicas que todo DEV deveria conhecer part-2

    Nesta sequencia de tópicos abordaremos algumas dicas, que todo desenvolvedor deveria ter a oportunidade de conhecer. Todo desenvolvedor que programa em T/SQL, precisa estar atento a algumas "tips" do SQL Server em seu dia-a-dia na empresa.

Part-2 Variáveis ​​table e JOIN's (DECLARE @table_variable_name TABLE)

Não use variáveis ​​de tabela em conjunto com JOIN. Use tabelas temporárias, CTEs (Common Table Expressions) em JOIN.


Embora as variáveis ​​table sejam muito rápidas e eficientes em muitas situações, o mecanismo do SQL Server a vê como uma única linha. Devido a isso, eles apresentam um desempenho horrível quando usados ​​em JOIN's. Tabelas temporárias apresentam melhor desempenho com JOIN's em comparação com as variáveis ​​da tabela.

Dica complementar: Criação de tabelas dentro de stored procedures? Cuidado!

Quando uma tabela é criada e utilizada dentro de uma mesma stored procedure, o otimizador não tem conhecimento das suas estatísticas, e assume que esta tabela tem 100 linhas e 10 páginas. Se a tabela criada é muito grande, esta suposição pode levar o otimizador a calcular um plano de acesso não otimizado / Errado. Para evitar este problema, crie a tabela em uma rotina anterior e utilize-a em outra.

Variáveis Locais ou Parâmetros na cláusula WHERE ? 

O otimizador não tem informações sobre o valor de uma variável, mas, em tempo de compilação, sabe o valor de um parâmetro. Isso posto, a utilização de parâmetros em cláusula where, leva o otimizador a produzir um plano de acesso mais eficiente.

mais recente, detalhamos esse hint no topico especifico: Dicas que todo DEV deveria conhecer
Parte 4 - Ad Hoc Queries (Forced Parameterization)

Exemplo sugestivo, observe que na primeira procedure

a Variavel @x recebe = b1 e logo em sequencia a variavel é passada como filtro WHERE b1 = @x
(O otimizador não tem informações sobre o valor de uma variável)

Na segunda procedure, em duas estapas: @x recebe = b1

Que é passado como parâmetro pra uma segunda procedure Exec s_p2 (@x) --solução
(Que força o otimizador a produzir um plano de acesso mais eficiente)

* Imagine no exemplo, uma tabela (t2) já criada anteriormente no escopo da procedure.

SQL SERVER - Dicas que todo DEV deveria conhecer part-1

    Nesta sequencia de tópicos abordaremos algumas dicas, que todo desenvolvedor deveria ter a oportunidade de conhecer. Todo desenvolvedor que programa em T/SQL, precisa estar atento a algumas "tips" do SQL Server em seu dia-a-dia na empresa.

Serão abordados diversos temas sequenciais, e depois da conclusão listaremos todos em um menu completo aqui.

Part-1 Transaction Log 
Part-2 Variáveis ​​table e JOIN's & Criação de tabelas dentro de stored procedures

Part-1 Transaction Log 

De modo simplista, todos imaginamos que quando executamos algum DML insert, update ou delete.
O SGBD registra em disco Transaction Log (faremos referencia com T-Log, daqui pra frente) para depois efetuar commit em mdf, certo?

Não - Errado.

Neste caminho simplificado, existe um camada de Log Buffer. Uma região em memoria responsável pelo buffer das informações, que somente apos check irá "commitar" esses dados em memoria para disco log. De maneira simplificada, esse é o WAIT mais comum relacionado ao T-Log.
Ele está relacionado ao tempo que SQL Server está esperando para escrever no disco.

Como podemos otimizar essa escrita ?

Nossa primeira Dica, neste tópico será a otimização do Transaction log, imaginem um loop de 10mil transações:

Já imaginou o trabalho que o SQL Server teria para abrir e fechar 10mil transações em loop?
Então imagine como seria muito mais simples, fazer tudo em uma única transação!

Padrão:

WHILE @id < 10000

   BEGIN

    INSERT INTO TABELA_TESTE VALUES(...)

   END

Melhoria:

BEGIN TRAN

   WHILE @id < 10000

   BEGIN

    INSERT INTO TABELA_TESTE VALUES(...)

   END

COMMIT

*

Por favor não confundam transaction begin tran  / while if begin de blocos de comando ok

Essa falha é muito comum em select into, update from também, onde indiferente da transação 

Já existiria um tratamento de erro no final If (@@Error > 0). O que torna totalmente adaptável o controle transacional no bloco de repetições.

No exemplo nosso tempo de execução baixou de forma considerável de mais de 2 minutos para 45 segundos! Ou seja, foi reduzido mais da metade do tempo! Essa melhora ocorreu por que o SQL Server processou as 10 mil inserções em uma única transação. Nem sempre é possível realizar essa otimização, mas ela pode ser uma boa solução.

Microsoft anuncia o SQL Server 2019 beta

Hoje, no Ignite, a Microsoft anunciou a prévia do SQL Server 2019 . Por 25 anos, o SQL Server ajudou as empresas a gerenciar todas as facetas de seus dados relacionais. Em versões recentes, o SQL Server foi além da consulta de dados relacionais, unificando dados relacionais e de gráficos e levando o aprendizado de máquina para onde os dados estão com o treinamento e a pontuação do modelo R e Python. À medida que o volume e a variedade de dados aumentam, os clientes precisam integrar e analisar facilmente os dados em todos os tipos de dados.

Agora, pela primeira vez, o SQL Server 2019 cria uma plataforma de dados unificada com o Apache Spark TM e o Hadoop Distributed File System (HDFS) junto com o SQL Server como uma solução única e integrada.Com a capacidade de criar clusters de big data, o SQL Server 2019 oferece uma incrível expansão dos recursos de gerenciamento de banco de dados, redefinindo ainda mais o SQL Server além de um banco de dados relacional tradicional. E, como em todas as versões, o SQL Server 2019 continua a ampliar os limites de segurança, disponibilidade e desempenho para cada carga de trabalho com o Intelligent Query Processing, ferramentas de conformidade de dados e suporte para memória persistente. Com o SQL Server 2019, você pode executar qualquer projeto de dados, desde cargas de trabalho tradicionais do SQL Server, como OLTP, Data Warehousing e BI, até IA e análise avançada em big data.

O SQL Server fornece uma verdadeira plataforma híbrida, com uma área de superfície consistente do SQL Server do data center para a nuvem pública, facilitando a execução no local de sua escolha. Como os clusters de big data do SQL Server 2019 são implantados como contêineres no Kubernetes com um serviço de gerenciamento integrado, os clientes podem obter uma experiência consistente de gerenciamento e implantação em uma variedade de plataformas suportadas no local e na nuvem: OpenShift ou Kubernetes local Serviço do Azure Kubernetes (AKS), Azure Stack (no AKS) e OpenShift no Azure. Com a portabilidade de licença do Azure Hybrid Benefit, você pode optar por executar cargas de trabalho do SQL Server no local ou no Azure, por uma fração do custo de qualquer outro provedor de nuvem.

SQL Server - Insights sobre todos os seus dados

O SQL Server continua a adotar o código aberto, desde o suporte do SQL Server 2017 para Linux e contêineres ao SQL Server 2019, agora abrangendo o Spark e o HDFS para oferecer uma plataforma de dados unificada. Com o SQL Server 2019, todos os componentes necessários para realizar análises sobre seus dados são incorporados em um cluster gerenciado, que é fácil de implantar e pode ser dimensionado de acordo com as necessidades do seu negócio. HDFS, Spark, Knox, Ranger, Livy, todos vêm empacotados junto com o SQL Server e são rapidamente e facilmente implantados como containers Linux no Kubernetes. O SQL Server simplifica o gerenciamento de todos os seus dados corporativos removendo quaisquer barreiras que existam atualmente entre dados estruturados e não estruturados.

Veja como podemos facilitar a eliminação de barreiras para a percepção de todos os seus dados, fornecendo uma visão dos seus dados em toda a organização:

• Simplifique a análise de big data para usuários do SQL Server. O SQL Server 2019 facilita o gerenciamento de ambientes de big data. Ele vem com tudo o que você precisa para criar um data lake, incluindo HDFS e Spark fornecidos pela Microsoft e ferramentas de análise, todos profundamente integrados ao SQL Server e totalmente suportados pela Microsoft. Agora, você pode executar aplicativos, análises e IA sobre dados estruturados e não estruturados - usando consultas T-SQL familiares ou pessoas familiarizadas com o Spark podem usar Python, R, Scala ou Java para executar tarefas do Spark para preparação ou análise de dados. o mesmo cluster integrado.
• Ofereça aos desenvolvedores, analistas de dados e engenheiros de dados uma única fonte para todos os seus dados - estruturados e não estruturados - usando suas ferramentas favoritas. Com o SQL Server 2019, os cientistas de dados podem analisar facilmente os dados no SQL Server e no HDFS por meio dos trabalhos do Spark. Os analistas podem executar análises avançadas sobre big data usando o SQL Server Machine Learning Services: treinar grandes conjuntos de dados no Hadoop e operacionalizar no SQL Server. Os cientistas de dados podem usar uma nova experiência de notebook em execução no mecanismo de notebooks Jupyter em uma nova extensão do Azure Data Studio para realizar interativamente análises avançadas de dados e compartilhar facilmente a análise com seus colegas.
• Divida os silos de dados e forneça uma visualização em todos os seus dados usando a virtualização de dados.A partir do SQL Server 2016, o PolyBase permitiu que você executasse uma consulta T-SQL dentro do SQL Server para extrair dados de seu lago de dados e retorná-los em um formato estruturado - tudo sem mover ou copiar os dados. Agora, no SQL Server 2019, estamos expandindo esse conceito de virtualização de dados para fontes de dados adicionais, incluindo Oracle, Teradata, MongoDB, PostgreSQL e outras. Usando o novo PolyBase, você pode dividir silos de dados e combinar facilmente dados de várias fontes usando a virtualização para evitar o tempo, esforço, riscos de segurança e dados duplicados criados pela movimentação e replicação de dados. Novos “pools de dados” e “pools de dados” elasticamente escalonáveis ​​tornam a consulta de dados virtualizados mais rápida, armazenando dados em cache e distribuindo a execução de consultas em muitas instâncias do SQL Server.

“Desde o início, o banco de dados do Sloan Digital Sky Survey foi executado no SQL Server e o SQL Server também armazena catálogos de objetos de grandes simulações cosmológicas.Estamos muito satisfeitos com a promessa dos clusters de big data do SQL Server 2019, o que nos permitirá aprimorar nossos bancos de dados para incluir todos os nossos grandes conjuntos de dados. A natureza distribuída do SQL Server 2019 nos permite expandir nossos esforços para novos tipos de simulações e para a próxima geração de pesquisas astronômicas com conjuntos de dados de até 10 PB ou mais, muito além dos limites de nossas soluções atuais de banco de dados. ”- Dr. Gerard Lemson Instituto de Engenharia Intensiva de Dados e Ciências, Universidade Johns Hopkins.

Melhor desempenho, segurança e disponibilidade

O mecanismo relacional do SQL Server 2019 fornecerá recursos novos e aprimorados nas áreas de desempenho de missão crítica, segurança e conformidade e disponibilidade do banco de dados, além de recursos adicionais para desenvolvedores, SQL Server no Linux e contêineres e aprimoramentos gerais do mecanismo.

Desempenho líder do setor - o banco de dados inteligente

• A família de recursos do Intelligent Query Processing se baseia em recursos de ajuste de desempenho sem uso de mãos do Processamento de Consulta Adaptável no SQL Server 2017, incluindo feedback de concessão de memória no modo Row, COUNT DISTINCT aproximado, modo Lote no rowstore e compilação adiada de variável de tabela.
• O suporte a memória persistente foi aprimorado nesta versão com um novo caminho de E / S otimizado disponível para interação com o armazenamento de memória persistente.
• A infra - estrutura de perfis de consulta Lightweight agora está habilitada por padrão para fornecer estatísticas do operador por consulta a qualquer momento e em qualquer lugar que você precisar.

Segurança Avançada - Computação Confidencial

• Sempre criptografado com enclaves seguros estende a tecnologia de criptografia do lado do cliente introduzida no SQL Server 2016. Os enclaves seguros protegem dados confidenciais em um enclave criado por hardware ou software dentro do banco de dados, protegendo-o contra malware e usuários privilegiados, permitindo operações avançadas em dados criptografados.
• A Descoberta e Classificação de Dados SQL agora está incorporada ao mecanismo do SQL Server com novos metadados e suporte de auditoria para ajudar no GDPR e em outras necessidades de conformidade.
• Agora, o gerenciamento de certificação é mais fácil usando o SQL Server Configuration Manager.

Disponibilidade de missão crítica - alto tempo de atividade

• Always On Availability Groups foram aprimorados para incluir o redirecionamento automático de conexões para o principal, com base na intenção de leitura / gravação.
• As configurações de alta disponibilidade para o SQL Server em execução em contêineres podem ser ativadas com Grupos de disponibilidade sempre ativos usando o Kubernetes.
• Índices online retomáveis agora suportam operações de criação e incluem padrões de escopo de banco de dados.

Experiência do desenvolvedor

• Os aprimoramentos no SQL Graph incluem suporte de correspondência com o T-SQL MERGE e restrições de borda.
• O novo suporte a UTF-8 oferece aos clientes a capacidade de reduzir o espaço de armazenamento do SQL Server para dados de caracteres.
• A nova extensão de linguagem Java permitirá que você chame um programa Java pré-compilado e execute com segurança o código Java no mesmo servidor com o SQL Server. Isso reduz a necessidade de mover dados e melhora o desempenho do aplicativo, aproximando suas cargas de trabalho de seus dados.
• O Machine Learning Services tem vários aprimoramentos, incluindo suporte a cluster de failover do Windows, modelos particionados e suporte para SQL Server no Linux.

Plataforma de escolha

• Recursos adicionais para o SQL Server no Linux incluem transações distribuídas, replicação, Polybase, Machine Learning Services, notificações de memória e suporte OpenLDAP.
• Os contêineres têm novos aprimoramentos, incluindo o uso do novo Microsoft Container Registry, com suporte para imagens RedHat Enterprise Linux e Always On Availability Groups para Kubernetes. 
  Você pode ler mais sobre o que há de novo no SQL Server 2019 em nossa documentação.

Suporte do SQL Server 2019 no Azure Data Studio

O suporte expandido para mais cargas de trabalho de dados no SQL Server requer ferramentas expandidas. Como a Microsoft trabalhou com usuários de sua plataforma de dados, vimos a união de personas anteriormente díspares: administradores de banco de dados, cientistas de dados, desenvolvedores de dados, analistas de dados e novas funções ainda em definição. Cada vez mais, esses usuários desejam usar as mesmas ferramentas para trabalhar juntos, sem interrupções, no local e na nuvem, usando dados relacionais e não estruturados, trabalhando com cargas de trabalho OLTP, ETL, analíticas e de fluxo contínuo.

O Azure Data Studio oferece uma experiência de editor moderna com IntelliSense ultrarrápido, trechos de código, integração de controle de origem e um terminal integrado. Ele é projetado com o usuário da plataforma de dados em mente, com gráficos integrados de conjuntos de resultados de consulta, um bloco de anotações integrado e painéis personalizáveis. O Azure Data Studio atualmente oferece suporte interno para o SQL Server no local e o Banco de Dados SQL do Azure, além do suporte de visualização para a Instância Gerenciada do Azure SQL e o Azure SQL Data Warehouse.

O Azure Data Studio está enviando uma nova extensão de visualização do SQL Server 2019 para adicionar suporte a alguns recursos do SQL Server 2019. A extensão oferece conectividade e ferramentas para clusters de big data do SQL Server, incluindo uma prévia da primeira experiência de notebook no conjunto de ferramentas do SQL Server e um novo assistente PolyBase Create External Table que facilita o acesso a dados de instâncias remotas do SQL Server e do Oracle .

Começando

Encontre recursos adicionais e comece hoje mesmo visitando os links abaixo:

• Visualize o SQL Server 2019 para Windows, Linux ou Docker.
• Inscreva-se no Early Adoption Program para obter orientação e suporte para o seu projeto a partir da engenharia do SQL Server ou para experimentar clusters de big data do SQL Server 2019.
• Faça o download do Azure Data Studio para começar a usar os novos recursos de big data do SQL Server, como virtualizações de dados e notebooks.

Por: 

ASAD KHAN

Principal PM Manager, SQL Server