O processo de ETL funciona em 3 etapas:  

1. Extração; 
2. Transformação; 
3. Carregamento. 

Confira, a seguir, as características de cada uma dessas etapas.

Primeira fase: Extração

Fase destinada à extração de dados SQL. É o momento em que é realizada a análise preliminar através da organização dos dados, convertendo-os em um formato único, com a finalidade de padronização.

Segunda fase: Transformação 

É o momento em que ocorre a adaptação e a limpeza das informações, reunindo somente o que efetivamente será aproveitado para análise. Nessa etapa são criados os filtros, de modo que as informações sejam agrupadas conforme critérios específicos para futuras análises.

Terceira fase: Carregamento

Nesta fase do processo é onde os dados organizados são transferidos para um novo repositório. A tabela é duplicada com a informação tratada e corrigida para impedir novos fluxos de desvio de informação. 

Necessariamente, o ETL não é executado em um único ambiente de tratamento informacional, podendo haver diversas aplicações para todo o processo.

Uma ação muito importante é analisar a janela de operação do ETL, pois não é a qualquer momento que ele deverá ser executado. Deve-se analisar o seu período de execução e definir o alcance dos dados que o ETL irá abranger, para que se tenha sucesso no processo.

O processo de ETL geralmente é usado em:  

• Armazenamento de dados; 
• Machine learning e inteligência artificial; 
• Integração de dados de marketing; 
• Integração de dados de Internet das Coisas (IoT, na sigla em inglês);
• Réplica de banco de dados;
• Migração para nuvem. 

Confira abaixo. 

Armazenamento de dados

Geralmente usado para mover os dados para um banco de dados em que várias origens são combinadas para análise.

Machine learning e inteligência artificial

No aprendizado de máquina, o sistema aprende usando técnicas de inteligência artificial e o ETL atua para mover os dados para um local único com finalidade exclusiva para o machine learning.

Integração de dados de marketing

O ETL atua na coleta e preparo dos dados, envolve mover todos os seus dados de marketing, como clientes, redes sociais e dados de análise da web.

Integração de dados de Internet das Coisas (IoT, na sigla em inglês)

Uma rede de objetos cotidianos físicos, capaz de reunir e de transmitir dados. O ETL ajuda a mover os dados de várias origens de IoT para um único lugar onde você pode analisá-los.

Réplica do banco de dados

O intuito é realizar uma cópia dos dados para a nuvem, pegando os dados dos seus bancos de origem (como Oracle, Cloud SQL para MySQL, Microsoft SQL Server, Cloud SQL para PostgreSQL, MongoDB, etc). Isso pode ser uma operação única ou um processo contínuo à medida que seus dados são atualizados, e o ETL pode ser usado para replicar os dados.

Migração para a nuvem

Usa-se o processo de ETL para executar as migrações dos dados para nuvem.

Conforme vimos, o processo de ETL possibilita a unificação dos dados, permitindo a implementação de uma estratégia de BI para utilização futura. Identificar padrões por meio dos dados é fundamental, pois resulta na compreensão de comportamentos que viabilizam as decisões do negócio.

Implementação de ETL, Rox Partner

Dúvidas para implementar o ETL ou sobre qual ferramenta utilizar nesse processo ou, ainda, se houver qualquer necessidade analítica, a Rox possui todo o suporte necessário! 

Conheça mais sobre as soluções que a Rox oferece e trabalhe os dados a seu favor!  

Aproveite e obtenha mais conhecimentos em nosso blog!

O dbt surgiu em 2016, em uma época quando existiam menos ferramentas em todas as etapas de dados. Mas foi criada para resolver essa dor latente que são a falta de unidade e o problema nas orquestrações de execuções SQL. 

Com o surgimento do Redshift, Big Query, Azure Sinapse, Snowflake e entre outros bancos de dados para Data Warehouse em Cloud e distribuídos, os Projetos de Analytics passaram a ser mais ágeis para serem construídos (antes um projeto poderia levar meses e até anos para ser processado) e mais acessíveis (financeiramente falando). Dessa forma, mais empresas conseguiram o acesso a esse ambiente analítico. Assim, o ecossistema, como um todo, foi beneficiado com essa evolução. Com isso, várias ferramentas apareceram para se conectar com esses Data Warehouse, entre eles o dbt. 

Um dos criadores do dbt, Tristan Handy, fazia parte da empresa RJ Metrics (que foi vendida para a Magento). Nesse contexto, há muito tempo, existiam pessoas envolvidas com analytics, preocupadas e conhecedoras de todo o ecossistema. 

