Será que meu dump foi gerado com sucesso?

Uma das atividades executadas para extrair dados de um banco é a geração do arquivo de dump de suas bases de dados, que nada mais é do que um arquivo contendo a imagem do seu banco de dados em um determinado instante do tempo num formato que possa ser restaurado em versões diferentes de seu banco de dados. Ele não é um backup por completo, mas permite que uma ou mais tabelas e/ou dados sejam restaurados.

Como existem ferramentas de linha de comando que geram esses arquivos, é bastante comum utilizá-las em scripts autônomos, agendados diariamente no período noturno.

Mas nem tudo são flores e podemos ser supreendidos ao saber que justo aquele dump que precisávamos não foi executado com sucesso. E agora?

Bom, como já diz o ditado “é melhor prevenir do que remediar”… então, que tal melhorar o script que gera o dump?

AVISO: os passos a seguir não se aplicam ao S.O. Windows ‘puro’, você precisa ter o Cygwin instalado!

Nos sistemas operacionais unix-like possuimos a saida padrão (conhecida por stdout, cujo descritor de arquivo é 1), a saída padrão de erros (conhecida por stderr, cujo descritor de arquivo é 2) e a entrada padrão (conhecida por stdin, cujo descritor de arquivo é 0).

Estes recursos podem ser utilizados para redirecionar as saidas de nossos programas. No caso do nosso amigo pg_dump geralmente utilizamos ele assim:

pg_dump meu_banco > meu_banco.dump

O que estamos fazendo, nada mais é do que redirecionar a saída padrão (stdout) do pg_dump para um arquivo chamado ‘meu_banco.dump’.

Mas e se ocorrer algum imprevisto, como falta de espaço em disco, por exemplo? Neste caso, podemos redirecionar a saída de erros (que por padrão é a console) para um arquivo com o seguinte comando:

pg_dump meu_banco > meu_banco.dump 2> meu_banco.erro

A única diferença foi a adição de '2> meu_banco.erro’ ao final do comando. No caso isso indica que os dados enviados para a saída padrão de erros (stderr, descritor de arquivo 2), devem ser redirecionados para o arquivo ‘meu_banco.erro’.

Sendo assim, após o comando ter sido executado, pode-se verificar se o arquivo ‘meu_banco.erro’ está vazio (indicando sucesso na operação) ou contém algo (indicando que houve erro). Este método é interessante porque você guarda o erro ocorrido, o que via script pode ajudar a entender a origem do problema e até mesmo servir de conteúdo para um e-mail automaticamente enviado para o DBA.

Outro método que você pode utilizar é redirecionar a saida padrão de erros para /dev/null e utilizar os operadores ‘&&’ e ‘||’ do shell:

pg_dump > meu_banco.dump 2>/dev/null && echo "OK" || echo "ERRO"

No caso acima, se tudo ocorrer bem, ele ecoará “OK” do contrário “ERRO” será retornado. Colocando tudo num script… Podemos utilizar os conceitos acima para criar um script que automatize este processo todo. Segue:

#!/bin/sh
###############################################
#
# Script de geração de dump full
#
# (c) 2006-2008 Dickson Guedes <guediz at gmail com>
#
###############################################

# Email DBA
CFG_EMAIL="dba@minhaempresa.com"

# Variaveis de mensagens
MSG_OK="Dump gerado com sucesso!"
MSG_ERRO="Dump gerado com erros!"
MSG_DATA=`date +"%Y-%m-%d"`

# Variaveis de caminhos dos utilitarios
PRG_PGDUMP="/usr/bin/pg_dump"

# Variaveis dos arquivos gerados
ARQ_DUMP="meu_banco"
ARQ_DUMP_OK="$ARQ_DUMP-$MSG_DATA.dump"
ARQ_DUMP_ERRO="$ARQ_DUMP-$MSG_DATA.erro"

###############################################

$PRG_PGDUMP >$ARQ_DUMP_OK 2>$ARQ_DUMP_ERRO && STATUS="SUCESSO" || STATUS="ERRO"

if [ "$STATUS" = "SUCESSO" ]; then
		echo "$MSG_OK"   | mail -s"$MSG_OK" $CFG_EMAIL
else
		echo "$MSG_ERRO" | mail -s"$MSG_ERRO" $CFG_EMAIL < $ARQ_DUMP_ERRO
fi

###############################################

DESAFIO: alterar o script acima adicionando a característica de passar o nome do banco de dados através de parâmetros de linha de comando.

Bom, é isso… “:)

comments powered by Disqus