BigQuery - Inserindo 1 milhão de registros em segundos (Google Cloud Plataform).

    Neste estudo de caso do blog, demonstraremos o INSERT de arquivos JSON em Tabelas BigQuery.

Milhões de registros (direto de arquivos físicos heim, acredite rs) em questões de Segundos;

Existem outros cenários, de maior preformance que abordaremos nos proximos post; como exemplos Datasets públicos sendo migrados e copiados em décimos de segundo...

• NYC Taxi Fares +/- 36 milhoes de registros disponiveis de tarifas dos taxis americanos (bigquery-public-data.new_york_taxi_trips.tlc_yellow_trips_2022)

• Wikipedia the massive database; como eles mesmo se apresentam "Um gigantesco" Database, que inclui dados de tráfego de cada página da Wikipedia (bigquery-public-data.wikipedia.pageviews_2023)

*  FILTRO / (Partition elimination) Aproximadamente 4,4 bilhoes de registros; em Um (1) Unico mês, 30 Dias rs;

** Cuidado: LEMBRAMOS  QUE  CONSUMO (QUERY) ACIMA DE 1 TB (um terabyte) MÊS / SERÁ COBRADO ADICIONAL; FIQUE ATENTO, rs ...

Para a preparação, vamos criar um arquivo de texto com 1 milhão de linhas em formato JSON, utilizando um script automático em Python.

Primeira Etapa 1)

Faremos uma abordagem mais simples: ler o arquivo de texto/JSON linha por linha e inserir na mesma tabela do BigQuery, uma de cada vez. Segundo a documentação do BigQuery Streaming Insert, é possível inserir várias linhas em uma única chamada da API.

https://cloud.google.com/bigquery/docs/streaming-data-into-bigquery

Neste diagrama, existem três componentes principais:

1. File Reader: Realiza a leitura simples de arquivos de texto, encaminhando o conteúdo (linhas) para o Canal.

2. Canal (c1 e c2): Responsável por compartilhar os dados em formato de cadeia de caracteres de texto. Ele prepara e envia o buffer de strings.

3. Work: Responsável por inserir os dados em uma tabela do BigQuery.

Channel é uma estrutura nativa da linguagem Go, utilizada para comunicar e sincronizar co-rotinas (goroutines).
Eu gosto de assimilar o conceito de channel a threads da CPU, embora não sejam gerenciadas pelo sistema operacional. Eles não bloqueiam nem interferem nas threads do sistema operacional, tornando a execução mais eficiente.

Os canais são bi-direcionais, permitindo a passagem de dados. Quando concluído, o conteúdo segue através do pipe para o Worker.

Para a terceira e última etapa, utilizaremos a goroutine do Go. O Go permite a sincronização de milhares ou até milhões de goroutines em execução paralela. Essas execuções simultâneas são significativamente mais rápidas do que outras formas de agendamento, já que as goroutines são muito leves (cerca de 2 KB de stack cada, podendo crescer conforme necessário).

Para decidir o número máximo de buffers e workers, é importante entender as cotas e os limites da API BigQuery Streaming, conforme descrito na documentação:

Cotas e limites  |  BigQuery  |  Google Cloud

 

Usando a configuração mais alta

Conseguimos inserir (1) um milhão de linhas em apenas 14 segundos!

Conclusão

Neste caso de teste do blog, aprendemos a aplicar os conceitos de simultaneidade e goroutines para fazer com que nossos "Jobs" (INSERT) aproveitem ao máximo os recursos da tecnologia BigQuery, executando tarefas simultâneas de forma incrivelmente mais rápida.

Evidências:

Performance extrema, com DynamoDB (DAX) Accelerator

 O Amazon DynamoDB foi concebido para escala e performance. Na maioria dos casos, os tempos de resposta do DynamoDB podem ser medidos em milissegundos de um dígito. No entanto, existem certos casos de uso que exigem tempos de resposta em microssegundos. Para esses casos de uso, o DynamoDB Accelerator (DAX) oferece tempos de resposta rápidos para acessar dados finais consistentes.

O DAX é um serviço de armazenamento em cache compatível com o DynamoDB no qual você pode se beneficiar da rápida performance em memória para aplicações exigentes. O DAX lida com três cenários principais:

