On Wed, Aug 21, 2013 at 1:46 AM, Waister Marques . waiste...@hotmail.comwrote:
Tudo bem pessoal.
Criei uma rotina de backup do meu banco que esta na versão 9.2, é gostaria
de implementar a mesma com compactação e vacuum full, baiaxo segue a rotina
que criei, detalhe que criei um rolin no banco para mais um usuário.
@echo off
for /f tokens=1-4 delims=/ %%i in (%date%) do (
set dow=%%i
set month=%%j
set day=%%k
set year=%%l
)
for /f tokens=1-4 delims=: %%a in (%time%) do (
set hora=%%a
set minu=%%b
)
set datestr=%hora%-%minu%-%dow%%year%-%month%-%day%
echo datestr is %datestr%
set BACKUP_FILE=Retaguarda-%datestr%.backup
echo backup file name is %BACKUP_FILE%
SET PGPASSWORD=postgres
echo on
pg_dump -i -h localhost -p 5432 -U retaguarda_dba -F c -b -v -f
%BACKUP_FILE% retaguarda_db
Algumas coisas ruins que notei na sua rotina:
1. Adicionar o PGPASSWORD no script, tente usar .pgpass, e mude essa senha
para algo que (1) não tenha publicado na internet, (2) não seja tão
comum/obvio.
2. Remova o -i, está depreciado. Sempre use o binário correto e seja
feliz...
3. Esse novo usuário, não é superusuário, é? Se for, não deveria, criei um
usuário com permissões somente-leitura nessa base.
Fora isso, sua rotina **de dump** parece boa, mas verifique também a
possibilidade de implantação de PITR [1], há quem considere que Dump não é
backup [2] (nas palavras do famoso Telles).
Esta funcionando beleza, pois coloquei a .bat dentro da pasta C:\Program
Files\PostgreSQL\9.2\bin do 2008 server,
Não posso palpitar muito sobre o Windows, mas isso não me parece uma boa
prática (não seria no Linux), creio que em C:\Program Files\PostgreSQL
deveria ter apenas o que foi instalado pelo instalador do PostgreSQL (minha
opinião), o que facilitará a administração e atualização do banco de dados
no futuro. Para resolver, recomendo colocar todos seus scripts num mesmo
local (ou ao menos com um diretório parente em comum) e alterar a variável
de ambiente PATH para o bin do PostgreSQL, ou ainda usar caminhos absolutos
(definindo uma variável para o caminho, claro). Se batch poder incluir
arquivos (não sei se dá) seria legal definir essas variáveis comuns num
arquivo a parte.
como faço para implementar ela com o comando vacuum full antes de fazer o
backup e depois compactar o banco?
Aí vem a dúvida: por que você quer fazer isso? Em muitos casos, muitos
mesmo, um vacuum full diário é completamente desnecessário e pode até
causar uma perda de performance no seu banco de dados (principalmente se
tiver muitos UPDATEs). O que eu recomendaria num cenário geral, sem análise
mais profunda, é rodar simplesmente um vacuum analyze (sem o full):
vacuumdb -z -h localhost -p 5432 -U retaguarda_dba
No mais, mantenha o autovacuum ativo e, se necessário, vá ajustando os
parâmetros do mesmo para casar com seu ambiente. Vale notar que para
muitos casos (principalmente ambientes menores - poucos usuários, base
pequena) as configurações padrões do autovacuum são o suficiente para tomar
conta do seu banco (pelo menos nas versões mais recentes do PG, como seu
caso).
Para ver se realmente precisa de vacuum full, dê uma analisada periódica no
inchaço de suas tabelas e faça somente para aquelas que estiverem ruins.
[1] http://www.postgresql.org/docs/current/static/continuous-archiving.html
[2] http://savepoint.blog.br/dump-nao-e-backup/
[3] http://wiki.postgresql.org/wiki/Show_database_bloat
Atenciosamente,
--
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
