Olá humanos,
Nesse post quero compartilhar com vocês alguns Casos do Dia a Dia relacionados ao RESTORE de bases de Teste, o que é uma atividade comum em muitos ambientes e consultorias que nós atuamos.
“Mas Luiz, é só fazer o RESTORE da base de teste e pronto! Certo???”
Então… não é bem assim jovem! Vou explicar melhor, citar alguns exemplos e os possíveis problemas.
Todo DBA vai precisar fazer um RESTORE algum dia. Já fiz alguns posts sobre isso, se você ainda não viu, confere lá!
https://luizlima.net/instant-file-initialization-x-tempo-restore/
https://luizlima.net/category/sql-server/restore/
É muito comum um cliente pedir para fazer o RESTORE de uma base de Teste para que ele possa fazer a homologação de algum projeto / alteração antes de subir isso na produção, ou mesmo para recuperar alguns registros de uma determinada data ou tabela (olha o DELETE SEM WHERE aí). Portanto, nossa missão será fazer o RESTORE dessa base de Teste.
Então vamos lá!
Local:
Infelizmente, nem todos os clientes tem condições para conseguir restaurar uma base de Teste devido a limitações de espaço. Isso é muito crítico, pois nesses casos nós não conseguimos nem testar se os Backups estão íntegros. Já pensou alguém fazer um DELETE SEM WHERE na tabela principal do negócio e não for possível fazer um RESTORE para recuperar esses dados? Viu só como isso pode ser muito crítico?
O melhor caso é quando o cliente possui algum servidor separado para Teste / Homologação, pois se der algum problema a produção não será afetada!
O outro caso é quando as bases de Teste são restauradas no mesmo servidor que as bases de Produção. Aqui vamos precisar ter mais atenção, pois podemos ter alguns problemas.
Problema:
Muitas vezes as bases de Teste ficam no mesmo local que as bases de produção. Com isso, podemos ter problemas que podem afetar as bases de produção e causar perdas para os clientes. Aqui cito a questão do espaço em disco e o compartilhamento de recursos (I/O, memória e CPU). Por exemplo, o cliente vai testar uma rotina muito pesada na base de Teste durante o dia e essa rotina consume muitos recursos do servidor.
Recovery Model:
Na maioria das vezes, a base que está sendo restaurada é uma base de produção e o Recovery Model dela é FULL. Com isso, o Recovery Model da base de teste também será FULL. Como é uma base de Teste, podemos alterar o Recovery Model para SIMPLE!
Segue o comando para fazer essa alteração:
|
1 |
ALTER DATABASE NomeDatabase SET RECOVERY SIMPLE |
Problema:
Se o Recovery Model da base de Teste ficar como FULL e não for feito Backup de Log dessa base, o Arquivo de Log dela irá crescer continuamente, podendo acabar com o espaço em disco e até mesmo parar o ambiente de produção, pois os arquivos das outras bases não vão ter mais espaço para crescer. Não é muito raro um cliente entrar em contato conosco informando que o espaço em disco está acabando e o problema ser exatamente esse que nós citamos!
Backup:
Dependendo da sua Estratégia de Backup, a base de Teste pode entrar automaticamente na rotina de Backup e gerar arquivos sem necessidade.
Problema:
Os arquivos de backup da base de Teste podem utilizar muito espaço em disco à toa. Imagine que o cliente está pagando para armazenar os arquivos de Backup na nuvem a cada GB. Então, se você tiver vários arquivos de uma base de Teste grande, podem estar gastando dinheiro para armazenar algo que não era necessário. Revise isso o quanto antes no seu ambiente!
Rotinas de Administração do Banco de Dados:
Aqui estou considerando as seguintes rotinas que podem ser pesadas e demoradas:
- CHECKDB
- Rebuild de Índices
- Atualização de Estatísticas
Problema:
Dependendo de como essas rotinas estão configuradas, a base de Teste pode ser considerada automaticamente e fazer as rotinas demorarem mais, até mesmo horas, sem necessidade. Em alguns casos, as rotinas ainda estão executando no início da manhã devido à nova base de Teste e isso pode gerar alguns impactos na produção.
Tabela – Ignore Databases:
“Caramba Luiz, vou ter que alterar todas as minhas rotinas para desconsiderar essa nova base de teste???”
Calma, você pode criar uma tabela de controle para desconsiderar essas bases de Teste.
O script abaixo cria essa tabela e insere algumas bases que serão desconsideradas nas rotinas.
|
1 2 3 4 5 6 7 8 |
CREATE TABLE Ignore_Databases ( Nm_Database VARCHAR(256) ) INSERT INTO Ignore_Databases VALUES ('NomeDatabase1'), ('NomeDatabase2'), ('NomeDatabase3') SELECT * FROM Ignore_Databases |
Depois disso, você precisa alterar cada rotina para utilizar essa tabela e desconsiderar as bases. Segue abaixo um exemplo:
|
1 2 3 4 5 6 7 |
SELECT D.name FROM sys.databases D LEFT JOIN Ignore_Databases I ON D.name = I.Nm_Database WHERE D.name not in ('tempdb','ReportServerTempDB') AND D.state_desc = 'ONLINE' AND I.Nm_Database IS NULL -- DESCONSIDERA AS BASES DE TESTE |
Pronto, agora as próximas bases de Teste já serão desconsideradas automaticamente das rotinas.
Observação:
Alguns clientes preferem selecionar algumas bases específicas nas rotinas. Nesse caso, quando uma nova base é criada ela deve ser incluída na rotina manualmente. Portanto, uma nova base de Teste não será incluída de forma automática e dessa forma evitamos alguns dos problemas que foram citados anteriormente.
Conclusão:
Portanto, na próxima vez que você precisar fazer um RESTORE, lembre-se de verificar todos esses pontos. Como podemos ver, restaurar uma base de Teste parece ser uma atividade muito simples, mas alguns possui alguns detalhes que são muito importantes.
Já teve algum problema relacionado a base de Teste? Deixe um comentário explicando o seu caso =)
Espero que tenha gostado e que isso também possa ser útil no seu dia a dia. Até o próximo post!
Me siga no LinkedIn e YouTube para ficar por dentro das novidades.
Abraço,
Luiz Vitor França Lima
Consultor SQL Server