1. Como um cache na memória, o DAX reduz os tempos de resposta de workloads de leitura final consistente por uma ordem de magnitude que varia de milissegundos de um único dígito até microssegundos.

2. O DAX reduz a complexidade operacional e da aplicação fornecendo um serviço gerenciado que é compatível com a API do DynamoDB. Portanto, ele exige apenas alterações funcionais mínimas para uso com um aplicativo existente.

3. Para workloads de leitura intermitentes ou pesadas, o DAX fornece throughput mais alto e economia potencial de custos operacionais reduzindo a necessidade de provisionar unidades de capacidade de leitura em excesso. Isso é especialmente benéfico para aplicativos que exigem leituras repetidas para chaves individuais.

O DAX é compatível com a criptografia do lado do servidor. Com a criptografia em repouso, os dados persistentes pelo DAX no disco serão criptografados. O DAX grava dados ao disco como parte das alterações de propagação do nó primário para as réplicas de leitura. 

O DAX também oferece suporte à criptografia em trânsito, garantindo que todas as solicitações e respostas entre a aplicação e o cluster sejam criptografadas por TLS (Transport Level Security) e que as conexões com o cluster possam ser autenticadas pela verificação de um certificado de cluster. .

O DAX dá acesso a dados finais consistentes de tabelas do DynamoDB, com latência de microssegundos. Um cluster do DAX multi-AZ pode servir milhões de solicitações por segundo.

O DAX é ideal para os seguintes tipos de aplicações:

• Aplicativos que exigem o melhor tempo de resposta possível para leituras. Alguns exemplos incluem lances em tempo real, jogos sociais e aplicações de negócios. O DAX oferece uma performance de leitura rápida na memória para esses casos de uso.

• Aplicativos que fazem a leitura de um pequeno número de itens com mais frequência do que outros. Por exemplo, considere um sistema de comércio eletrônico que tem uma promoção de um produto popular válida por apenas um dia. Durante a promoção, a demanda por esse produto (e seus dados no DynamoDB) aumentaria drasticamente em comparação a todos os outros produtos. Para mitigar os impactos de uma chave de "aceleração" e uma distribuição de tráfego não uniforme, você pode descarregar as atividades de leitura em um cache do DAX até que essa promoção de um dia acabe.

• Aplicativos que exigem leitura intensa, mas que também são sensíveis aos custos. Com o DynamoDB, você fornece o número de leituras por segundo que a sua aplicação exige. Se as atividades de leitura aumentarem, você poderá aumentar o throughput de leitura provisionado das suas tabelas (a um custo adicional). Como alternativa, é possível descarregar as atividades da sua aplicação em um cluster do DAX e reduzir a quantidade de unidades de capacidade de leitura que você precisa comprar.

• Aplicativos que exigem leituras repetidas em um grande conjunto de dados. Esses aplicativos poderiam desviar os recursos de banco de dados de outros aplicativos. Por exemplo, uma análise de longa execução de dados meteorológicos regionais pode consumir toda a capacidade de leitura em uma tabela do DynamoDB. Essa situação pode afetar negativamente outros aplicativos que precisam acessar os mesmos dados. Com o DAX, a análise meteorológica pode ser realizada com base nos dados em cache.

O DAX não é ideal para os seguintes tipos de aplicação:

• Aplicativos que exigem leituras fortemente consistentes (ou que não toleram leituras eventualmente consistentes).

• Aplicativos que não precisam de tempos de resposta em microssegundos para leituras ou descarregar atividades de leitura repetidas de tabelas subjacentes.

• Aplicações que exigem alto volume de gravações. O alto volume de gravações leva ao aumento da replicação entre nós do DAX em um cluster. Isso causa um aumento no consumo de recursos e no risco de problemas de disponibilidade.

• Aplicações sem muitas leituras repetidas. O DAX tem melhor desempenho quando as taxas de acertos de cache excedem 90%. Taxas de acertos de cache mais baixas aumentam as perdas no cache, o que consome mais recursos em todo o cluster do DAX.

