SQL Server Tips

Encontre aqui dicas de SQL Server para seu dia-a-dia

  • Workshop Serverless no Azure

    Olá pessoal, no último dia 18/03/2023, participei junto com o Renato Groffe do evento Workshop Serverless no Azure, e eu falei sobre as opções para Data Platform.

    O evento foi realizado na universidade UniMetrocamp e teve um total de 45 participantes.

    Organizadores:

    • João Ronaldo Cunha (UniMetrocamp)
    • Renato Groffe (Microsoft MVP, MTAC)

    Palestrantes:

    • Renato Groffe (Microsoft MVP, MTAC)
    • Roberto Fonseca (Microsoft MVP, MTAC)

    Abordamos as seguintes tecnologias, Azure SQL Database, SQL Managed Instances, Azure Cosmos DB e Azure Data Factory. Tivemos um total de 45 participantes numa manhã de muito conhecimento compartilhado!

  • Participe do SQL Server – CAMPINAS

    Olá! Quer fazer parte do grupo de SQL Server para a região metropolitana de Campinas – SP?

    Nosso objetivo é reunir o máximo de profissionais de bancos de dados interessados em compatilhar conhecimento sobre bancos de dados e computação em nuvem.

    Por enquanto estamos apenas realizando eventos online, mas em breve, reiniciaremos também com os eventos presenciais!

    Inscreva-se e seja o primeiro a ser informado!

  • .NET Conf 2023

    No último dia 21/01/2023 fui convidado pelo Renato Groffe, MVP de .NET para participar do evento .NET Conf 2023, realizado no auditório da Venturus. Esse é mais um evento gratuito organizado por ele e me sinto honrado em participar.

    Número de participantes: 85 pessoas

    Apresentações que aconteceram durante o evento:

    • Keynote – .NET Conf novamente em Campinas-SP – Ericson da Fonseca (Microsoft MVP)
    • Observabilidade em .NET – Se sua aplicação cair, quem descobre primeiro? Você ou seus clientes? – Matheus Barros (DevPira)
    • .NET 7, Azure e o Meio Ambiente – Murilo Beltrame (DevPira)
    • SQL Server High Availability and Disaster Recovery – Roberto Fonseca (Microsoft MVP, MTAC)
    • .NET 7 + ASP.NET Core: principais novidades no desenvolvimento Back-End – Renato Groffe (Microsoft MVP, MTAC)
    • Desenvolvendo o site do .NET com .NET!!! – Maíra Wenzel (Principal Program Manager – Microsoft)

  • SQL SERVER HIGH AVAILABILITY AND DISASTER RECOVERY – Arquivos da palestra

    Olá pessoal, para aqueles interessados em conhecer um pouco mais sobre Availability Groups, aqui está o PPT utilizado na minha palestra no último final de semana no SQL Saturday Lima.

    SQL Server HA and DR PresentationBaixar

  • SQL Server High Availability and Disaster recovery – Cita en SQLSaturday Lima

    Olá pessoal, vou palestrar no SQL Saturday Lima – Peru!! Submeti há alguns dias algumas palestras para o SQL Saturday Lima e tive a grata satisfação de ser aprovado para palestrar! Será minha primeira palestra em espanhol, o que será um grande desafio, já que não falo espanhol há mais de 6 anos!

    Caso você esteja por perto e queira aparecer lá pela Microsoft Peru, aqui está o link de inscrição!

    https://sqlsaturday.com/2022-12-10-sqlsaturday1038/

    Hola, me gustaría informarles que proximo dia 10 de diciembre yo estaré platicando con mis amigos de Peru en el SQL Saturday Lima! Muchas gracias por la oportunidad y nos vemos allá!

    ,

  • Transaction Log – Parte 1 de 2

    Arquitetura Lógica

    O log de transações do SQL Server opera de forma lógica como se o log de transações fosse uma string de caracteres. Cada registro de log é identificado por um LSN (Log Sequence Number). Cada registro de log novo é gravado no final lógico do log com um LSN maior que o do registro antes da gravação. Os registros de log são armazenados em uma sequência à medida que são criados, de tal modo que se LSN2 for maior que LSN1, a alteração descrita pelo registro de log mencionado por LSN2 ocorreu após a alteração descrita no registro de log LSN1. Cada registro de log contém a ID da transação a que pertence. Para cada transação, todos os registros de log associados com a transação são vinculados individualmente em uma cadeia usando ponteiros de retrocesso que aceleram a reversão da transação.

    Os registros de log para modificações de dados registram a operação lógica executada ou as imagens anteriores e posteriores dos dados modificados. A imagem anterior é uma cópia dos dados antes da execução da operação; a imagem posterior é uma cópia dos dados após a execução da operação.

    As etapas para recuperar uma operação dependem do tipo de registro de log:

    • Log da operação lógica
      • Para avançar a operação lógica, é executada a operação novamente.
      • Para reverter a operação lógica, é executada a operação lógica inversa.
    • Log da imagem anterior e posterior
      • Para avançar a operação lógica, é aplicada a imagem posterior.
      • Para reverter a operação lógica, é aplicada a imagem anterior.

    São registrados muitos tipos de operações no log de transações. Essas operações incluem:

    • O início e o término de cada transação.
    • Toda modificação de dados (inserção, atualização ou exclusão). Isso inclui mudanças por procedimentos armazenados do sistema ou instruções DDL (linguagem de definição de dados) para qualquer tabela, inclusive tabelas do sistema.
    • Toda extensão e alocação ou desalocação de página.
    • Criando ou descartando uma tabela ou um índice.

    Operações de reversão também são registradas. Cada transação reserva espaço no log de transações para verificar se há espaço de log suficiente para oferecer suporte a uma reversão causada por uma instrução de reversão explícita ou se um erro for encontrado. A quantidade de espaço reservada depende das operações executadas na transação, mas geralmente é igual à quantidade de espaço usada para registrar cada operação. Esse espaço reservado é liberado quando a transação é concluída.

    A seção do arquivo de log originado do primeiro registro de log deve estar presente para que todo o banco de dados seja revertido com êxito para o registro de log da última gravação, chamada de parte ativa do log, log ativo ou base do log. Essa é a seção do log necessária para uma recuperação completa do banco de dados. Nenhuma parte do log ativo pode ter sido truncada. O LSN (número de sequência de log) do primeiro registro de log é conhecido como o LSN de recuperação mínimo (MinLSN) . Saiba mais sobre operações com suporte do log de transações em O log de transações (SQL Server) .

    O backup diferencial e o backup de log avançam o banco de dados restaurado para uma hora posterior que corresponde a um LSN mais alto.

    Arquitetura Física

    O log de transações em um banco de dados mapeia um ou mais arquivos físicos. Conceitualmente, o arquivo de log é uma cadeia de caracteres de registros de log. Fisicamente, a sequência de registros de log é armazenada com eficiência no conjunto de arquivos físicos que implementam o log de transações. Deve haver, no mínimo, um arquivo de log para cada banco de dados.

    VLFs (Virtual Log Files)

    O Mecanismo de Banco de Dados do SQL Server divide cada arquivo de log físico internamente em vários VLFs (arquivos de log virtuais). Os arquivos de log virtuais não têm tamanho fixo e não há número fixo de arquivos de log virtuais para um arquivo de log físico. O Mecanismo de Banco de Dados escolhe o tamanho dos arquivos de log virtuais dinamicamente enquanto está criando ou estendendo os arquivos de log. O Mecanismo de Banco de Dados tenta manter um pequeno número de arquivos virtuais. O tamanho dos arquivos virtuais depois que um arquivo de log for estendido é a soma do tamanho do log existente com o tamanho do incremento do arquivo novo. O tamanho ou o número de arquivos de log virtuais não pode ser configurado nem definido por administradores.

    ,

  • Workshop Certificação AZ-900 e DP-900 – Campinas.NET- outubro/2022

    Na manhã do dia 08/10/2022 (sábado) realizei uma apresentação/Workshop sobre o exame de certificação AZ-900 – Microsoft Azure Fundamentals e também sobre o exame DP-900 – Microsoft Azure Data Fundamentals, em espaço cedido pela UniMetrocamp em Campinas-SP. Novamente uma atividade em parceria com meus amigos Ericson da Fonseca (Microsoft MVP) e o Renato Groffe (Microsoft MVP, MTAC). Tivemos um total de 20 pessoas acompanhando a apresentação.

    Durante este evento cobrimos dicas voltadas ao exame de certificação AZ-900 (Azure Fundamentals) e DP-900 (Azure Data Fundamentals), principalmente conceitos de cloud computing e uma visão geral de diversos serviços oferecidos pelo Microsoft Azure (como Azure App Service, Azure Functions, Azure Kubernetes Service, Azure Storage, Azure Arc, Azure Monitor, Application Insights, Azure SQL Databases, Managed Databases…).

    A fonte primária de estudos que recomendamos na preparação para este exame é o roteiro de aprendizagem no Microsoft Learn:

    https://learn.microsoft.com/en-us/certifications/exams/az-900

    Certificações Microsoft: 8 exames que podem ser realizados gratuitamente! | Outubro-2022

    A seguir estão os prints com os tópicos que abordamos e algumas fotos do evento…

  • SQL Saturday SP presencial está de volta!

    Quem estava com saudades do maior evento de tecnologias Microsoft para profissionais de bancos de dados, pode ficar tranquilo!

    Temos o enorme prazer de anunciar a volta do SQL Saturday São Paulo, que neste ano será realizado na Faculdade Monitor, localizado na Av. Rangel Pestana, 1105 – Brás – São Paulo – SP

    Como de costume, teremos vários MVPs e alguns dos maiores profissionais de bancos de dados do Brasil. Veja a grade!

    Portanto, façam planos para assistir à este que é nossa retomada de eventos presenciais para profissionais de bancos de dados!

    Inscrevam-se aqui e nos encontramos dia 05/11/2022!

    ,

  • SQL Server 2022 What’s new Series – Query Store and Intelligent Query Processing

    O Repositório de Consultas para réplicas secundárias está disponível com instâncias do SQL Server 2022 (16.x) configuradas em grupos de disponibilidade. Quando esse recurso está habilitado, as informações de execução de consulta de réplicas secundárias são enviadas de volta para a réplica primária e armazenadas em seu próprio Repositório de Consultas. Isso permite monitoramento e análise centralizados do desempenho da consulta em todas as réplicas no grupo de disponibilidade. Observe que esse recurso não está disponível para ambientes de grupo de indisponibilidade ou para versões anteriores do SQL Server.

    Antes de usar o Repositório de Consultas para réplicas secundárias em uma instância do SQL Server, você precisa ter um grupo de disponibilidade Always On. Em seguida, habilite o Query Store para réplicas secundárias usando as opções ALTER DATABASE SET (Transact-SQL).

    Se o Query Store ainda não estiver habilitado e no modo READ_WRITE na réplica primária, você deverá ativá-lo antes de prosseguir. Execute o seguinte para cada banco de dados desejado na réplica primária:

    ALTER DATABASE [Database_Name] SET QUERY_STORE = ON;
