Automatizando Teste de Restore - Implementação


Fala galera, tudo certo?

Hoje vamos dar continuidade ao assunto do final de semana passado, o DRS. E hoje você já vai colocar ele para funcionar aí no seu lab. Quem caiu direto nessa postagem, corre que ainda dá tempo de ver a postagem do final de semana passado e entender um pouco mais o que irá acontecer por aqui. Caso queira passar por lá depois, agora iremos iniciar a implementação de uma ferramenta que estou desenvolvendo para automatizar o RESTORE DATABASE no SQL Server.

Para implementação, irá precisar de duas instâncias SQL Server, uma simulando o ambiente de PRODUÇÃO, e outra o ambiente de teste, dev, homologação... Só que pelo amor do tio Bill, não vai fazer isso no seu cliente agora, vamos entender como funciona primeiro.

A primeira coisa que você vai fazer é clicar AQUI para baixar os arquivos no repositório do github, recomendo criar a seguinte estrutura de pastas e depois se achar necessário pode fazer as alterações -> C:\app\DRS\ <- Dentro da pasta DRS você joga todas as outras pastas e arquivos que pegou do git.

Pode ficar tranquilo que todos os scripts necessários estão na pasta Scripts que você pegou do git.

Procedimentos para instância de produção:

Etapa 1 - Criar banco de dados Traces (Caso já exista, pode pular esta etapa)
Lembre de mudar o destino dos arquivos para um local em seu lab.

Encontre mais utilidades para o banco de dados Traces no blog do Fabricio.



Etapa 2 - Criar tabela BACKUPQUEUE no banco de dados Traces




Etapa 3 - Criar usuário RestoreTeste (Em cliente, de uma atenção para as políticas de segurança)



Agora vamos para a instância de teste:

“Aaah Natan, só posso implementar se tiver duas instâncias? ” Não! Consegue implementar com uma só, mas eu não recomendo deixar todos processos no ambiente de produção. Todavia, basta pular as Etapas 4 e 5, prosseguindo com as demais na única instância.

Etapa 4 - Criar o banco de dados Traces no ambiente de teste. O diretório tem que ser diferente do Traces criado em produção, ou o nome dos arquivos terão de ser diferentes;

Etapa 5 - Criar usuário RestoreTeste na instância de teste (Mesmo Usuário e senha de produção);


Etapa 6 - Criar procedure sp_FileRestore no banco de dados Traces



São passados como parâmetros a peça de backup (@ORIGEM) e os diretórios para onde queremos que os arquivos MDF, NDF e LDF sejam armazenados.
Em seguida é criada uma tabela temporária para armazenar os dados obtidos por meio do RESTORE FILELISTONLY.
Por fim são geradas as linhas para cada um dos tipos de arquivos caso eles existam dentro da peça de backup. O arquivo batch irá se encarregar de executar este procedimento e gerar o script de restore.


Etapa 7 - Criar procedure sp_DropRestore no banco de dados Traces



Após a ferramenta efetuar o Restore, temos a opção de eliminar o banco restaurado, então criei este procedimento para garantir que um banco que não faz parte do processo não seja eliminado.
Antes do drop é verificado se o owner do banco é o mesmo owner responsável pelo processo de restore, portanto, se o banco for de outro owner, não será eliminado.
Na linha 10 após o DATEADD você vai encontrar o valor -2. Isso indica que só os bancos restaurados até duas horas para trás poderão ser eliminados. Este valor terá de ser ajustado conforme as peculiaridades do seu ambiente, como exemplo, um banco de dados levar mais de 2 horas para ser restaurado.

Agora vamos para o arquivo de configuração da ferramenta config.bat, que fica em C:\app\DRS\config. Ele é um batch, então abra com o editor de texto.

Clique para exibir config.bat



Caso você tenha apenas uma instância, colocar o mesmo valor para as linhas 7 e 10;

Na linha 19 é o diretório de TODAS as peças de backup, o padrão do nome das peças deverá ser:
Ex: Meubanco_aqui_não_faz_diferença.bak
Ex: Financeiro_backup_2018_12_02_145703_4868281.bak

Para as linhas 40, 43 e 46, informar o local desejado para que os arquivos do banco restaurado sejam armazenados.

É de extrema importância verificar se o usuário que irá executar o batch possui as permissões necessárias para manipular os arquivos no disco C e no diretório de backup, e para o diretório de backup o usuário responsável pelo serviço da instância também tem que ter os privilégios para manipulação.

Se quiser manter os bancos restaurados, basta comentar a linha 85 do source.bat:

Clique para exibir o trecho



Para não ficar uma postagem muito longa, não vou comentar sobre cada trecho do source.bat, mas deixei todas as etapas comentadas dentro do arquivo e sigo a disposição para quaisquer dúvidas.