ADR - Recuperação acelerada no SQL Server 2022 (Evolução)

       Basicamente, a Recuperação Acelerada de Banco de Dados é um recurso revolucionário do SQL Server que aumenta drasticamente a disponibilidade do banco de dados. É uma virada de jogo em situações em que transações de longa duração estão envolvidas, pois revisa totalmente o processo de recuperação do mecanismo de banco de dados SQL. Os principais benefícios do ADR 2022 incluem recuperação rápida e consistente de banco de dados, reversão imediata de transações e truncamento agressivo de log.

O novo e aprimorado ADR no SQL Server 2022

O SQL Server 2022 introduz diversas melhorias no ADR, projetadas especificamente para enfrentar desafios de armazenamento persistente (PVS) e aprimorar a escalabilidade geral.

Limpeza de transações do usuário: uma abordagem mais eficiente

O processo de limpeza do ADR no SQL Server 2022 foi aprimorado ao permitir que as transações do usuário limpem páginas que o processo regular que não poderiam tratar devido a conflitos no bloqueio no nível da tabela. Isso garante que o processo de limpeza de ADR não fique mais paralisado indefinidamente devido a problemas de aquisição de bloqueio, aumentando assim a eficácia e eficiência geral do sistema.

Armazenamento de versão persistente em nível de transação (PVS)

Este novo recurso permite que o ADR limpe versões vinculadas a transações confirmadas, independentemente de o sistema ter cancelado transações. O resultado é que as páginas PVS podem ser desalocadas mesmo que a limpeza não conclua uma varredura bem-sucedida. Isso reduz o crescimento do PVS mesmo se a limpeza do ADR atrasar ou falhar.

Limpeza de versão multithread: poder em números

O SQL Server 2022 introduziu a limpeza de versão multithread, que permite que vários bancos de dados na mesma instância do SQL Server sejam limpos simultaneamente. Esse aprimoramento é particularmente benéfico ao lidar com vários bancos de dados grandes. O número de threads usados ​​para limpeza de versão pode ser ajustado para escalabilidade com  sp_configure.

EXEC sp_configure 'ADR Cleaner Thread Count', '8'
RECONFIGURE WITH OVERRIDE;

Para concluir

As melhorias na Recuperação Acelerada de Banco de Dados no SQL Server 2022 oferecem benefícios substanciais para administradores e desenvolvedores de banco de dados. Eles melhoram a velocidade e a eficiência dos processos de recuperação de banco de dados, reduzem o consumo de memória e melhoram a eficiência de limpeza. À medida que o SQL Server continua a evoluir, podemos antecipar melhorias adicionais no ADR e em outros recursos que continuarão a refinar o desempenho, a recuperação e o gerenciamento do banco de dados. 

SQL Server - Apresentando WAIT_AT_LOW_PRIORITY

Os administradores de banco de dados geralmente têm a tarefa de gerenciar o tamanho de um banco de dados SQL Server. O comando DBCC SHRINKDATABASE é uma ferramenta poderosa em seu arsenal, permitindo reduzir o tamanho físico dos dados e arquivos de log no banco de dados especificado. No entanto, como acontece com todas as ferramentas poderosas, deve ser usado criteriosamente para evitar potenciais problemas de desempenho. Nesta postagem do blog, exploraremos o comando DBCC SHRINKDATABASE e suas opções, com foco no recurso WAIT_AT_LOW_PRIORITY introduzido no SQL Server 2022 e versões posteriores.

Compreendendo o DBCC SHRINKDATABASE

O comando DBCC SHRINKDATABASE ajuda a reduzir o tamanho dos dados e os arquivos de log em um banco de dados especificado. Ele usa o nome ou ID do banco de dados como argumento, com uma porcentagem alvo opcional que denota o espaço livre que você gostaria de manter no arquivo de banco de dados após ele ter sido reduzido.

O comando também fornece duas opções especiais: NOTRUNCATE e TRUNCATEONLY. A opção NOTRUNCATE move as páginas atribuídas do final do arquivo para páginas não atribuídas na frente do arquivo, compactando efetivamente os dados dentro do arquivo, mas não liberando o espaço livre no final de volta para o sistema operacional. Por outro lado, a opção TRUNCATEONLY libera todo o espaço livre no final do arquivo para o sistema operacional sem mover nenhuma página do arquivo.