O dbt suporta diversas ferramentas como motor de processamento SQL, entre elas, temos o Snowflake, Teradata, Amazon Athena, prestoDB e entre outras. Algumas das conexões para motores de processamento SQLs foram criadas pelos próprios desenvolvedores do dbt, mas, em sua grande maioria, foi uma contribuição da comunidade. Isso é um ponto muito forte do dbt, que é uma ferramenta Open Source e com um grande apoio da comunidade de desenvolvedores.

O dbt trabalha com alguns princípios básicos, sendo eles: SQL para Desenvolvimento Rápido, Controle de Versão, Trabalho Colaborativo, CI/CD, Teste, Documentação e Linhagem de Dados. Vamos, agora, falar de cada um desses pontos: 

O dbt é uma ferramenta que permite escrever em SQL combinado com uma linguagem de templates chamada Jinja, que possibilita que o código SQL seja reutilizável, modular, com blocos lógicos, condições e entre diversas outras facilidades. 

Além disso, é possível escrever os modelos SQL modulares com instruções SELECT e a função ref() – para referenciar outros modelos de dados já existentes no seu projeto dbt; nesse aspecto, sem se preocupar com o gerenciamento de dependência, já que o dbt lida com esta tarefa.  

Também é possível substituir operações DDL/DML padrão por instruções SQL SELECT simples que inferem dependências, criam tabelas, exibições e executam modelos em ordem.

Com o dbt é possível implementar um pipeline de dados em SQL com segurança usando ambientes de desenvolvimento. O controle de versão habilitado para Git permite a colaboração e um retorno aos estados anteriores, em caso de falha e erros nos deploys. 

Outra característica interessante é o processo de observabilidade em fluxos de trabalho de transformação com agendamento, registro e alertas no aplicativo web do dbt. Neste ambiente, pode-se criar políticas de proteção, garantindo que os dados se movam por meio de processos governados, incluindo ambientes de desenvolvimento, com estágios de desenvolvimento e produção gerados por cada execução de CI.

O dbt permite testes de regressão automatizados para que seja possível garantir que os módulos SQL estejam realizando as transformações corretamente; além disso, garante que os dados de origem e os dados de resultado estejam no formato desejado.  

dbt oferece dois tipos de teste, os Testes de Esquema e os Testes de Dados: 

• Testes de Esquema: declarações, como valores únicos, não nulos, aceitos e relacionados que são adicionados a arquivos .yml no modelo a ser testado. 
• Testes de Dados: consultas SQL personalizadas que podem ser encontradas no diretório test. Os testes personalizados e pré-empacotados do dbt ajudam os desenvolvedores a criar uma “rastreabilidade” de suposições validadas para colaboradores de dados. 

Os recursos de documentação do dbt oferecem a capacidade de definir modelos de dados e suas colunas em um arquivo yaml de “source”, facilitando o acompanhamento das principais definições de dados. 

É possível visualizar a documentação em uma interface web amigável,  por meio de um catálogo de dados, com definições, dependências e a linhagem de dados de todo o ecossistema dbt.

Na visualização do Lineage dos dados do dbt, é possível saber exatamente de onde os dados saíram e para onde eles foram. É possível visualizar a linhagem de dados não somente em termos de entidades de base de dados, mas também em termos de modelos, dependências e processamentos. O dbt possui também o conceito de “Exposures”, em que é possível dizer que determinado dado está disponível, tudo isso em uma visualização em dashboard no Metabase.

Existem dois arquivos principais no dbt, o arquivo profiles.yml e dbt_project.yml. Esses são arquivos exclusivos dessa ferramenta de transformação e fornecem muito poder, permitindo que você personalize o seu ambiente conforme a sua necessidade.  

Os modelos de projetos são definidos no arquivo dbt_project.yml. É  por meio desse arquivo que o dbt sabe que um diretório é um projeto dbt. Ele também contém informações importantes que informam ao dbt como operar em seu projeto. 

O arquivo profiles.yml permite selecionar credenciais exclusivas de suas fontes e destinos de dados. Nestes arquivos, são descritos os perfis de banco de dados que serão conectados, com informações como: no profiles.yml. 

Além desses arquivos, existem algumas características bem definidas na ferramenta dbt, sendo elas: 

• Projeto; 
• Modelo;
• Comandos.  

Existem dois arquivos principais no dbt, o arquivo profiles.yml e dbt_project.yml. Esses são arquivos exclusivos dessa ferramenta de transformação e fornecem muito poder, permitindo que você personalize o seu ambiente conforme a sua necessidade.  