Pronto, implementado! Agora é só executar o source.bat localizado em C:\app\DRS\source. Para mostrar o resultado a vocês eu optei por manter os bancos restaurados, o arquivo disponível no Git irá remove-los.


Segue o resultado:

Log gerado
== Inicio do processo ==
 
== Populando semaforo ==
 
- Bases qualificadas :
Financeiro                    
RH                            
Vendas                        
 
== Restore atual ==

- Nome Original da base : Financeiro
- Nome Restauracao da base: Financeiro_DRS
- Peca utilizada: D:\backup\Financeiro\Financeiro_backup_2018_12_08_161404_0804874.bak
- Data de inicio: 2018_12_09_14_31_34 
- Script de restore: C:\app\DRS\temp\ScriptRestore_Financeiro.sql
- Status do restore:

10 percent processed.
20 percent processed.
30 percent processed.
40 percent processed.
50 percent processed.
60 percent processed.
70 percent processed.
80 percent processed.
90 percent processed.
100 percent processed.
Processed 26288 pages for database 'Financeiro_DRS', file 'Financeiro' on file 1.
Processed 2 pages for database 'Financeiro_DRS', file 'Financeiro_log' on file 1.
RESTORE DATABASE successfully processed 26290 pages in 0.943 seconds (217.803 MB/sec).

- Data de Termino: 2018_12_09_14_31_37 

== Fim do Restore ==
 
 
== Restore atual ==

- Nome Original da base : RH
- Nome Restauracao da base: RH_DRS
- Peca utilizada: D:\backup\RH\RH_backup_2018_12_08_161404_2305869.bak
- Data de inicio: 2018_12_09_14_31_37 
- Script de restore: C:\app\DRS\temp\ScriptRestore_RH.sql
- Status do restore:

10 percent processed.
20 percent processed.
30 percent processed.
40 percent processed.
50 percent processed.
60 percent processed.
70 percent processed.
80 percent processed.
90 percent processed.
100 percent processed.
Processed 26288 pages for database 'RH_DRS', file 'RH' on file 1.
Processed 2 pages for database 'RH_DRS', file 'RH_log' on file 1.
RESTORE DATABASE successfully processed 26290 pages in 0.897 seconds (228.972 MB/sec).

- Data de Termino: 2018_12_09_14_31_40 

== Fim do Restore ==
 
 
== Restore atual ==

- Nome Original da base : Vendas
- Nome Restauracao da base: Vendas_DRS
- Peca utilizada: D:\backup\Vendas\Vendas_backup_2018_12_08_161404_3704580.bak
- Data de inicio: 2018_12_09_14_31_40 
- Script de restore: C:\app\DRS\temp\ScriptRestore_Vendas.sql
- Status do restore:

10 percent processed.
20 percent processed.
30 percent processed.
40 percent processed.
50 percent processed.
60 percent processed.
70 percent processed.
80 percent processed.
90 percent processed.
100 percent processed.
Processed 26288 pages for database 'Vendas_DRS', file 'Vendas' on file 1.
Processed 2 pages for database 'Vendas_DRS', file 'Vendas_log' on file 1.
RESTORE DATABASE successfully processed 26290 pages in 0.886 seconds (231.815 MB/sec).

- Data de Termino: 2018_12_09_14_31_43 

== Fim do Restore ==
 
 

== Fim do processo. Não existem bases para restauração. ==




No diretório C:\app\DRS\log você encontrará o log de todo o processo.

E no diretório C:\app\DRS\temp podera ver os scripts utilizados para o restore.

Caso o processo sofra alguma falha por falta de permissão, primeiro verificar o arquivo de log e se necessário os scripts de restore.


- Natan, eu não tenho espaço em disco para fazer o restore da minha base;
- Não tenho duas instâncias para executar este processo e achei agressivo para a produção;
- Queria executar este teste de restore de outra forma, existe?

Sim, existe! Esta outra forma é o RESTORE VERIFYONLY, onde o backup é verificado, mas NÃO é restaurado. Ele verifica se a peça de backup está completa e se consegue ser lida sem realizar a verificação da estrutura de dados, assim chegando o mais próximo de uma restauração real.

Na próxima postagem, irei disponibilizar o script para automatizar o RESTORE VERIFYONLY, para que seja executado em todas as peças desejadas.

Como a ferramenta ainda esta em desenvolvimento, sempre irei manter as alterações comentadas no Git e quando necessário, comento sobre elas por aqui.

**Homologado no SQL SERVER 2017. Para versões anteriores, ajustes poderão ser necessários na tabela temporária "#backupdetails" presente na procedure "sp_FileRestore"

Por hoje é isso galera, toda forma de interação é bem-vinda, abraços,
Natan Rocha.


Comentários

Postar um comentário

Postagens mais visitadas deste blog

Automatizando Teste de Restore - Introdução