Apresentando WAIT_AT_LOW_PRIORITY

A opção WAIT_AT_LOW_PRIORITY é um recurso que pode ser usado junto com o comando DBCC SHRINKDATABASE para gerenciar a contenção de bloqueio de forma mais eficaz. Esse recurso é especialmente útil quando uma operação de redução precisa adquirir um bloqueio de modificação de esquema (Sch-M), que muitas vezes pode causar bloqueio significativo no banco de dados.

Quando um comando de redução é executado no modo WAIT_AT_LOW_PRIORITY, novas consultas que exigem bloqueios de estabilidade de esquema (Sch-S) não são bloqueadas pela operação de redução em espera até que a operação de redução pare de esperar e comece a ser executada. Se uma nova operação de redução no modo WAIT_AT_LOW_PRIORITY não puder obter um bloqueio devido a uma consulta de longa execução, a operação de redução eventualmente atingirá o tempo limite após 1 minuto por padrão e será encerrada sem erros.

A opção WAIT_AT_LOW_PRIORITY assume dois valores possíveis para o argumento ABORT_AFTER_WAIT: SELF e BLOCKERS. A opção SELF é o padrão e permite que a operação de redução saia sem realizar nenhuma ação se estiver sendo bloqueada. A opção BLOCKERS, por outro lado, elimina todas as transações do usuário que estão bloqueando a operação de redução, permitindo que ela continue.

DBCC SHRINKDATABASE (Database, 100) 
WITH WAIT_AT_LOW_PRIORITY (ABORT_AFTER_WAIT = BLOCKERS);

Considerações finais

Gerenciar o tamanho de um banco de dados SQL Server é uma parte essencial do trabalho de um administrador de banco de dados. DBCC SHRINKDATABASE, quando usado criteriosamente, pode ajudar a gerenciar o tamanho físico do banco de dados de maneira eficaz. A opção WAIT_AT_LOW_PRIORITY aprimora ainda mais isso, gerenciando a contenção de bloqueio de maneira eficaz e garantindo que as operações de redução do banco de dados não bloqueiem desnecessariamente outras consultas.

No entanto, também é importante notar que a redução e o crescimento constantes do banco de dados podem levar à fragmentação e impactar negativamente o desempenho. Portanto, é essencial ter uma estratégia bem pensada para gerenciar o tamanho do banco de dados, e ferramentas como DBCC SHRINKDATABASE devem fazer parte dessa estratégia, e não de toda a estratégia.

SQL SERVER 2014 – Estatísticas incrementais

SQL SERVER – Noções básicas sobre estatísticas incrementais

As estatísticas são essenciais para que o otimizador de consultas do SQL Server gere planos de execução eficientes. Estatísticas desatualizadas podem levar a um desempenho insatisfatório da consulta. Tradicionalmente, as estatísticas são atualizadas automaticamente ou reconstruídas manualmente usando verificações completas, o que pode consumir muitos recursos para tabelas grandes. O SQL Server 2014 introduziu um novo recurso chamado estatísticas incrementais para fornecer gerenciamento de estatísticas mais eficiente.

O que são estatísticas incrementais?

Com as estatísticas incrementais habilitadas, o SQL Server rastreia as alterações nos dados e atualiza apenas os subconjuntos de estatísticas impactados em vez de reconstruir as estatísticas completas. Isso significa atualizações menores e mais frequentes focadas nos dados alterados.

Alguns pontos-chave:

• Disponível apenas para SQL Server 2014 e versões mais recentes.
• Habilitado no nível de índice ou estatística usando a opção STATISTICS_INCREMENTAL = ON .
• Mais adequado para tabelas grandes com alterações frequentes de dados em subconjuntos pequenos.
• Pode reduzir o uso de recursos de manutenção de estatísticas enquanto mantém as estatísticas mais atualizadas.
• A  STATISTICS_NORECOMPUTE configuração substitui e desativa estatísticas incrementais.

Como funcionam as estatísticas incrementais?