Os modelos de projetos são definidos no arquivo dbt_project.yml. É  por meio desse arquivo que o dbt sabe que um diretório é um projeto dbt. Ele também contém informações importantes que informam ao dbt como operar em seu projeto. 

O arquivo profiles.yml permite selecionar credenciais exclusivas de suas fontes e destinos de dados. Nestes arquivos, são descritos os perfis de banco de dados que serão conectados, com informações como: no profiles.yml. 

Além desses arquivos, existem algumas características bem definidas na ferramenta dbt, sendo elas: 

• Projeto; 
• Modelo;
• Comandos.  

Um projeto dbt é um diretório que contém arquivos .sql e .yml . Os arquivos mínimos necessários são: 

• Um arquivo de projeto chamado dbt_project.yml  – esse arquivo contém configurações de um projeto dbt; 
• Modelo(s) arquivos .sql  – modelo em dbt é simplesmente um único arquivo .sql contendo uma única instrução SELECT . 

Um modelo dbt é basicamente um arquivo .sql com uma instrução SELECT. O modelo denominado “.sql” contém instruções SQL SELECT, que em tempo de execução serão aplicadas aos motores de processamento SQL – Data Warehouse com Snowflake, Redsfift, Big Query etc. ou framework de processamento SQL, como Spar, prestoDB, AWS Athena e entre outros. 

O modelo também define o esquema de nossas tabelas de origem em source e o esquema das visualizações a serem criadas em models.

Os comandos dbt começam com dbt e podem ser executados usando uma das seguintes maneiras: 

• dbt Cloud – a seção de comando na parte inferior do painel dbt Cloud; 
• dbt CLI. 

Alguns comandos só podem ser usados ​​em dbt CLI como dbt init.

• Ferramenta de migração de dados. 
• Engine de processamento de dados: Ele orquestra a execução dos próprios arquivos em SQL e deixa para que o Data Warehouse se encarregue de processar essas consultas.

O dbt oferece uma experiência única para engenheiros e analistas de dados, pois usa instruções SQL SELECT simples para realizar transformações pesadas de maneira limpa e econômica. Seus módulos têm execução competitivamente mais rápida e são fáceis de modificar e testar. A integração do dbt com os modelos e templates, juntamente com a sua capacidade de controle de versão e realização de testes automatizados, torna o processo de transformação de dados mais robusto e seguro. Esta é uma excelente ferramenta de transformação e processamento de dados, empoderando qualquer pessoa na Jornada Data Driven, desde que se sinta confortável com a linguagem SQL.  

No próximo post da nossa série sobre dbt, faremos um tutorial de exemplo, criando modelos, templates, testes e colocando nosso dbt em produção. 

Aproveite e conheça mais em nosso blog!  

Já pensou em ter um banco de dados quase 100 vezes mais rápido do que o principal e mais caro banco de dados do mercado? E sem gastar um centavo com licenciamento? É isso que o MongoDB te oferece! Ele é um NoSQL extremamente fácil de se trabalhar e é Open Source (código aberto) sob a licença GNU AGPL3. Essa licença lhe permite usar seu aplicativo comercial distribuído como serviço, sem precisar compartilhar o código. Desta forma, todo mundo que quer usar o MongoDB em um serviço comercial está amparado pela sua licença.

Uma das aplicações mais comuns que vemos no uso do MongoDB é em arquitetura de microsserviço. É muito rápido e simples subir uma instância única de MongoDB para atender o seu serviço. Na outra ponta, também é muito comum vermos grandes clusters de MongoDB com dezenas de máquinas rodando simultaneamente em empresas. Isto porque o MongoDB é altamente escalável e extremamente disponível. Com o MongoDB, você pode começar pequeno e quando necessário, aumentar sua capacidade rapidamente, atendendo a real demanda da sua aplicação. 

Hoje, todos os principais provedores de cloud oferecem a você serviços de MongoDB gerenciado. Isso significa que você pode provisionar o seu MongoDB como serviço, sem se preocupar com o gerenciamento do seu cluster de Mongo. Existe ainda a possibilidade de utilizar o MongoDB Atlas, que é o serviço provisionado pela própria Mongo, empresa responsável pelo desenvolvimento do banco.

MongoDB possui diversas features muito legais, que nem todos os NoSQL possuem. Uma delas, por exemplo, é o suporte a transações ACID sobre múltiplos documentos de forma simultânea. Ele possui também a capacidade de realização de queries sobre qualquer campo do documento, inclusive campos em arrays e estrutura alinhadas. Ainda possui features de indexações, como a indexação secundária, que pode tornar suas queries muito mais rápidas e eficientes. Ele também suporta nativamente agregações e ordenação em queries.  

