On Wed, Aug 21, 2013 at 1:46 AM, Waister Marques . <[email protected]>wrote:
> 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
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