As estatísticas incrementais dividem os dados em partições e mantêm estatísticas em cada partição. À medida que os dados mudam, apenas as partições afetadas são atualizadas. Alguns exemplos de alterações de dados que acionam atualizações incrementais de estatísticas:

• Instruções INSERT, UPDATE, DELETE ou MERGE que modificam dados dentro da tabela
• Operações de inserção em massa usando  BULK INSERT ou OPENROWSET(BULK...)

O SQL Server determina quais partições foram afetadas usando bitmaps de rastreamento e atualiza apenas as estatísticas dessas partições.

Nos bastidores, as estatísticas incrementais são implementadas como um objeto de estatísticas com várias partes. O cabeçalho contém estatísticas de resumo global para toda a tabela. Cada partição possui seu próprio subconjunto de estatísticas.

Gerenciando estatísticas incrementais

Para ativar estatísticas incrementais em um objeto de índice ou estatísticas:

CREATE STATISTICS stats_name ON table_name(column)

WITH INCREMENTAL = ON;

CREATE INDEX index_name ON table_name(column)

WITH (STATISTICS_INCREMENTAL = ON);

Esse recurso é habilitado por padrão ao criar estatísticas em uma tabela com otimização de memória. Para desativar estatísticas incrementais, defina  STATISTICS_INCREMENTAL = OFF. Isso reconstruirá as estatísticas como estatísticas não incrementais de verificação completa.

UseUPDATE STATISTICSpara reconstruir manualmente estatísticas incrementais sob demanda. Esses incrementos alteraram as partições e deixaram as partições inalteradas, diferentemente da verificação completa.

Verifique as  _STATS_DATE colunas  sys.indexes e  sys.stats veja quando as estatísticas foram atualizadas pela última vez.

Dicas para usar estatísticas

• Teste seu ambiente de homologaçao e seus dados para ver se as estatísticas incrementais melhoram o desempenho em relação às estatísticas de verificação completa.
• Considere ativar tabelas grandes com padrões de partição claros, como intervalos de datas.
• Esteja ciente de que as estatísticas incrementais requerem mais espaço em disco do que as estatísticas típicas.
• Monitore para garantir que as estatísticas incrementais sejam atualizadas conforme esperado.
• Desative remova dos fontesSTATISTICS_NORECOMPUTE para que as estatísticas incrementais funcionem corretamente.

Espero que esta visão geral ajude a explicar como você pode aproveitar esse recurso no SQL Server! Qualquer duvida estamos a disposição. Sucesso

Novas mudanças no Controle de Certificações Microsoft - Microsoft Learn

Olá Pessoal, atenção com as mudanças no Controle de Certificações Microsoft.

Algumas semanas atrás, anunciamos atualizações para a experiência do perfil do Microsoft Learn que permite que você verifique, rastreie e compartilhe seu progresso e realizações de treinamento e certificação — tudo em uma plataforma . Hoje, temos o prazer de informar que esses novos recursos já estão ativos e prontos para você. Comece a usar essas ferramentas para ajudar a gerenciar seu aprendizado e compartilhar seu sucesso. Observe que a parceria da Credly foi desativada A parceria do programa de certificações da Microsoft com a Credly foi desativada em 30 de junho de 2023 e a Credly não está mais emitindo crachás para as certificações da Microsoft. Aqui está o que isso significa para você: Todas as suas certificações estão em seu perfil do Microsoft Learn e serão atualizadas com informações pertinentes, incluindo datas de expiração e renovação. Os crachás de Certificação Microsoft que você reivindicou anteriormente no Credly continuarão disponíveis em seu perfil Credly até 30 de junho de 2024. As datas de expiração e renovação desses crachás não serão mais atualizadas.

Aproveite ao máximo os novos recursos em seu perfil do Microsoft Learn

Certifique-se de alinhar seu perfil do Microsoft Learn com seu perfil de certificação . Isso ajuda a garantir acesso fácil a todas as informações e atividades de aprendizado. Depois de conectar seus perfis, acesse seu perfil do Microsoft Learn para:

• Compartilhe e verifique suas Certificações Microsoft por e-mail, no LinkedIn e em outras plataformas de redes sociais. Você também pode atualizar seu currículo com um link para sua certificação obtida verificada pela Microsoft.
• Verifique as datas de expiração da certificação e a elegibilidade para renovação.
• Baixe e imprima transcrições e certificados.
• Gerencie suas próximas atividades e compromissos de exames de certificação.

Oracle Cloud Infrastructure 2023 Certified Foundations Associate

    

 Concluí com sucesso o programa 'Oracle Cloud Infrastructure 2023 (1Z0-1085-23)' e recebi meu certificado e crachá! O conteúdo é muito bem detalhado e agradeço pelo conhecimento que adquiri nas tecnologias oracle-cloud ☁️, habilidades em provisionamento, segurança, rede e armazenamento dentro do Oracle Cloud Infrastructure. Um alô ao Oracle Cloud por esta oportunidade ~ de graça rs!

I've successfully completed the 'Oracle Cloud Infrastructure 2023 (1Z0-1085-23)' program and received my certificate and badge! The content is very well detailed, and I grateful for the knowledge I've gained in oracle-cloud technologies ☁️,  skills in provisioning, security, networking, and storage within Oracle Cloud Infrastructure. A shoutout to Oracle Cloud for this opportunity ~ for free rs!

#OracleCertified #1Z0-1085-23

#CloudInfrastructure #CloudTechnologies

https://catalog-education.oracle.com/pls/certview/sharebadge?id=E1CD68018AB425945F4E1E00DB3009432EDE8D7604BF1233971DF50D40460EA4

O Azure AD está se tornando Microsoft "Entra ID"

 Microsoft Entra ID é o novo nome do Azure Active Directory (Azure AD). Nenhuma ação é exigida de você.

A mudança de nome para Microsoft Entra ID representa a evolução e a unificação da família de produtos Microsoft Entra e um compromisso de simplificar as experiências de acesso seguro para todos.

Nenhuma alteração nos recursos, licenciamento ou preços 

Os recursos e funcionalidades do Azure AD continuarão disponíveis no Microsoft Entra ID. Preços, termos e acordos de nível de serviço também permanecem os mesmos. Para tornar a transição perfeita para você, as URLs, APIs e bibliotecas de autenticação do Azure AD permanecem as mesmas, assim como as experiências do desenvolvedor.

Momento da mudança de nome

A mudança de nome será implementada em todos os produtos e experiências da Microsoft durante o segundo semestre de 2023 . Os clientes que têm acesso ao Azure AD continuarão a ter acesso sem interrupções planejadas.

Saiba mais no blog oficial de lançamento:

• Leia os últimos anúncios do Microsoft Entra ID

Impacto da Alteração do Nível de Compatibilidade no Cache - SQL Server

        No mundo do SQL Server, o nível de compatibilidade do banco de dados desempenha um papel vital na determinação de como um banco de dados se comporta quando se trata de executar consultas e otimizar planos de execução. O SQL Server se esforça constantemente para melhorar o desempenho e a otimização de consultas, adotando novos algoritmos e aprimoramentos a cada novo lançamento. Como resultado, alterar o nível de compatibilidade torna-se necessário para aproveitar os recursos e melhorias mais recentes. Nesta postagem do blog, exploraremos como a alteração do nível de compatibilidade afeta o cache de consulta e por que é essencial estar ciente de seu impacto. 

Compreendendo o cache de consulta

      Antes de aprofundar nos efeitos da alteração do nível de compatibilidade, vamos discutir brevemente o cache de consulta no SQL Server. O cache de consulta, também conhecido como cache de plano, armazena os planos de execução gerados pelo otimizador de consulta do SQL Server. Quando uma consulta é executada, o SQL Server primeiro verifica o cache para ver se existe um plano de execução para essa consulta específica. Se encontrado, o plano em cache é usado, economizando a sobrecarga de gerar um novo plano. Isso melhora significativamente o desempenho da consulta e reduz o tempo de processamento da consulta.

Verificando o status do cache: 

-- Check the buffer cache usage
SELECT
    COUNT(*) AS CachedPagesCount,
    COUNT(*) * 8 / 1024 AS CachedSizeMB