Para você que é desenvolvedor, diversos pacotes em sua linguagem favorita são disponibilizados pela comunidade. Um exemplo disso é que você pode escolher trabalhar diretamente com JSON dentro do Mongo ou pode usar o seu ORM favorito. 

Diversas outras features são oferecidas pelo MongoDB, mas eu gostaria de citar mais uma apenas, o GridFS. Essa feature possibilita você armazenar documentos extremamente grandes. Por deafult, você pode armazenar documentos de até 16MB no MongoDB, mas, caso precise de ainda maiores, o GridFS pode ser muito útil para você.

Apesar da sua grande popularidade, ainda não é tão comum encontrar no mercado profissionais como DBAs especializados em MongoDB. Essa é uma demanda cada vez mais comum em grandes projetos, principalmente quando é necessário aumentar a escala do seu cluster MongoDB, aplicar boas práticas, melhorar particionamento, sharding, replicas sets e entre outras características do seu cluster de MongoDB para aprimorar ainda mais o desempenho do seu banco de dados. Pensando nisso, a Rox desenvolveu um time especializado na manutenção, suporte e melhorias em MongoDB, seja on-primese ou na sua cloud favorita. Somos especializados em todo o ciclo de vida de dados e temos, além dos melhores DBAs em MongoDB, uma equipe completa especializada em infra-estrutura, cloud computing, DevOps, e banco de dados em geral. Com a Rox você pode focar no desenvolvimento das suas aplicações e ficar tranquilo com o suporte, manutenção e melhoria do seu ambiente de banco de dados NoSQL com MongoDB graças aos nossos especialistas. Não deixe de conversar conosco. 

Quer saber como podemos te ajudar? Clique aqui! 

IMPORTANTE: Para que nossa replicação funcione, não podemos esquecer dos seguintes parâmetros:

bindip: com o ip da máquina local, no exemplo da minha instância primária ficou bindIp: 127.0.0.1,192.168.15.6.

authorization: enabled = Habilitar a autenticação obrigatória no MongoDB, assim não sendo possível conectar sem passar usuário e senha.

keyFile: /home/mongodb/keyFile/mongo-key = Nossa chave de autenticação

replSetName: replicaset01 = O nome da nossa replicação, manter comentado com um # por enquanto.

Após configurar no MongoDB primário e secundário, vamos criar um usuário admin no nosso MongoDB primário, pois, como ativamos a opção de autenticação, será necessário a criação deste.

No meu caso, criei o usuário “admin” com senha “admin” na role “root” dentro do db “admin”.

IMPORTANTE: Lembrando que meu ambiente é de teste. Na realidade, configurar um usuário e uma senha com maior complexidade.

Após isso, realizar o reinício da instância.

Para conectar, passar usuário e senha e o authenticationDatabase.

Validei que o acesso está funcionando no meu caso.

Agora que a mágica acontece! Vamos converter nossa instância do servidor mongodb01 em Replica Set. No arquivo de configuração, descomentaremos as linhas replication: e replSetName: replicaset01 e realizar o reinício da instância.

Conectado com o usuário admin, execute:

E validar também a configuração do Replica Set.

Neste momento, adicionaremos o secundário.

Neste caso, você pode adicionar o IP e a porta da seguinte maneira:

Vamos validar os membros do Replica Set.

Observe que a replicação já adicionou meu secundário, porém apresenta uma mensagem de falha de conexão. Isso ocorreu pois ainda tenho que descomentar os parâmetros de chave e replicação na instância mongodb02 e reiniciá-la.

Após isto, a replicação conectou nos dois Nodes.

Observe que, no secundário, eu executei o rs.slaveOk() (que está sendo substituído pelo rs.secondaryOk()), já que, por se tratar de um secundário, não conseguimos executar os mesmos comandos que na instância primária, a não ser que você mesmo execute.

Nossa replicação já está funcionando, mas, dessa forma, podemos ter chaveamento entre primário e secundário. No meu caso, eu quero manter o mongodb01 como primário e o mongodb02 como secundário. Sendo assim, vamos executar os seguintes comandos no primário.

Com isso, nossa replicação está configurada com sucesso. Você pode testar o sincronismo criando dbs.

Aqui executei o comando para criação do db que no exemplo chamei de roxdb.

E está feito! Espero que tenham gostado e contem para gente como foi sua experiência configurando seu Replica Set.

O procedimento para realizar o backup log também é extremamente simples. Basta que o banco atenda as particularidades mencionadas anteriormente.

1. Para fazermos o backup, temos que selecionar com o botão direito o nome do banco de dados > Tarefas > Fazer Backup
   
