Fala pessoal, tudo bem? Quando falamos sobre Azure SQL Database, é bem comum lembrar das limitações que essa solução PaaS possui mesmo sendo muito escalável e flexível, por exemplo a ausência de recursos muito utilizados em instalações standalone do SQL Server como o DatabaseMail, SQL Agent, Cross-database etc… Na pratica sabemos que, com a utilização de outros serviços no Azure conseguimos contornar essas limitações, no entanto, mesmo assim é necessário passar por um processo de refatoração e transformações das databases ou até mesmo em alguns casos remodelar. Mas com o passar dos anos, a Microsoft cada vez mais tem lançado soluções para aprimorar o SQL Database, e no mês de abril de 2023 foi anunciado a disponibilização do Change Data Capture (CDC) para Azure SQL Database, o que antes estava disponível somente para o SQL Server e Managed Instances em decorrência da necessidade da utilização do SQL Agent e criação de jobs (Antes que o CDC fosse disponibilizado havia a possibilidade de configurar a feature chamada “temporal tables” no Azure SQL DB). Pré-requisitos recomendados: Estar familiarizado com a terminologia e conceitos básicos de Cloud Computer no Azure; Possuir alguma experiencia de administração de banco de dados SQL Server; Ter um breve conhecimento sobre o Azure SQL Database. O que é Change Data Capture (CDC)? Assim como detalhado na documentação da Microsoft, de forma resumida é uma funcionalidade do SQL Server que permite capturar e rastrear as alterações feitas nos dados de uma tabela, ele registra as operações de inserção, atualização e exclusão (DML) que ocorrem nos registros da tabela, permitindo que as alterações sejam rastreadas e consultadas posteriormente. Essas alterações são armazenadas em tabelas especiais chamadas “tabelas de controle de alterações”, que são criadas automaticamente pelo SQL Server. Essas tabelas contêm as informações necessárias para reconstruir os dados alterados, incluindo o tipo de operação, os valores antigos e os valores novos. Link de referência: Clique Aqui Ao contrário do SQL Server standalone e o Managed Instance, o CDC no SQL Database não utiliza SQL Server Agent jobs, mas oferece funcionalidade semelhante através de um scheduler que executa automaticamente os processos “capture” e “cleanup” de alterações nas tabelas. O mais incrível de tudo, é que o processo para habilitar o CDC no SQL Database funciona da mesma forma que aos demais ambientes: Conectar no SQL Database usando uma conta com privilégios suficientes; Habilitar o CDC na database através da procedure [sys.sp_cdc_enable_db]; Habilitar o CDC em uma tabela específica através da procedure [sys.sp_cdc_enable_table]; Link de referência: Clique Aqui O processo de habilitar o CDC é bem simples e fácil, para demonstração foi criado uma SQL Database no purchasing mode vCore, no Service Tier General Purpose e no Computer Tier Serverless com apenas 1 vCore, com o modelo de dados do AdventureWorksLT (Com o mínimo de recursos possíveis): Estando conectado na database, basta executar a seguinte procedure para habilitar o CDC: EXEC sys.sp_cdc_enable_db Query para validar a habilitação do CDC: SELECT name, is_cdc_enabled FROM sys.databases WHERE is_cdc_enabled = 1 Em seguida bastar habilitar o CDC nas tabelas desejadas, em nosso caso iremos habilitar somente na tabela [SalesLT].[ProductModel]: EXEC sys.sp_cdc_enable_table @source_schema = N'SalesLT', @source_name = N'ProductModel', @role_name = NULL, @filegroup_name = NULL, @supports_net_changes = 0 Aqui finalizamos a configuração do CDC, as demais configurações seriam necessárias se houvesse necessidade de personalização ou habilita-lo em mais tabelas. Com a seguinte query conseguimos ver todas as tabelas de controle que a feature do CDC criou, incluindo a tabela [SalesLT_ProductModel_CT] que irá armazenar todas as alterações de registros (As tabelas que armazenam as alterações possuem o sufixo “CT”): Link do GitHub com todos os scripts e queries auxiliares para criação dos comandos de forma dinâmica: Clique Aqui Vamos fazer alguns testes para validar o CDC, primeiro iremos inserir um registro na tabela [SalesLT].[ProductModel] e verificar sua inserção, em seguida alterar um valor e por fim deleta-lo. Inserção do registro: Atualização e deleção do registro: Ao consultar a tabela [SalesLT_ProductModel_CT] é possível observar todas as operações que ocorreram na tabela principal, incluindo inserção do registro, valor anterior da alteração identificado pela operação 3, e o valor posterior da alteração identificado pela operação 4, e por fim a deleção do registro: Limitação da feature no Azure SQL Database: No purchasing model DTU, a feature do CDC está somente disponível no service tier Premium, além disso, caso a database esteja em SQL Elastic Pool, a configuração do mesmo precisa ser superior a 100 DTUs, caso contrário será retornado o seguinte erro: No teste realizado, para obter sucesso ao habilitar a feature houve a necessário de realizar um scale up para o service Tier Premium: Em seguida foi obtido sucesso na habilitação da feature: Bom pessoal, acredito que finalizamos por aqui, e espero que tenham gostado assim como eu, dessa novidade incrível que a Microsoft disponibilizou para o Azure SQL DB, sem duvidas outros serviços que não envolvem o banco de dados diretamente também terão novidades., tendo em vista que muitas ferramentas no mercados utilizam o CDC no SQL Server para replicação de dados, versionamento, migração etc.. como o caso do AWS DMS, o Apache KAFKA e dentre outros.