ALTER DATABASE [Database_Name] SET QUERY_STORE ( OPERATION_MODE = READ_WRITE );


    Para habilitar o Repositório de Consultas em todas as réplicas secundárias, conecte-se à réplica primária e execute o seguinte para cada banco de dados desejado. Atualmente, quando o Repositório de Consultas para réplicas secundárias está habilitado, ele é habilitado para todas as réplicas secundárias.

    ALTER DATABASE [Database_Name]
FOR SECONDARY SET QUERY_STORE = ON (OPERATION_MODE = READ_WRITE );

    Para desabilitar o Repositório de Consultas em todas as réplicas secundárias, conecte-se à réplica primária e execute o seguinte para cada banco de dados desejado:

    ALTER DATABASE [Database_Name] FOR SECONDARY SET QUERY_STORE = OFF;

    Você pode validar se o Repositório de Consultas está habilitado em uma réplica secundária conectando-se ao banco de dados na réplica secundária e executando o seguinte:

    SELECT desired_state, desired_state_desc, actual_state, actual_state_desc, readonly_reason FROM sys.database_query_store_options;

    Os resultados de amostra a seguir da consulta de sys.database_query_store_options indicam que o Repositório de Consultas está em um estado READ_CAPTURE_SECONDARY para o secundário

    Para desabilitar o Repositório de Consultas para réplicas secundárias, conecte-se ao banco de dados na réplica primária e execute o seguinte código:

    ALTER DATABASE CURRENT FOR SECONDARY SET QUERY_STORE = OFF;

  • SQL Server 2022 What’s new Series – Virtual Log Files

    Arquivos de log virtual (VLFs) são um conceito-chave no gerenciamento de log de transações do SQL Server. Eles são partições lógicas de arquivos de log físicos usados para registrar transações de banco de dados. O Mecanismo de banco de dados do SQL Server cria e gerencia VLFs dinamicamente em arquivos de log físicos.

    O tamanho e o número de VLFs são determinados pelo SQL Server Database Engine e são baseados no tamanho e na frequência do crescimento do arquivo de log. No SQL Server 2014 e versões posteriores, se o próximo crescimento for menor que 1/8 do tamanho físico do log atual, crie 1 VLF que cubra o tamanho do crescimento. Se o próximo crescimento for maior que 1/8 do tamanho do log atual, o método anterior a 2014 é usado, onde são criados 4 VLFs que cobrem o tamanho do crescimento se o crescimento for menor que 64 MB.

    No Banco de Dados SQL do Azure e no SQL Server 2022, o método é um pouco diferente. Se o crescimento for menor ou igual a 64 MB, apenas 1 VLF será criado para cobrir o tamanho do crescimento. Se o crescimento for de 64 MB até 1 GB, 8 VLFs serão criados para cobrir o tamanho do crescimento e, se o crescimento for maior que 1 GB, 16 VLFs serão criados para cobrir o tamanho do crescimento.

    Ter muitos VLFs pode retardar a inicialização do banco de dados, backup de log e operações de restauração, enquanto ter muito poucos pode causar problemas com backups de log de transações, replicação e recuperação. Portanto, é essencial estimar adequadamente o tamanho necessário e as configurações de crescimento automático de um log de transação para garantir a distribuição ideal dos VLFs.

    É recomendável atribuir aos arquivos de log um valor de tamanho próximo ao tamanho final necessário, usando os incrementos necessários para obter a distribuição VLF ideal e ter um valor growth_increment relativamente grande. Isso ajudará a garantir a criação e o gerenciamento eficientes dos VLFs.

    Como resolver esse problema em bancos de dados com um grande número de VLFs?

    1. Shrink o arquivo de Transaction Log
    2. Cresça o arquivo de Log em apenas um passo usando o seguinte script:
    ALTER DATABASE <database name> MODIFY FILE (NAME='Logical file name of transaction log', SIZE = <required size>);

    Depois de definir o novo layout do arquivo de log de transações com menos VLFs, revise e faça as alterações necessárias nas configurações de crescimento automático do log de transações. Isso garante que o arquivo de log evite encontrar o mesmo problema no futuro.

    Antes de executar qualquer uma dessas operações, certifique-se de ter um backup restaurável válido caso encontre problemas posteriormente.