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)

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.

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…

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;

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.

O SQL Server agora possui suporte para a Autenticação Azure Active Directory para sistemas operacionais Windows e Linux

É ótimo ver que agora o SQL Server dá suporte a vários métodos de autenticação com o Azure AD, incluindo:

• senha do Azure AD,
• Azure AD integrado,
• Azure AD universal com autenticação multifator
• Token de acesso do Azure AD.

Também é importante observar que, para usar a autenticação do Azure AD com o SQL Server, o SQL Server e o host Windows ou Linux em que ele é executado devem ser registrados no Azure Arc, e o Agente do Azure Arc e a extensão do Azure para SQL Server devem estar instalados .

Em relação aos métodos de autenticação, o Azure AD Password permite especificar o nome de usuário e a senha para o cliente e o driver, mas é recomendável evitar isso, pois requer o envio de senhas pela rede.

O Azure AD integrado usa as credenciais do Windows do usuário para autenticação do Azure AD quando o domínio do Windows é sincronizado com o Azure AD e o usuário está conectado ao domínio do Windows.

O Azure AD Universal com autenticação multifator é o método interativo padrão com opção de autenticação multifator para contas do Azure AD, e o token de acesso do Azure AD é usado por alguns clientes não GUI, como Invoke-sqlcmd.

Vale a pena observar que apenas o SQL Server 2022 (16.x) local com um sistema operacional Windows ou Linux compatível, ou o SQL Server 2022 em VMs do Windows Azure, é compatível com a autenticação do Azure AD.

Além disso, a conta do Azure AD usada para conectar o SQL Server ao Azure Arc deve ter as permissões necessárias, incluindo associação ao grupo de integração de máquinas conectadas ao Azure ou função de colaborador no grupo de recursos, associação à função Administrador de recursos de máquinas conectadas do Azure no grupo de recursos e associação na função Leitor no grupo de recursos.

Grupos de disponibilidade Always On no SQL Server são projetados para fornecer recursos de alta disponibilidade e recuperação de desastres para um grupo de bancos de dados de usuários que precisam operar como um grupo coordenado.

Esses bancos de dados são replicados em alguns nós em um cluster e são mantidos sincronizados em todas as réplicas do grupo de disponibilidade.

Em um grupo de disponibilidade Always On, há uma réplica primária e uma ou mais réplicas secundárias.

A réplica primária é a instância do SQL Server que hospeda a cópia primária do banco de dados de disponibilidade e é responsável por processar todas as operações de gravação no banco de dados.

As réplicas secundárias são cópias somente leitura do banco de dados de disponibilidade que são mantidas em sincronia com a réplica primária.

Quando há uma falha no nó ou na integridade do SQL Server no nó que hospeda a cópia primária, o grupo de disponibilidade pode fazer failover para uma das réplicas secundárias.

Durante um failover, todos os bancos de dados do usuário no grupo de disponibilidade são movidos como uma unidade para o novo nó de réplica, garantindo que permaneçam sincronizados e disponíveis.

Os bancos de dados do usuário em um grupo de disponibilidade podem ser mantidos sincronizados em todas as réplicas no modo síncrono ou assíncrono.

No modo síncrono, as transações são confirmadas em todas as réplicas antes que a transação seja considerada confirmada na réplica primária, garantindo que os dados sejam sempre consistentes em todas as réplicas.

No modo assíncrono, as transações são confirmadas primeiro na réplica primária e, em seguida, replicadas de forma assíncrona para as réplicas secundárias. Embora o modo assíncrono possa fornecer maior desempenho, existe o risco de perda de dados em caso de failover.

Os grupos de disponibilidade contidos no SQL Server são projetados para manter as configurações do ambiente de execução consistentes nas réplicas de um grupo de disponibilidade. Cada grupo de disponibilidade independente tem seus próprios bancos de dados de sistema master e msdb, nomeados de acordo com o nome do grupo de disponibilidade. Esses bancos de dados do sistema são propagados automaticamente para novas réplicas e as atualizações são replicadas para esses bancos de dados como qualquer outro banco de dados em um grupo de disponibilidade.