FROM sys.dm_os_buffer_descriptors
WHERE database_id = DB_ID();
GO
-- Check the plan cache usage
SELECT
    objtype AS CacheObjectType,
    COUNT(*) AS CachedPlansCount,
    SUM(size_in_bytes) / 1024 AS CachedSizeKB
FROM sys.dm_exec_cached_plans
GROUP BY objtype;
GO
-- Check the procedure cache usage
SELECT
    cacheobjtype AS CacheObjectType,
    COUNT(*) AS CachedObjectsCount
FROM sys.dm_exec_cached_plans
GROUP BY cacheobjtype;
GO

-- For SQL Server 2008:
ALTER DATABASE [Banco_Homolog] SET COMPATIBILITY_LEVEL = 100;

Aqui, 100 significa SQL Server 2008. Se você deseja alterar o nível de compatibilidade para SQL Server 2022, pode usar 160 em vez de 100. Da mesma forma, pode usar 140 para SQL Server 2017.

Depois de alterar o nível de compatibilidade e verificar o cache de consulta novamente, 
você verá que ele está quase vazio.


Em conclusão, o nível de compatibilidade de um banco de dados SQL Server desempenha um papel crucial na determinação do comportamento e desempenho da otimização de consulta. Alterar o nível de compatibilidade pode influenciar os planos de execução em cache e, por sua vez, afetar o desempenho geral da consulta. Como parte da verificação abrangente de integridade do desempenho do banco de dados , sempre considero o nível de compatibilidade do banco de dados para garantir que os clientes aproveitem todo o potencial de seus bancos de dados SQL Server.

referencias Pinal Dave: comprehensive-database-performance-health-check

Grande abraços 
Gustavo Damatto
MCSD - Microsoft Certified Solutions Developer

linkedin.com/in/damatto
Ribeirão Preto-SP

Lançamento - Microsoft SQL Server 2022

  

Lançado oficialmente em novembro,  durante o evento anual Microsoft  Ignite  foi anunciado o grande lançamento do SQL Server 2022, a mais nova versão do principal banco de dados da Microsoft.

" Hoje estamos anunciando a prévia do SQL Server 2022, a versão mais integrada do SQL Server com Azure disponível, com inovação contínua em desempenho, segurança e disponibilidade." - Peter Carin CVP da Microsoft

O SQL Server 2022 se integra ao Azure Synapse Link e ao Azure Purview para permitir que os clientes obtenham insights, previsões e governança mais profundas a partir de seus dados em escala. A integração da nuvem é aprimorada com recuperação de desastres (DR) para a instância gerenciada do Azure SQL, junto com conexões sem ETL (extrair, transformar e carregar) para análise de nuvem, que permite que os administradores de banco de dados gerenciem suas propriedades de dados com maior flexibilidade e impacto mínimo para o usuário final. O desempenho e a escalabilidade são aprimorados automaticamente por meio de inteligência de consulta integrada. Há opções e flexibilidade entre linguagens e plataformas, incluindo Linux, Windows e Kubernetes.

Habilitado para Azure

HA/DR bidirecional para Azure SQL

Para garantir o tempo de atividade, o SQL Server 2022 está totalmente integrado ao novo recurso de link na instância gerenciada do Azure SQL. Com o novo recurso de link para a instância gerenciada SQL do Azure, agora você obtém todos os benefícios de executar um ambiente PaaS aplicado à recuperação de desastres - permitindo que você gaste menos tempo na configuração e gerenciamento, mesmo quando comparado a um ambiente IaaS. Isso funciona usando um Grupo de Disponibilidade Distribuída (DAG) interno para replicar dados para uma Instância Gerenciada SQL do Azure previamente implantada como um site de réplica de DR. A instância está pronta e esperando sempre que você precisar - nenhuma configuração ou manutenção demorada é necessária. Você também pode usar este recurso de link em cenários de escalabilidade horizontal de leitura para descarregar solicitações pesadas que podem afetar o desempenho do banco de dados. E estamos trabalhando para desenvolver mais recursos para dar suporte à movimentação bidirecional de dados.

Link de sinapse do Azure