2. Será aberta a mesma janela do backup full. Contudo, nesse caso, iremos realizar algumas alterações, ficando dessa forma:
   
3. Em azul – Banco de dados: Neste campo, informamos o nome do banco que será feito o backup.
   Em verde – Tipo de Backup: Neste campo, informamos o tipo de backup que desejamos realizar. Como neste caso iremos realizar o backup log, portanto, iremos selecionar “Log de Transações”
   Em vermelho – Diretório: Neste campo, informamos o local em que queremos armazenar nosso arquivo de backup. Assim como no backup full, iremos armazenar em Program Files\Microsoft SQL Server\MSSQL15.InstanceName\MSSQL\Backup.

IMPORTANTE: Diferente do backup full, a extensão usada para o backup log é a .trn. Assim como exemplo da imagem acima, sublinhado em vermelho.

Dentre os três backups apresentados, o backup diferencial é o que menos é usado. Porém, isso não significa que ele não seja importante e, da mesma forma que os outros, é usado outro cenário. Seu nome já nos dá uma dica de qual é o seu propósito e como ele funciona.

O backup diferencial faz o backup do banco desde o último backup full executado. Isso é chamado de base do diferencial.

Para ficar mais simples de entender, podemos usar a imagem abaixo:

Todo o contorno da linha preta (incluindo as partes em vermelho e verde) – É o nosso banco de dados.

Parte vermelha – É o backup full. Assim como mostrado na imagem abaixo, efetuamos o backup do banco db_sistema no dia 04 de fevereiro de 2022 às 23:57 horas.

Parte verde – É o backup diferencial, que pega a diferença entre o último backup full realizado e o estado recente do banco de dados.

Ou seja, o backup diferencial tende a ser mais rápido, isso porque ele não faz o backup do banco de dados inteiro, somente da diferença.

Então, imagine que vamos rodar o backup diferencial às 10:00 horas do dia 05 de fevereiro de 2022. Ele vai fazer o backup do que foi alterado após às 23:57 horas do dia 04 de fevereiro de 2022 até às 10:00 horas do dia 05 de fevereiro de 2022.

Partindo do pressuposto que o seu banco de dados está com os backups full e log, ou até mesmo o diferencial, em dia, não há motivos para se preocupar exceto um, que pode lhe causar uma imensa dor de cabeça e atrapalhar o fluxo do seu negócio.

Como dito anteriormente, o banco de dados está suscetível a erros ou até mesmo situações em que são inseridos, alterados e/ou apagados determinados dados de forma equivocada. Felizmente, o seu banco está com os backups em dia. Então, fique feliz, pois há salvação e é extremamente possível recuperá-lo antes do erro ou ponto de falha, perdendo a menor quantidade de dados possível.

Nesta parte do artigo, vamos aprender como recuperar os backups do banco de dados, conseguindo reverter alguns desastres e erros.

Primeiro, é importante ressaltar que, uma vez que o banco e seus dados foram comprometidos, o mesmo terá que ser sobrescrito, ou seja, revertido para um estado anterior.

Para os exemplos, iremos utilizar o AdventureWorks2019 que é gratuito e disponibilizado pela Microsoft para fins de testes e aprendizados.  Conseguimos baixar o arquivo .bak no seguinte link: Bancos de dados de exemplo do AdventureWorks – SQL Server | Microsoft Docs

1. Na sua instância SQL Server, clique com o botão direito em Bancos de dados > Restaurar Banco de Dados
   
2. Será aberta a seguinte tela.Note que não há nenhum arquivo de backup escolhido. Para escolher o arquivo, basta selecionarmos os componentes marcados em vermelho, conforme as imagens abaixo:
   
   
3. Nesta tela, temos que ter atenção em alguns pontos:
   • Primeiro: É importante informar no campo “Local do Arquivo de Backup” (linha azul) o diretório em que está armazenado o arquivo .bak do banco de dados que você está tentando restaurar. Sem isso, o SQL não saberá qual arquivo será restaurado e o restore falhará. No meu caso, baixei o arquivo do banco AdventureWorks e coloquei no diretório padrão de backups do SQL, mas o local onde irá armazená-lo fica a seu critério.
   • Segundo: Selecionar o arquivo de backup que deseja restaurar (linha vermelha). Para nosso exemplo, iremos selecionar o bak;
   • Terceiro: Concluído os dois passos anteriores, podemos clicar em “OK” (linha verde) e OK novamente na próxima tela;
     