Fala pessoal, tudo bem? Hoje gostaria de falar um pouco sobre uma limitação que existe no Azure SQL Database que é muito importante, principalmente quando é pensado em migrar um banco de dados local (on-premise) para a plataforma como serviço (PaaS) da Microsoft. Pré-requisitos recomendados: Estar familiarizado com a terminologia e conceitos básicos de Cloud Computer no Azure; Ter um breve conhecimento sobre o Azure SQL Database; Dependendo da modelagem de um ou mais banco de dados, é comum vermos a utilização de instruções realizando cross-database, basicamente é quando uma instrução está referenciando uma tabela de outro banco de dados, podendo ser também procedures, funções ou até mesmo, a utilização de Linked Servers no SQL Server on-premisse, para acessar tabelas de outro servidor e banco de dados. Link de referência: Redgate Vamos exemplificar um pouco mais, em uma instalação Stand Alone do SQL Server 2019, temos os seguintes banco de dados: Levando em conta, que por questão de regra de negócio ou devido ao planejamento da arquitetura do sistema, temos a tabela [Customers] no banco de dados [CustomersData], e a tabela [Orders] no banco de dados [OrdersData]. E queremos saber quais foram os 10 clientes que mais realizaram pedidos em ordem decrescente, como as tabelas estão em bancos de dados diferentes seria necessario realizar um cross-database, informando a estrutura de [database].[schema].[table] na instrução, tendo algo semelhante a seguinte query: Exemplificando esse mesmo cenário no Azure SQL Database, estaremos criando duas SQL Databases através do SQL Server Management Studio usando o Transact SQL (T-SQL), levando em conta que o SQL Server já esteja previamente provisionado: Semelhante ao exemplo do SQL Sever Stand Alone, foi criado os bancos de dados e populado as tabelas [Customers] e [Orders], mas, se tentarmos executar a mesma instrução receberemos o seguinte erro: OBS: Todos os scripts usados neste artigo se encontram no seguinte link: Clique Aqui Como retornado na mensagem de erro, não é suportado cross-database no Azure SQL DB, mas existe outras formas de referenciar outros bancos de dados, seja através de serviços disponiveis no Azure ou através de instruções T-SQL. Neste artigo, estaremos falando sobre o Azure SQL Database elastic query e a criação de external data source para realizar consultas de Transact-SQL para abranger vários bancos de dados no Azure SQL DB. Vale ressaltar que essa feature ainda se encontra em preview pela Microsoft, mas a mesma permite realizar leituras de banco de dados remotos completamente em T-SQL, e oferece uma nova opção de migração de banco de dados no SQL Server on-premisse para o Azure SQL DB, tendo em vista que através dessa feature é possivel realizar cross-database entre banco de dados e entre servidores lógicos diferentes (SQL Server) semelhante aos linked servers utilizados. Elastic query used on scaled-out data tier (Microsoft) Agora chegamos na melhor parte, a parte pratica. Levando em consideração que já temos o Azure SQL DB [CustomersData] com a tabela [Customers] e o [OrdersData] com a tabela [Orders], seguiremos para a configuração do “SQL Database elastic query” com os seguintes passos: CREATE LOGIN CREATE USER CREATE MASTER KEY CREATE DATABASE SCOPED CREDENTIAL CREATE EXTERNAL DATA SOURCE CREATE EXTERNAL TABLE Neste exemplo estaremos acessando a tabela [Orders] através da database [CustomersData], mas nada impediria de fazer o inverso ou até mesmo nos dois sentidos. Primeiro será necessario criar um novo login no banco de dados [master] que iremos chamar de “RemoteLogger” e em seguida acessar a SQL Database [OrdersData] e criar um usuário para atribuir ao login criado, e conceder a permissão de leitura na tabela: Agora precisamos criar uma nova master key no banco de dados de origem [CustomersData]: Também precisaremos criar uma credencial no escopo do banco de dados de origem [CustomersData], para o banco de dados de destino [OrdersData] que contém o usuário e a senha para o login “RemoteLogger” criado: Agora estaremos criando uma external data source para referência dos dados remoto, para definir onde procurar o banco de dados remoto, seja no mesmo ou em outro servidor. A fonte de dados remota para este exemplo será chamada de “RemoteDatabase”. Por fim, será necessario criar uma tabela externa (external table) para fazer referência aos campos da tabela [Orders] do banco de dados externo/destino [OrdersData]: Vale lembrar que o nome da tabela externa precisa ser o mesmo nome da tabela referenciada, agora ao executarmos a instrução que havia retornando erro, sem especificar outras databases, somente a tabela externa obteremos sucesso, tendo em vista que agora estamos usando uma “External Table” que debaixo dos panos é acessado outro SQL DB para acessar os dados: Também conseguimos validar tabelas externas criadas em uma SQL Database, através da coluna [is_external] na DMV [sys.tables]: Outra questão que vale ressaltar, é que existe algumas recomendações e limitações com a utilização desse recurso, basta acessar o link de referência da Microsoft já informado anteriormente para conferir esses detalhes. Bom pessoal, espero que tenham gostado desse artigo, a feature SQL Database elastic query, é muito útil em diversas situações, principalmente quando a utilização de cross-database ou a utilização de linked servers em determinados banco de dados eram impeditivos de uma migração para o Azure SQL Database, claro que algumas instruções ainda teriam que ser reestruturas, mas é um ganho considerável com a utilização dessa feature.