Meetup MLSA Talk Nights #11

Olá Pessoal!

Nessa semana participei como convidado do Meetup do programa Microsoft Learn Student Ambassador. Novamente com meu amigo Sidney Cirqueira (https://www.linkedin.com/in/sidneyoliveiracirqueira/) apresentamos dois temas: Azure SQL Database: Starting Points e Azure Machine Learning: From Zero to Hero.

Para quem não pode participar, segue o link com o vídeo da apresentação no Youtube.

Para mais informações sobre o programa Microsoft Learn Student Ambassador acesse: https://studentambassadors.microsoft.com/

Até a próxima!

• 

2ª Live do grupo SQL Server DF – Arquitetura Moderna de Dados & IA no Microsoft Azure

Olá Pessoal!

Nessa semana aconteceu a 2ª Live do grupo SQL Server DF e tive a oportunidade de apresentar com o Sidney Cirqueira (https://medium.com/@sidneyocirqueira) o tema: Arquitetura Moderna de Dados & IA no Microsoft Azure.

Para quem não pode acompanhar no dia, segue o link com vídeo publicado no canal:

Agradecimento especial a equipe do SQL Server DF que conduziu essa live, Nane e Raul.

Até a próxima!

• 

Utilizando Azure Function com o Data Factory

Olá Pessoal!

Feliz Ano Novo atrasado!!

Para iniciar bem o ano, vou publicar um novo artigo voltado para utilização do Azure Function App com o Azure Data Factory.

O Azure Function App é um serviço de computação serverless, que permite que códigos sejam executados por eventos sem a necessidade de provisionar uma infraestrutura. Para mais informações: https://docs.microsoft.com/pt-br/azure/azure-functions/functions-overview

Como sabemos, o Azure Data Factory (ADF) é um serviço de ETL na nuvem e dentre as suas capacidades nativas, permite que componentes adicionais possam ser utilizados dentro de uma pipeline para expandir suas capacidades, como por exemplo, o Azure Function App. Usando o Azure Function App é possível executar scripts ou pedaços de códigos em resposta a uma variedade de eventos.

No exemplo que irei demonstrar, vou utilizar uma função para parar/iniciar uma Máquina Virtual realizando a sua chamada pelo ADF.

Pré-requisitos:

Data Factory
Function App
Virtual Machine

Iniciaremos pela inserção do código PowerShell a ser utilizado no Function App.


using namespace System.Net

# Input bindings are passed in via param block.
param($Request, $TriggerMetadata)

#Set default value
$status = 200

Try{
# Write to the Azure Functions log stream.
Write-Host "PowerShell HTTP trigger function processed a request."

# Interact with Body parameters or the body of the request.
write-host ($request | Convertto-json -depth 99)

$ResourceGroupName = $request.Body.ResourceGroupName
$VMName = $request.Body.VMName

$vmStatus = Get-AzVM -ResourceGroupName $ResourceGroupName -Name $VMName -Status
Write-output $vmStatus
If(-not ($vmStatus)){
$status = 404
Throw 'ERROR! VM not found'
}
[string]$Message = "Virtual machine status: " + $vmStatus.statuses[-1].displayStatus
Switch($request.Body.action){
'start'{
If($vmStatus.statuses[-1].displayStatus -ne 'VM running'){
Start-AzVM -ResourceGroupName $ResourceGroupName -Name $VMName -Verbose
[string]$message += '... Virtual machine is now starting'
}
Else{
[string]$message += '... Virtual machine is already running'
}
}
'stop'{
If($vmStatus.statuses[-1].displayStatus -ne 'VM deallocated'){
Stop-AzVM -ResourceGroupName $ResourceGroupName -Name $VMName -Force -Verbose
[string]$message += '... Virtual machine is stopping'
}
Else{
[string]$message += '... Virtual machine is already deallocated'
}
}
default{
[string]$message += ". $($request.Body.action) is outside of the allowed action 'start' & 'stop'"
$status = 400
}
}
}
Catch{
[string]$message += $_
}

Write-output $message

# Associate values to output bindings by calling 'Push-OutputBinding'.
Push-OutputBinding -Name Response -Value (
[HttpResponseContext]@{
StatusCode = $status
body = @{ "message" = [string]$message }
headers = @{ "content-type" = "text/plain" }
}
)


Dentro do Function App no Azure selecione a opção Webhook + API para que possamos chamar a função através de requisições HTTP e em seguida, aplique o código informado acima.

Indo para o ADF, crie uma nova pipeline e a adicione o componente do Azure Function.

No ADF será necessário criar uma nova conexão (Linked Service) com o Function App, sendo assim, devemos retornar ao Function App para obter a Function Key, que pode ser gerada na seguinte opção dentro do serviço.

Em seguida retorne ao ADF e faça a configuração com algumas propriedades conforme a imagem abaixo. Lembre de publicar as alterações.

Veja que no Body informado acima temos algumas informações importantes que definem a qual Máquina Virtual queremos que a ação seja executada e qual tipo de ação, que no caso pode ser tanto um Start quanto um Stop na VM.

{"Action":"stop","VMName":"demovm2020","ResourceGroupName":"rg_demo_function_adf"}

Ainda temos alguns ajustes adicionais que devem ser feitos para o Function App antes de executar a pipeline criada no ADF. Precisamos garantir que o código consiga acessar e autenticar nos recursos do Azure, caso contrário a Máquina Virtual não estará acessível.

Acesse o menu de Platform Features dentro do Function App e no grupo de Networking vá até a opção de Identity. Dentro dessa opção você deve alterar o status para On. Após essa alteração, a autenticação aos recursos pelo Function App será feito utilizado o Azure role-based-access-control (RBAC).

O último passo necessário é a atribuição de privilégio ao grupo de recursos no qual o Function App deve ter acesso para autenticação, que no caso é o grupo de recursos que a Máquina Virtual pertence.

Na imagem abaixo podemos ver que foi selecionado a Role Owner e para poder retornar as Functions App, a opção Assign access to deve ser alterada para Function App.

Voltando para o ADF, podemos simplesmente executar a pipeline criada e aguardar pelo status de sucesso.

Até a próxima!

Timeout na Conexão do Azure Data Factory

Olá Pessoal!

Recentemente estive envolvido em um projeto de carga utilizando o Azure Data Factory como orquestrador, tendo como origem o Oracle Database On-premises e destino, o Azure SQL Data Warehouse.

Os dados do Oracle DB estavam distribuídos em dois hosts distintos e percebi que no processo de configuração da fonte de dados de origem, uma instância concluía a conexão com sucesso enquanto a outra constantemente retornava timeout. Esse comportamento também foi observado quando utilizado a ferramenta de teste de conexão presente no Integration Runtime Configuration Manager.

O mais interessante, é que ambas as instâncias estavam acessíveis pelo SQL Developer e ODBC Data Sources, não justificando qualquer tipo de restrição de acesso ou até falta conectividade no host que estava hospedando o Integration Runtime.

Após o contato com o engenheiro de suporte da Microsoft, foi possível identificar que existia um delay maior no tempo de resposta entre as instâncias, sendo o suficiente para uma delas ultrapassar o limite de tempo do processo de validação da conexão no portal do Data Factory e também no processo do teste através do Integration Runtime Configuration Manager.

Para contornar esse comportamento, um parâmetro adicional para controle do timeout teve que ser adicionado nas propriedades da conexão e dessa forma, os limites de timeout substituíram a definição padrão do produto. Note na imagem abaixo que após a aplicação do parâmetro a conexão é feita com sucesso.

Até a próxima!

Consumindo dados do Azure IoT Hub com o Power BI

Olá Pessoal!

Tenho trabalhado cada vez mais com um portfólio extenso de produtos no Azure relacionados a Data Platform e com certa frequência, tenho que fazer algumas apresentações de soluções. Vou mostrar neste artigo um exemplo de como consumir dados com origem no Azure IoT Hub dentro do Power BI Service em tempo real.

Para esse exemplo utilizarei como fonte de dados o Raspberry Pi Web Simulator, que irá basicamente gerar dados de telemetria aleatórios de temperatura e umidade de forma continua. Você pode acessar através do link: https://azure-samples.github.io/raspberry-pi-web-simulator/

Para mais informações acesse o repositório dessa aplicação no Github: https://github.com/Azure-Samples/raspberry-pi-web-simulator

Utilizaremos 4 componentes na solução, a aplicação web do Raspberry Pi, o Azure IoT Hub, Azure Stream Analytics e Power BI Service.

O Azure IoT Hub é um serviço que atua como hub central de mensagens para comunicação entre as aplicações IoT e o dispositivo. Sendo assim, a primeira tarefa a ser feita é criação do serviço no Azure com a camada “F1: Free Tier”, dessa forma será possível enviar até 8 mil mensagens por dia sem custo, ideal para realização de testes.

Após a criação do serviço, devemos criar o “IoT Device” no qual será cadastrado o dispositivo e obtido a string de conexão a ser utilizada dentro do Raspberry Pi Web.

Devemos agora acessar a aplicação web do Raspberry Pi e alterar apenas a linhas 15, na qual é solicitado o “IoT hub device connection string”. Nesse trecho deve ser colocado a string de conexão obtido no IoT Device e ao final selecionado a opção “Run” para iniciar o envio dos dados de telemetria para o Azure IoT Hub.

Após o inicio do envio, as informações estatísticas podem ser consultadas na visão geral do serviço do IoT Hub.

Uma vez que os dados de telemetria estejam chegando no IoT Hub, devemos avançar para a segunda parte. Precisaremos utilizar o serviço do Azure Stream Analytics, que tem como objetivo criar uma “pipeline” para processamento dos eventos que estão sendo carregados no IoT Hub e jogá-los no Power BI Service em tempo real.

Assim como no serviço anterior, deve ser criado o recurso no Azure.

Para esse serviço deve ser configurado a fonte de entrada e saída, sendo assim, a entrada será definida com a origem do IoT Hub e a saída será um Workspace do Power BI Service.

A consulta do Stream Analytics deve ser editada para utilizar como parâmetros as fontes criadas e por último, o serviço precisa ser iniciado.

Após concluir a etapa anterior, os eventos começaram a passar pelo serviço do Stream Analytics e o conjunto de dados “IoTDataset” aparecerá no Power BI Service.

O passo final será criar um relatório e dashboard com os dados que estão chegando no Power BI em tempo real.

Chegamos ao final do processo e foi possível simular um cenário que os dados são consumidos pelo Power BI através de componentes específicos do Azure. Para mais detalhes, seguem as documentações oficiais dos serviços que utilizamos no Azure:

https://docs.microsoft.com/pt-br/azure/iot-hub/

https://docs.microsoft.com/pt-br/azure/stream-analytics/

https://docs.microsoft.com/pt-br/power-bi/

Até a próxima!

Integrando Azure Data Factory com o SSIS

Olá Pessoal!

Feliz Ano Novo…

Para iniciarmos bem o ano, vou falar um pouco sobre um produto que tenho utilizado bastante ultimamente, o Azure Data Factory.

Data Factory é um serviço de integração (ETL/ELT) disponível no Azure, tendo como diferencial a sua facilidade na construção soluções de integrações híbridas. Esse serviço também se destaca pela quantidade de conectores com suporte nativo disponíveis, os quais já passam de 70. Vocês podem conferir os detalhes gerais na página abaixo abaixo:

https://azure.microsoft.com/pt-br/services/data-factory/

Apesar de uma série de benefícios existentes em sua utilização, inclusive em sua nova versão (V2), o Data Factory ainda trás limitações quando comparamos com alguns recursos existentes no SQL Server Integration Services, principalmente na parte das transformações disponíveis.

Fora algumas limitações, o Data Factory trás ganhos na orquestração visual, tendo uma quantidade de conectores grande, além de um throughput elevado e inclusive, permitindo que pacotes On-premises do SSIS sejam executados no serviço.

No exemplo abaixo, será demonstrado como fazer a configuração do Data Factory para pode executar pacotes do SSIS. O seguinte cenário será utilizado como base, existe um pacote do SSIS (On-premises) que faz a carga de dados de um arquivo estruturado em um diretório de rede para o SQL Server local, o objetivo é levar de maneira simples esse pacote para o Data Factory.

Uma vez que o serviço do Data Factory tenha sido criado e essa etapa é relativamente simples, você deve acessar a visão geral do recurso e ir até a página de “Autor e Monitor”.

Nessa tela inicial está disponível acesso as principais funções do Data Factory, além de tutoriais e materiais de apoio para realizar as principais operações no serviço.

A primeira opção é referente a criação de “Pipeline”, que são agrupamentos lógicos de atividades que juntos realizam a tarefa. A segunda opção de “Copy Data” inicia uma atividade de cópia entre dois armazenamento de dados, podendo estar On-premises ou Cloud. A terceira opção de “Configure SSIS Integration Runtime” apoia exatamente na atividade que iremos realizar. Por último temos o “Set up Code Repository” para realizar a associação do repositório de versionamento com o Data Factory.

Avance para seleção da opção “Configure SSIS Integration Runtime”. O “Integration Runtime” é uma estrutura computacional do Data Factory que fornece algumas capacidades de integração de dados entre ambientes de redes diferentes. No Data Factory uma atividade define a ação a ser realizada, um “Linked Service” define o armazenamento de dados de destino e o “Integration Runtime” fornece a ponte entre a atividade e o “Linked Service”. A diferença do “Azure-SSIS Integration Runtime” para as outras opções, se resume a capacidade de executar pacotes nativos do SSIS no Data Factory com recursos do Azure VM em Cluster dedicados para essa tarefa.

Veja que existe a seleção do hardware a ser utilizado, assim como, a quantidade de nodes. Quando comparado a precificação do “SSIS Integration Runtime” com a pipeline sem integração, o custo é muito maior, sendo assim, o custo deve ser um fator importante na decisão na utilização desse tipo de solução integrada.

A próxima etapa no setup é referente a configuração do Azure SQL Database que irá hospedar a base do “SSIS Catalog”. O server já existia na subscrição, sendo assim, só foi necessário preencher as informações de acesso e selecionar o “Tier”.

Se necessário altere as configurações avançadas disponíveis e em caso de dúvida, repare que existe um ícone de exclamação próximo ao item, ao passar o mouse por cima será possível obter mais informações sobre a função de determinada configuração, em nosso caso vou deixar o padrão e finalizar.

O deploy irá demorar alguns minutos e ao concluir será exibido dentro do Data Factory, além da base do SSISDB criada automaticamente no SQL Database.

Ao selecionar a opção “View Runtime Integration Detail” é possível acessar uma página com maior detalhes de configuração, mostrando também informações de consumo dos nodes.

Agora que terminamos essa parte do setup no Data Factory, vamos ao ambiente On-premises. Temos o projeto “CargaDados” já existente no Visual Studio (SSDT) com o pacote “Carga”. No pacote “Carga” temos uma tarefa para extração dos dados de determinado arquivo estruturado e inserção deste em um banco SQL Server On-premises.

Esse projeto teve seu deploy feito para o Integration Services Catalogs da mesma instância do SQL Server On-premises.

Precisamos agora partir para segunda etapa, na qual faremos o deploy do projeto para o Azure SQL Database que está hospedando a estrutura do Integration Services Catalogs (SSISDB). A etapa é igual a qualquer outro procedimento de deploy, na tela de publicação do Integration Services dentro do Visual Studio (SSDT), deve ser selecionado o servidor e avançar para o deploy.

Uma vez concluído a estrutura do Integration Services Catalogs no Azure SQL Database será criada.

Por último, faremos o agendamento para execução periódica do pacote, essa etapa pode ser feita também por dentro do SSMS ao clicar com o botão direito no pacote e ir até a opção “Schedule”.

O recurso de agendamento pelo SSMS criará a “Pipeline”, Atividade e “Trigger” dentro do Data Factory, seguindo os parâmetros passados na configuração.

A execução da “Trigger” pode ser monitorada na guia “Monitor” na opção “Trigger Runs”.

Concluímos todos os passos da solução! Vale ressaltar que, não são todos os caso que a utilização do Data Factory com o SSIS é vantajoso, existem restrição não abordadas aqui e que devem ser vistas na documentação, apesar disso, é um recurso que funciona muito bem, além de ter uma fácil configuração. Devemos também lembrar que, o Data Factory fornece outros 2 tipos de “Integration Runtime”, não discutidos nesse artigo, um para uso com atividades no Azure e outro redes privadas.

Seguem alguns links complementares que irão ajudar na utilização do Azure Data Factory, inclusive relacionado a funcionalidade de integração com o SSIS.

https://docs.microsoft.com/pt-br/azure/data-factory/concepts-integration-runtime

https://www.blue-granite.com/blog/the-right-tool-for-the-job-azure-data-factory-v2-vs.-integration-services

https://azure.microsoft.com/pt-br/pricing/details/data-factory/

https://docs.microsoft.com/en-us/azure/data-factory/create-azure-ssis-integration-runtime

https://docs.microsoft.com/pt-br/sql/integration-services/lift-shift/ssis-azure-connect-to-catalog-database?view=sql-server-2017

Até a próxima!

AMBIENTE HÍBRIDO – AZURE SQL DATABASE COM SQL SERVER ON-PREMISES

Olá Pessoal!

O processo de adoção de soluções na nuvem esta mais natural e transparente a cada dia, sendo assim, os clientes estão optando por estender o ambiente local (On-premises) e integrá-lo como parte da arquitetura Cloud cada vez mais, transformando em uma solução híbrida. Esse tipo de solução pode ser alcançada de maneiras diferentes dependendo do tipo de plataforma de dados escolhida no ambiente da nuvem, nesse artigo vamos abordar o funcionamento de uma solução entre Azure SQL Database (Platform as a Service) e o SQL Server 2017 On-Premises.

Temos o seguinte cenário para trabalhar, o cliente deseja migrar o banco de dados SQL Server para o Azure SQL Database, levando em consideração principalmente o custo/benefício do serviço, além disso tem intenção de manter os dados replicados em sua instância de origem no SQL Server 2017 On-Premises, funcionando como uma espécie de Disaster Recovery.

Essa integração entre o SQL Database e o SQL Server depende do serviço Azure SQL Data Sync que está incorporado no Azure SQL Database. O Azure SQL Data Sync pode ser utilizado para distribuição de dados entre SQL Server, Azure SQL VM e Azure SQL databases, tanto unidirecional quanto bidirecional. Para nosso cenário, utilizaremos esse serviço para sincronização dos dados entre o Azure SQL Database e SQL Server on-premises.

Veja na topologia abaixo o modelo que utilizaremos:

A primeira etapa dessa solução envolve a migração da base para o Azure SQL Database, no qual pode ser feito através do Microsoft Data Migration Assistant (DMA). Vou considerar que essa etapa foi concluída com sucesso e sem restrições, sendo assim, o ambiente no Azure (PaaS) já está preparado.

Veja na imagem acima que uma das opções disponíveis no menu de configurações do Azure SQL Database é o “Sync to other databases” e após acessar essa opção pode ser visto as categorias “Sync Group” e “Sync Agent“.

O Data Sync é baseado no conceito do Sync Group, que é o grupo de bases que você deseja sincronizar. Dentro do Sync Group é definido a base que servirá como “Hub” e as restantes são definidas como membro, dessa forma a comunicação ocorre apenas entre o “Hub” e os membros individuais.

Algumas considerações importantes:

• A base de dados “Hub” precisa ser um Azure SQL Database;
• As bases de dados member podem ser SQL Databases, on-premises SQL Server databases ou instâncias SQL Server em Azure virtual Machines;
• A base de dados Sync contém o metadado e log do Data Sync, sendo necessário ser um Azure SQL Database localizado na mesma região que a base de dados “Hub”;
• Se uma base de dados on-premises for definida como membro, obrigatoriamente deve ser instalado e configurado o “Local Sync Agent“.

Como pode ser visto nas considerações, em nosso cenário será necessário instalar o “Local Sync Agent“, entretanto iniciaremos pela configuração do “Sync Group“.

Selecione a opção de “New Sync Group” dentro do menu “Sync to others databases“, como pode ser visto na imagem anterior. Deve ser preenchido o nome do “Sync Group“, a base de dados que irá receber os metadados, sendo que, é recomendado que uma nova base seja criada exclusivamente para armazenar esses dados, também deve ser selecionado na opção “Automatic Sync“, que define a frequência de atualização dados dados e por último, o “Conflict Resolution” que tem duas opções, “Hub Win” e “Member Win“, caso seja escolhido o primeiro, se algum conflito ocorrer na sincronização os dados da origem (“Hub”) substituem os dados conflitados no destino (“Member”), na segunda opção, ocorre exatamente o inverso.

Após finalizar essa etapa, o Azure vai iniciar o processo de implantação do “Sync Group” e em seguida avançar para a inclusão dos membros no menu “Add sync members“. Nessa etapa o usuário e senha de acesso devem ser preenchidos para a base de dados atual selecionada como “Hub“. Logo abaixo temos disponível a seleção do “Member Database“, que pode ser um Azure Database ou um On-Premises Database, para nosso cenário irei selecionar a segunda opção.

A primeira opção dentro da etapa do “Configure On-Premises” é para fazer a configuração do “Sync Agent Gateway“, sendo assim, vemos criar um novo e para isso devemos fazer o download do SQL Azure Data Sync Agent. A instalação é bem simples e apenas requer um usuário com privilégios para rodar o serviço no Windows.

Após a instalação, devemos retornar ao Azure e preencher o nome do agente para que possa ser gerado a chave de registro do “Sync Agent“.

Retorne ao “Sync Agent” e selecione “Submit Agent Key“, em seguida preencha o “Agent Key” com a chave copiada e também as credenciais de acesso do Azure SQL Database criado anteriormente para os metadados.

O próximo passo será registar o acesso ao SQL Server On-Premises através da opção “Register” no “Sync Agent“.

Uma vez que as configurações foram finalizadas, podemos retornar ao Azure e selecionar “OK” no menu “Select Sync Agent” e retornar ao “Configure On-Premises“. Seguiremos para a opção “Select the Database“, na qual temos que preencher o nome no campo “Sync Member Name“, selecionar o “Sync Agent” recém configurado e o “Sync Directions“. O “Sync Directions” determina a direção que os dados serão sincronizados, no nosso caso utilizaremos o “From the Hub“, ou seja, a base de dados no Azure SQL Database que está configurada como “Hub” será a origem dos dados a serem sincronizados.

Finalize essa configuração através do botão “OK” no menu “Select the Database“, “Configure On-Premises” e “Select sync members“, em seguida o Azure vai iniciar as implementações. Por último, iremos ao menu “Configure sync group” para selecionar as tabelas que serão sincronizadas. Repare que existe um alerta informando que apenas as tabelas com chave primária são suportadas, felizmente a tabela “SalesOrderDetailEnlarged” atende esse requisito.

Após salvarmos a configuração, o Azure irá processar as alterações e retornar para o menu inicial do “Sync to other databases“.

Ao verificar via SSMS as bases do Azure SQL Database, perceba que além da “AventureWorks2017” que já existia, foi adicionada a base de dados “dbsyncmetadata” com os metadados, também foram criados novas tabelas de apoio da solução dentro da base “AventureWorks2017“. Essas mesmas tabelas foram criadas no SQL Server On-Premises.

Agora a solução para atender o cliente está pronta, restando apenas testar o seu funcionamento. Podemos acessar o “Sync Group” e acompanhar os logs para identificar as notificações de erro e sincronização.

Apesar de serem etapas simples, existem muitas limitações que impossibilitam que essa solução seja utiliza para qualquer cenário, é importante que seja feita a leitura de toda documentação do produto, assim como, os devidos testes antes da utilização em produção.

Seguem as referências:

https://docs.microsoft.com/pt-br/azure/sql-database/sql-database-get-started-sql-data-sync

https://docs.microsoft.com/pt-br/azure/sql-database/sql-database-sync-data

https://azure.microsoft.com/pt-br/blog/azure-sql-hybrid-data-movement/

Até a próxima!

BACKUP AUTOMATIZADO DO SQL SERVER COM AZURE VIRTUAL MACHINE

Olá Pessoal!

Um dos benefícios de criar uma instância do SQL Server em uma máquina virtual no Microsoft Azure são as integrações nativas disponíveis no painel do Azure, como é o caso do recurso de Backup Automatizado (Automated Backup). Vamos explorar melhor esse recurso com a demonstração abaixo utilizando uma máquina virtual com o SQL Server 2017.

O SQL Server também está disponível no Azure como IaaS (Infrastructure as a Service), sendo assim, existem alguns modelos para contratação e dentre eles, a opção de criar a máquina virtual a partir de uma imagem que contém a edição desejada do produto.

No processo de criação da máquina virtual, diversos itens devem ser preenchidos até chegar a etapa de configuração do SQL Server, na qual iremos configurar o Backup Automatizado pelo painel do Azure.

Antes de avançar no recurso do Backup Automatizado, vamos relembrar quais opções a Microsoft disponibiliza atualmente para realização do backup em instâncias SQL Server rodando em Azure Virtual Machines (IaaS):

• Backup para URL – Disponível a partir do SQL Server 2012, utiliza o Azure Blob Storage como destino dos arquivos de backup. Mais informações: https://docs.microsoft.com/pt-br/sql/relational-databases/backup-restore/sql-server-backup-to-url?view=sql-server-2017

• Managed Backups – Disponível a partir do SQL Server 2014, configura políticas de backup através de Stored Procedures (TSQL), também tendo como destino o Azure Blob Storage. Mais informações: https://docs.microsoft.com/pt-br/sql/relational-databases/backup-restore/sql-server-managed-backup-to-microsoft-azure?view=sql-server-2017

• Automated Backups – Disponível a partir do SQL Server 2014, apresenta uma interface de configuração para o Managed Backup através de um agente chamado SQL Server IaaS Agent Extension, assim como os anteriores, os arquivos de backups são armazenados no Azure Blob Storage. Mais informações: https://docs.microsoft.com/pt-br/azure/virtual-machines/windows/sql/virtual-machines-windows-sql-automated-backup-v2

• Azure Backup For SQL Server (Preview) – Permite que os backups sejam realizados utilizando o Azure Recovery Services Vault, trazendo uma série de benefícios adicionais. Utiliza o componente VDI (Virtual Device Interface), sendo assim, é similar a um backup feito por uma ferramenta 3º. Mais informações: https://docs.microsoft.com/pt-br/azure/virtual-machines/windows/sql/virtual-machines-windows-sql-backup-recovery

Como foi citado acima, é possível que backups regulares do banco de dados sejam configurados utilizando o armazenamento do Azure Blob Storage, entretanto, para que esse recurso funcione é necessário que a extensão do SQL Server IaaS Agent esteja instalada no host que contém a instância do SQL Server e essa extensão só é compatível para deploys de VMs a partir das imagens disponíveis na galeria de recursos do Azure. A extensão do SQL Server IaaS Agent não será compatível se você instalar o SQL Server em uma máquina virtual do Windows Server somente com o sistema operacional ou se for utilizado um VHD de uma VM do SQL Server personalizada.

Veja na imagem abaixo a extensão SqlIaasExtension.

Voltando a tela de configuração do Backup Automatizado, essa opção deve ser habilitada no menu de configurações do SQL Server ainda no processo de setup do host.

É possível perceber que as seleções disponíveis são bem simples e existe uma opção bem relevante, a “Janela de tempo de backup (horas)”, na qual é definido o tempo máximo disponível para que o backup seja realizado.

Uma vez que a configuração foi concluída, um resumo é apresentado antes de iniciar o processo de criação do host, que deve demorar alguns minutos. Note que uma nova conta de armazenamento foi criada no processo de configuração do host.

Com a máquina criada e a instância do SQL Server em funcionamento, é só uma questão de tempo até que recurso do Backup Automatizado comece a realizar os backups e armazenar os arquivos no Azure Blob Storage. Para verificar os arquivos de backup, vá até a conta de armazenamento utilizada no processo de criação do host e selecione a opção do armazenamento de Blobs.

O contêiner com o nome “backupcontainer” será criado no processo de configuração do Backup Automatizado, é nele que os arquivos de backup do SQL Server são armazenados.

Para leitura dos dados do Azure Storage também pode ser utilizado a ferramenta Microsoft Azure Storage Explorer, que permite uma melhor visão e gerenciamento do armazenamento.

Vamos ao SSMS para buscar através de uma Query as informações dos backups que foram realizados até o momento, veja na imagem abaixo as informações relacionadas ao armazenamento.

Caso deseje alterar as configurações do Backup Automatizado após a host estar criado, basta acessar a opção “Configuração do SQL Server” no painel da máquina virtual.

Ao acessar esse menu, uma série de opções de configuração da instância do SQL Server estarão disponíveis e dentre elas, o Backup Automatizado.

 

Existem limitações e requisitos não abordados aqui que devem ser atendidos para utilização do Backup Automatizado, vejam na documentação oficial todos esses importantes pontos antes da implementação.

Informações adicionais:

https://docs.microsoft.com/pt-br/azure/virtual-machines/windows/sql/virtual-machines-windows-sql-server-iaas-overview#get-started-with-sql-vms

https://docs.microsoft.com/pt-br/sql/relational-databases/backup-restore/sql-server-backup-and-restore-with-microsoft-azure-blob-storage-service?view=sql-server-2017

Até a próxima!

.NET FRAMEWORK RUNTIME FATAL ERROR

Olá Pessoal!

Faz pouco tempo que passei por um problema em uma implementação e tive que recorrer ao suporte do produto junto a Microsoft, vou compartilhar esse caso com vocês.

Durante o processo de teste e ajuste de hardware após a implantação de um ambiente SQL Server 2017 utilizando Always On Availability Groups com dois nós, foi observado failovers ocorrendo de forma inesperada entre os nós. Ao analisar o error log do SQL Server, a seguinte mensagem foi apresentada:

Acontece que o erro gerado causou crash na instância do SQL Server e o failover automático foi acionado imediatamente, por isso da transição das roles entre os nós inesperadamente. Apesar de saber o motivo do failover, ainda não sabíamos por que um erro no componente .NET Framework runtime causou uma reinicialização no serviço do SQL Server e se poderia ocorrer novamente, impactando no ambiente que iria para produção.

Optei por abrir um chamado na Microsoft para apoio na identificação da causa raiz do problema, buscando evitar dessa forma que o mesmo ocorra novamente. Após a solicitação inicial do chamado, o analista responsável pelo ticket solicitou uma série de informações complementares para esclarecer melhor o ocorrido, assim como, entender em quais circunstâncias o Stack Dump foi gerado.

Após verificar os logs do SQL Server e o Dump gerado, o analista percebeu um detalhe relacionado a configuração de hardware. No dia anterior ao ocorrido, foi feito um upgrade de hardware nos hosts com as instâncias do SQL Server, tanto o processador quanto a memória foram alterados utilizando o VMware Hot-Add. Veja abaixo:

Processador e Memória antes

Processador e Memória depois

Foi concluído que durante o evento do crash, o SQL Server detectou 16 sockets com 1 core per socket e 1 logical processor per socket e com um total de 16 logical processors, além de 128GB Ram. A equipe de suporte apontou que já observou alguns casos com esse cenário, no qual o SQL Server falha ao detectar desalinhamento com os processor cores. O crash dump gerado após a falha informa que o erro ocorreu devido a Access Violation. Access Violation conceitualmente ocorre quando um programa executa uma ação em um endereço de memória, no entanto, essa ação não é permitida. A página de memória será configurada com a opção de proteção de memória adequada durante a alocação. Se um aplicativo acessar um endereço de memória que não esteja alinhado com a proteção de página para essa memória, será lançada uma exceção de Access Violation.

Realmente esse caso foi uma exceção e não voltou a ocorrer, atualmente o ambiente está totalmente estável.

Até a próxima!

SQL SATURDAY #792 BRASILIA 2018

Olá Pessoal!

O já tradicional SQL Saturday está de volta a Brasília em mais uma edição recheada de boas palestras com os melhores profissionais de plataforma de dados. Lembrando que este evento é de graça!

Esse ano teremos também uma Pós Conferência – Treinamento com o Fabiano Amorim.

Espero vocês lá, não percam essa oportunidade, mais informações acessem:

http://www.sqlsaturday.com/792/eventhome.aspx

https://www.eventbrite.com.br/e/pos-sqlsat792-investigando-problemas-de-cpu-no-sql-server-tickets-47260300832

Até a próxima!