4. Feito isso, você deve receber a tela da seguinte maneira. Note que ele reconheceu o dispositivo em que estamos pegando o arquivo de backup (C:\Program Files\Microsoft SQL Server\MSSQL15.CARLOSMENDES\MSSQL\Backup\AdventureWorks2019.bak), o nome do banco de dados (AdventureWorks) e a data na qual foi feito o backup (segunda-feira, 15 de junho de 2020 às 20:26:36).
   
5. Caso quisessemos, poderíamos alterar o nome do banco de dados e restaurá-lo com outro nome, mas nesse caso não será necessário.
6. Por fim, basta clicar em “OK” e você deve receber a seguinte mensagem de sucesso, conforme a imagem abaixo:
   
7. Agora, conseguimos ver que o banco está em nossa instância SQL foi recuperado com êxito.
   Obs.: Caso não apareça o banco, basta clicar com o botão direito em Banco de dados > Atualizar (Refresh) e ele deverá aparecer.
   

Como falamos antes, a recuperação de um banco de dados visa, acima de tudo, voltar o banco ao estado antes da falha ou do erro que aconteceu. Acontece que, dependendo do tamanho do banco de dados e de quando foi feito o último backup full, a perda de dados pode ser gigante. Para entender melhor, vamos montar o cenário, aplicando com a prática.

Supondo que meu banco restaurado há pouco, AdventureWorks, seja meu banco de produção, extremamente crítico, com diversas transações e processos em execução. Eu faço o backup full dele diariamente, durante a madrugada, pois o banco é grande e demora para concluir o backup. Então, eu executo o backup full do meu banco de dados às 02:00 horas.

Imagine que este banco está recebendo conexões e processos normalmente. Em um dado momento, preciso que seja criada a tabela “funcionário”. Sendo assim, executo a DDL de criação da tabela e começo a popular a mesma, conforme o exemplo abaixo:

Agora, iremos dropar a tabela criada anteriormente, com o comando DROP TABLE. Note que ao executar o comando select na tabela “funcionário”, recebemos o erro do Database Engine informando que a tabela não existe no banco.

Ou seja, tínhamos criado uma tabela chamada “funcionário” e populamos ela com dados. Mas, após o drop, ela não existe mais. Você pode até estar pensando: “Ok, só precisamos restaurar o backup full do banco de dados”. Contudo, a tabela “funcionario” foi criada após o backup full. Se restaurássemos, não teríamos a tabela de volta.

Por sorte, fomos precavidos e rodamos o backup log após a criação da tabela e, com ele, conseguimos restaurar o banco de dados até o momento em que o drop table ocorreu. Primeiro, temos que ter em mente que, para restaurar um backup log, devemos primeiro restaurar o último backup full que foi executado, e após isso, aplicar os arquivos de log até o momento em que a tabela foi apagada. Então vamos lá!

Vamos restaurar um backup full, da mesma forma que restauramos o banco AdventureWorks2019, mas dessa vez, ao invés de fazermos via tela gráfica, faremos via script. Isso porque nesse caso, como iremos restaurar um log por cima, precisamos nos atentar em alguns pontos e adicionar alguns comandos.

1. Seguindo o passo a passo para recuperar um backup full, antes de clicar em “OK”, vamos clicar em Script > Janela do Editor de Nova Consulta
   
2. Com isso, teremos o seguinte script:
   
   Segue script:
   USE [master]
   ALTER DATABASE [AdventureWorks2019] SET SINGLE_USER WITH ROLLBACK IMMEDIATE /* –> Estamos alterando o banco de dados para usuário único, fazendo com que asconexões abertas com o banco que será restaurado sejam encerradas, e as transações em andamento sejam revertidas; */
   RESTORE DATABASE [AdventureWorks2019] /* –> Comando para restaurar o banco de dados (Informa o banco de dados que vamos restaurar — banco destino); */
   FROM  DISK = N’Backup Path’ /* –> Informa qual é o backup que está sendo resturado; */
   WITH  FILE = 1, /* –>  Informa a partir de qual datafile será realizado o restore (Quando = 1, significa que será usado o datafile primário (primary) — .MDF); */
   NOUNLOAD,
   NORECOVERY, /* –> Permite que mais sequências de backup sejam restauradas; */
   REPLACE, /* –> Significa que o banco de dados será sobrescrevido; */
   STATS = 5 /* –> Porcentagem de progresso que será informada durante o restore (Quando = 5, significa que o SQL mostrará a porcentagem de progresso do restore de 5 em 5); */
   GO