Anteriormente, mover dados de bancos de dados locais, como SQL Server, para o Synapse exigia o uso de ETL. Como todos sabemos, configurar e executar um pipeline de ETL dá muito trabalho e os insights ficam para trás em relação ao que está acontecendo a qualquer momento. O Azure Synapse Link para SQL Server 2022 fornece feeds de alteração automática que capturam as alterações no SQL Server e as alimentam no Azure Synapse Analytics. Ele fornece análise quase em tempo real e processamento transacional e analítico híbrido com impacto mínimo nos sistemas operacionais. Depois que os dados chegam ao Synapse, você pode combiná-los com muitas fontes de dados diferentes, independentemente de seu tamanho, escala ou formato e executar análises poderosas sobre tudo isso usando sua escolha de Azure Machine Learning, Spark ou Power BI. Uma vez que os feeds de mudança automatizados apenas empurram o que é novo ou diferente,

Integração do Azure Purview

Recentemente, anunciamos a disponibilidade geral do Azure Purview como um serviço unificado de governança e gerenciamento de dados. Estamos empolgados em destacar que o SQL Server também está integrado ao Azure Purview para maior descoberta de dados, permitindo que você divida os silos de dados. Por meio dessa integração, você será capaz de:

• Verifique automaticamente seu SQL Server local gratuitamente para capturar metadados.
• Classifique os dados usando classificadores integrados e personalizados e rótulos de sensibilidade da Proteção de Informações da Microsoft.
• Configure e controle direitos de acesso específicos ao SQL Server.

Aprimoramentos de desempenho, segurança e disponibilidade

atuação

O SQL Server oferece desempenho diferenciado, com desempenho OLTP número um 1 e desempenho DW não agrupado número um em 1 TB 2 , 3 TB 3 , 10 TB 4 e 30 TB 5, de acordo com o Transaction Processing Performance Council independente. A inteligência de consulta integrada na inovação do SQL Server 2022 inclui:

• Para Query Store, estamos adicionando suporte para réplicas de leitura e permitindo dicas de consulta para melhorar o desempenho e mitigar problemas rapidamente sem ter que alterar a fonte T-SQL.
• Para o Intelligent Query Processing, estamos expandindo mais cenários com base em problemas comuns do cliente. Por exemplo, o problema do “plano sensível a parâmetros” se refere a um cenário em que um único plano em cache para uma consulta parametrizada não é ideal para todos os valores de parâmetros de entrada possíveis. Com o recurso de otimização Parameter Sensitive Plan do SQL Server 2022, habilitamos automaticamente a geração de vários planos ativos em cache para uma única instrução parametrizada. Esses planos de execução em cache irão acomodar diferentes tamanhos de dados com base nos valores de parâmetro de tempo de execução fornecidos.

Segurança

Nos últimos dez anos, o SQL Server teve menos vulnerabilidades do que a concorrência. 6 Com base nisso, o novo recurso de razão cria um registro de controle imutável de modificações de dados ao longo do tempo. Isso protege os dados contra adulteração por agentes mal-intencionados e é benéfico para cenários como auditorias internas e externas.

Disponibilidade

Com a mudança para uma distribuição mais global de funcionários e clientes, muitas organizações estão mudando para um ambiente de multi-gravação que permite que mudanças sejam feitas no banco de dados local e enviadas para outras réplicas em um fluxo bidirecional de atualizações. No entanto, se várias pessoas alterarem a mesma linha no banco de dados e as diferentes réplicas de gravação contiverem informações diferentes, anteriormente esse conflito de réplica ponto a ponto paralisaria toda a operação até que fosse resolvido. Com o SQL Server 2022, estamos automatizando a regra do último gravador vence. Agora, quando um conflito for detectado, a hora da modificação mais recente será escolhida para persistir em todas as réplicas. Isso ajuda a manter seus cenários de exibição múltipla funcionando sem problemas.

saiba mais

Saiba mais sobre o lançamento do SQL Server 2022 na  página da Web  e assistindo a sessões de aprofundamento no  Microsoft Ignite  , com o  Microsoft Mechanics  e no próximo  PASS Data Community Summit  virtual gratuito .

Grande abraços 

Gustavo Damatto - dba