Todo administrador ou desenvolvedor de bancos de dados, cedo ou tarde, vai precisar criar scripts para executar múltiplas tarefas que se repetem para vários objetos.
Além de ser uma tarefa tediosa, preparar estes scripts manualmente é um processo que envolve grande risco de erro.
O procedimento envolve, primeiramente identificar, os objetos que precisam ser alterados e então construir as instruções DDL (DROP, CREATE, ALTER).
Um método de simplificar as duas tarefas é criando consultas sobre as tabelas de sistema do banco de dados (metadados) e então definir na cláusula SELECT uma cadeia de caracteres que gera estas instruções DDL.
LEIA TAMBÉM: O Caso das Consultas Lentas no Synapse
Essa técnica pode ser usada tanto para base de dados do SQL Server (on-premises) quanto das versões do AZURE SQL DB. Importante observar que as tabelas de sistema cobrem praticamente todos os objetos do banco (veja o link). Portanto a mesma técnica se aplica a uma quantidade enorme de situações.
Neste artigo, apresento um script que varre todas as tabelas de usuário de um banco de dados e altera o tipo de dados dos campos que atendem a uma certa condição.
Scripts SQL e Tabelas de Sistema
Entendo o Caso de Uso
Imagine que você precisa fazer uma migração do seu banco de dados para um novo servidor SQL Server 2022 (nível de compatibilidade 16.x). Um dos problemas observados é que existem dezenas de campos que usam o tipo de dados TEXT, que está prestes a ser aposentado. Será necessário alterar todos eles para o tipo VARCHAR(MAX) para evitar problemas futuros.
Cabe a você identificar todos os casos e providenciar o script que fará as devidas alterações.
Preparando o Script
Para resolver este problema, basta usar as tabelas sys.objects, sys.columns e sys.types, que trazem respectivamente os metadados de todos os objetos do banco, os campos das tabelas e os tipos de dados reconhecidos.
Com essas três tabelas, teremos condições de identificar os objetos que nos interessam (campos com tipo de dados “TEXT”) e preparar a declaração DDL desejada. Esta declaração deverá seguir a seguinte sintaxe:
Inicialmente crio uma expressão de tabela comum (cte) para identificar os objetos. Em seguida, uso estes dados para construir as declarações DDL conforme a Quadro1.
Para que o script possa ser facilmente reaproveitado para outras alterações de tipos de dados, incluo duas variáveis para informar qual é o tipo de dados buscado e qual é o tipo de dados que será aplicado.
Usei os colchetes em todos os objetos de banco para evitar problemas como nomes fora do padrão SQL (exemplo: nomes que incluam palavras reservadas ou espaços em branco).
LEIA TAMBÉM: Análise de Grafos no Azure SQL DB
O Quadro 2 mostra a declaração completa e o output obtido.
Observe que eu adicionei um caractere ponto-e-vírgula ao final de cada declaração para que elas sejam entendidas pelo SQL como comandos independentes ao invés de tratar a lista de declarações como um pacote único (“batch”).
Finalizando o Trabalho
Como você já observou, o resultado da consulta da Quadro 2 é o próprio script que será executado.
Neste exemplo, o script gerado tem apenas 2 declarações SQL, que poderiam sim ser criadas manualmente. Mas frequentemente uso esta técnica para criar listagens com centenas de declarações.
Um ponto que considero importante mencionar é que costumo adicionar no topo do script uma declaração para usar o banco de dados correto (“USE [bdX]”). Isso é facilmente inserido no gerador de script, como mostra este esboço (Quadro 3).
Caso prefira fazer o download do script completo, acesse este link.
LEIA TAMBÉM: O Caso do Índice Temporário
Scripts SQL: Comentários Finais
Minha intenção aqui é convencer os que estão iniciando no mundo SQL a dar mais atenção às tabelas de sistema e usar os metadados do banco a seu favor. Evidentemente estes metadados jamais devem ser alterados manualmente, sob pena de corromper seu banco de dados.
Porém, como se pode ver, a ideia de geração de scripts não é nenhum bicho de sete cabeças.
É necessária muita atenção na construção das declarações, pois qualquer descuido tem potencial para causar danos na estrutura do banco de dados e, em casos extremos, perda de dados.
Mas o que costuma correr com frequência com estes geradores de script é que estes descuidos são detectados na fase de testes. Os scripts incorretos geralmente apresentam erros de sintaxe e que, portanto, não são reconhecidos como declarações SQL válidas.
No próximo artigo, o assunto é a reconstrução de índices a partir do metadados.
Até lá!
De 0 a 10, o quanto você recomendaria este artigo para um amigo?