3. Vale lembrar que é extremamente importante colocar a opção Isso porque ela vai permitir que posteriormente, consigamos restaurar o backup log após o backup full.
   1. Como vimos acima, o restore foi executado com sucesso. Sendo assim, o banco de dados que estamos recuperando, AdventureWorks2019, deverá ficar com o status “Restoring” (Restaurando). Dessa forma:
      
   2. Muito bem, agora temos que restaurar o backup log. Para fazermos isso, temos que clicar com o botão direito em Tarefas > Restaurar > Log de Transações
      
      
   3. Com isso, você deverá ver a seguinte tela. Para escolhermos o arquivo de log que vamos restaurar, devemos marcar o checkbox “Do dispositivo:” e clicar no quadrado marcado em vermelho e depois em “Adicionar” como mostra as imagens abaixo:
      

    

4. Assim como na recuperação do backup full, temos que escolher o arquivo que iremos restaurar. Mas dessa vez, iremos escolher o backup log que fizemos anteriormente, logo após criarmos a tabela “funcionario”. Após selecionado clique em “OK” e depois em “OK” novamente.
   
   1. Feito isso, clicaremos em Script > Ação do Script para a Nova Janela de Consulta
      
   2. Assim, o script deverá aparecer em uma nova janela de edição de query:
      
      Note que foi aberto em uma sessão diferente. É importante que você copie e cole o script na mesma sessão em que você rodou o restore do backup full. Desta vez, sem a opção norecovery. Isso porque queríamos resgatar apenas este backup log. Contudo, quando for restaurado mais de um backup log, sempre deverá ter a opção norecovery, deixando apenas o último arquivo que será restaurado sem essa opção. Dessa forma, o Database Engine entende que não há mais sequências de backup para serem restauradas, e que o banco pode enfim entrar em uso.
   3. Por fim, quando executado com sucesso, deverá receber algo como isto:
      
   4. Se você verificar o banco de dados AdventureWorks2019, ele não está mais com o status “Restoring” (Restaurando), estando finalmente online novamente.
      
   5. Agora, chegou o momento de verificarmos se a tabela “funcionario” que havia sido excluída, está de volta, executando o seguinte script:
      
      USE AdventureWorks2019
      GO
      SELECT *FROM FUNCIONARIO
   6. Podemos notar que a tabela está no banco de dados novamente e com os registros que foram inseridos logo após sua criação.
      
      Assim, podemos ver a importância de sempre estar com o backup full e log em dia. Isso porque, quando esses eventos de desastre no banco de dados surgirem, será possível recuperar o que foi perdido de forma mais assertiva e pontual. Mesmo tendo suas particularidades, todos os tipos de backup (full, log e diferencial) possuem o mesmo objetivo e ajudam a garantir a segurança das informações em caso de comprometimento da integridade do banco de dados. Além disso, também vimos que é possível recuperar estes backups, retornando o estado do banco no momento específico antes de algum erro cometido. Por isso, mantenha sempre seu ambiente SQL Server com os backups em dia, para que em caso de falhas ou outros problemas que interfiram no seu banco de dados, a margem de perda de dados seja a menor possível.

    

Agora vamos falar sobre comandos do tipo DML. DML é uma abreviação de Data Modification Language (Linguagem de modificação de Dados). Esta é uma linguagem que resgata, guarda, modifica, insere, deleta e atualiza dados no banco de dados. Exemplo disso são comandos do tipo SELECT, UPDATE, INSERT, DELETE e etc.

O que difere os processos de DML dos processos de DDL, é que, no DML, em paralelo atua também o Transaction Manager. Quando o Buffer Manager recebe uma requisição de alteração, ela encaminha antes ao Transaction Manager para que este guarde um log desta transação para que só então guarde as páginas em cache.

O Transaction Manager possui dois componentes para garantir a consistência da requisição: O Lock Manager e o Log Manager. O Lock Manager gerencia a concorrência de dados através de locks e o Log Manager armazena de fato o log da transação no logfile. Esse tipo de processo é chamado de WAL (Write-ahead Logging).

Mas, neste processo, ainda falta alguém. De maneira análoga, o Buffer Manager está para o Buffer Pool assim como o Transaction Manager está para o Transaction Log! O Transaction Log, utiliza o logfile através dos VLF’s (Virtual Log Files) para armazenar e ordenar esses dados “recuperáveis”. Essa arquitetura é relativamente simples e a receita que o SQL Server usa é basicamente o seguinte:

• Se o próximo crescimento for menor que 1/8 do tamanho físico do log atual, crie 1 VLF que abranja o tamanho do crescimento (começando com SQL Server 2014 (12.x))
• Se o próximo crescimento for maior que 1/8 do tamanho atual do log, use o método pré-2014:
• Se o crescimento for menor que 64 MB, crie 4 VLFs que abranjam o tamanho do crescimento (por exemplo, para um crescimento de 1 MB, crie quatro VLFs de 256 KB)
• Se o crescimento for de 64 MB a 1 GB, crie 8 VLFs que abranjam o tamanho do crescimento (por exemplo, para um crescimento de 512 MB, crie oito VLFs de 64 MB)
• Se o crescimento for maior que 1 GB, crie 16 VLFs que abranjam o tamanho do crescimento (por exemplo, para um crescimento de 8 GB, crie dezesseis VLFs de 512 MB)

E com isso, finalizamos mais um artigo. Os métodos de Recovery (recuperação) serão abordados em outra ocasião, pois é um processo um tanto quanto extenso.

Então, fique atento ao Blog da Rox, pois em breve será publicada a parte 3 deste conteúdo superinteressante.

Até a próxima e se inscreva em nossa newsletter!

Tão importante quanto ter um modelo de troubleshooting desenhado, é entender o que levou a acontecer o incidente. Muito se pode entender do problema, olhando todos os pontos da execução da requisição, e esse é o intuito deste artigo: explorar todo o ciclo de vida de uma query. Entre a solicitação do usuário e a entrega do resultado, muita coisa acontece no SQL Server e é o que veremos a seguir.

Protocol Layer

Tudo começa quando um usuário envia uma solicitação via SNI( SQL Server Network Interface) ao banco de dados a partir de uma query, e aqui vamos utilizar o exemplo de uma instrução do tipo SELECT. Esta solicitação é encaminhada ao SBGD através de um protocolo denominado TDS (Tabular Data Stream) que fica responsável por “desembrulhar” este pacote no client e analisar o que está sendo solicitado. Este mesmo protocolo é o responsável por retornar o resultado ao solicitante ao fim da execução.

Relational Engine – Command Parser

O próximo componente é o Command Parser e é onde a “mágica” começa. Nesta camada, o SQL lida com eventos de T-SQL, analisando sua sintaxe e devolvendo caso haja quaisquer erros de volta à camada do solicitante. Com a sintaxe validada, o próximo passo é criar um plano de execução ou reaproveitar um plano ja existente no Plan Cache. Neste caso é criado uma hash do T-SQL para verificar nesta partição do Buffer Pool se há um plano adequado. se houver, a instrução é designada diretamente ao Query Executor, e falaremos mais sobre ele logo abaixo.

Relational Engine – Query Optimizer

“Beleza, mas e se não houver um plano adequado para a solicitação?”, Neste caso o CMD Parser gerará uma árvore de consulta baseado no T-SQL e enviará à camada do Query Optimizer. Esta camada é uma das mais complexas e “misteriosas” do SQL Server. ele avalia a árvore baseando-se em custos e o objetivo é encontrar o plano mais eficiente, ou seja, um plano que terá o menor custo de execução. Em um plano, cada operador tem um custo de linha de base, que é então multiplicado pelo tamanho da linha e pelo número estimado de linhas para obter o custo desse operador — e o custo do plano é o custo total de todos os operadores. Este “Custo” é apenas um número arbitrário utilizado para representar o custo de recurso do plano em questão.

Esta otimização ocorre em 3 fases e são elas:

• Fase 0 — Durante esta fase, o otimizador analisa os NESTED LOOP JOINS e não considerará operadores de paralelismo. O otimizador vai parar aqui se o custo do plano que encontrou for < 0.2. Um plano gerado nesta fase é conhecido como um processo de transação, ou TRIVIAL PLAN (Plano Trivial).

• Fase 1 — A Fase 1 usa um subconjunto das possíveis regras de otimização e procura padrões comuns para os quais já possui um plano. O otimizador vai parar aqui se o custo do plano que encontrou for < 1.0. Planos gerados nesta fase são chamados de QUICK PLAN (planos rápidos).

• Fase 2 — Esta fase final é onde o otimizador puxa todas as paradas e é capaz de usar todas as suas regras de otimização. Ele também olha para o paralelismo e as visualizações indexadas (se você estiver executando a Enterprise Edition) – FULL PLAN (otimização TOTAL).

Relational Engine – Query Executor

E assim chegamos ao Query Executor. Este componente é o responsável por de fato executar a query, trabalhando por cada etapa do plano e devolvendo o resultado ao usuário. Nesta parte do ciclo, há uma interação com o mecanismo de armazenamento para recuperar ou modificar dados. E nesta parte há diferenças entre instruções DML e DDL. Iremos explorar esta diferença no próximo artigo com mais detalhes.

Com isso, chegamos ao fim deste artigo. Espero que tenham gostado e nos vemos no próximo capitulo.