Quando você adiciona um objeto como um logon ou trabalho de agente enquanto estiver conectado ao grupo de disponibilidade contido, essas alterações serão replicadas para as outras réplicas no grupo de disponibilidade. Isso garante que quando o grupo de disponibilidade contido fizer failover para outra instância, você ainda verá os trabalhos do agente e poderá autenticar usando o logon criado no grupo de disponibilidade independente.

É importante observar que os grupos de disponibilidade contidos não representam um limite de segurança e não há limite que impeça uma conexão com um grupo de disponibilidade contido de acessar bancos de dados fora do grupo de disponibilidade.

Portanto, é importante garantir que medidas de segurança adequadas sejam implementadas para proteger dados confidenciais.

Quando um novo grupo de disponibilidade independente é criado, os bancos de dados do sistema são inicialmente modelos vazios sem nenhum dado.

As contas de administrador na instância que cria o grupo de disponibilidade contido são copiadas para o banco de dados mestre contido, o que permite que o administrador faça logon no grupo de disponibilidade independente e defina o restante da configuração. No entanto, quaisquer usuários locais ou configurações na instância não aparecerão automaticamente nos bancos de dados do sistema independente e devem ser recriados manualmente no contexto do grupo de disponibilidade independente.

Uma exceção a isso é que todos os logons na função sysadmin na instância pai são copiados para o novo banco de dados principal específico do grupo de disponibilidade.

Conectar-se ao ouvinte do grupo de disponibilidade contido garante que você esteja operando no contexto do grupo de disponibilidade contido e tenha acesso ao conteúdo encontrado nos bancos de dados do sistema contido do grupo de disponibilidade contido, como logons, trabalhos de agente e outras definições de configuração específico para o grupo de disponibilidade contido.

Por outro lado, a conexão direta com a instância ignora o ambiente do grupo de disponibilidade contido e você estará sujeito ao conteúdo encontrado nos bancos de dados do sistema da instância, que pode ser diferente do conteúdo encontrado nos bancos de dados do sistema contido do grupo de disponibilidade contido .

"Persist Security Info=False;
User ID=MyUser;Password=xxxx;
Initial Catalog=MyContainedDatabase;
Server=MyServer;"

diferenças entre conectar-se à instância e conectar-se ao grupo de disponibilidade independente:

• Quando conectados à instância, os usuários verão todos os bancos de dados nessa instância, incluindo bancos de dados do sistema e bancos de dados do usuário que não fazem parte do grupo de disponibilidade contido.
• Quando conectados ao grupo de disponibilidade contido, os usuários verão apenas os bancos de dados que fazem parte desse grupo, além do banco de dados tempdb.
• Os nomes dos bancos de dados mestre e msdb do AG contido são diferentes quando conectados à instância e quando conectados ao AG contido.
• Dentro do AG contido, seus nomes são simplesmente “master” e “msdb”, mas fora do AG eles são denominados “[contained AG]_master” e “[contained AG]_msdb”.
• O ID do banco de dados para o banco de dados mestre do AG contido é 1 quando conectado ao AG contido, mas pode ser diferente quando conectado à instância.
• Embora os usuários não vejam bancos de dados fora do AG contido na exibição sys.databases quando conectados em uma conexão de AG contido, eles ainda poderão acessar esses bancos de dados usando um nome de três partes ou usando o comando USE.
• As opções de configuração do servidor podem ser lidas a partir de uma conexão AG contida, mas só podem ser gravadas a partir de uma conexão em nível de instância usando o procedimento armazenado do sistema sp_configure.
• Embora um usuário sysadmin possa executar a maioria das operações no nível da instância quando conectado a um AG contido, a maioria das operações no nível do banco de dados, no nível do terminal ou no nível do AG só pode ser executada a partir de uma conexão no nível da instância.