pg_dump -U <usuario> –inserts -t <tabela> <banco> > dump.sql

Um exemplo real:

pg_dump -U postgres –inserts -t municipio geral > municipios.sql

Howto: Gerando Dump do Postgresql e transferindo o arquivo para uma máquina com Windows Server

O objetivo deste howto não é discutir qual é a melhor forma de realizar um backup PostgreSQL, mas sim propor uma forma de realizar um Dump da base de dados em um servidor Linux e transferir para um servidor de arquivos que rode Windows, isso é muito comum em empresas e instituições, onde muitas vezes no servidor Windows encontra-se instalada algumas ferramentas de terceiro para gerenciar fitas, robôs e etc.

Não custa citar o ótimo artigo do Fábio Telles Rodriguez, onde o mesmo deixa claro que Dump não é considerado a melhor forma de realizar um backup. Vamos lá.

Imaginemos o seguinte cenário:

• Uma rede controlada por um Windows Active Directory – AD (Windows 2003 ou maior);
• Um servidor de arquivos na rede, que pode estar rodando na mesma máquina do AD ou em outra;

• Servidor Linux (Ubuntu ou outro qualquer) e rodando o SGBD PostgreSQL 8.x;

A idéia é o seguinte:

• Uma vez por dia o SGBD PostgreSQL irá gerar um Dump da base de dados, através de uma tarefa agendada na Crontab.
• O dump gerado será armazenado em um diretório na mesma máquina do SGBD (não é uma boa prática deixar na mesma máquina) e uma cópia do mesmo será enviado para o servidor de arquivos Windows.

Mãos a massa:

1. Vamos considerar que o servidor Linux seja Ubuntu (ou debian) . Se estiver utilizando CentOS  é só instalar os mesmos pacotes pelo Yum Instal;

Instalando os requisitos:

# apt-get install samba samba-common smbfs smbclient

Criando a pasta que servirá de montagem:

# mkdir /mnt/ntserver

No servidor de domínio, Windows Server – Active Directory, você deve ter um usuário com privilégio de escrita na pasta compartilhada. Basta executar a linha abaixo para testar a montagem:

# mount -t smbfs //192.168.0.10/pasta_compartilhada /mnt/ntserver -o username=usuario_de_dominio,password=senha_de_dominio

Claro trocando os termos em negrito para os da sua rede.

# ls /mnt/ntserver

Com este comando deve listar o conteudo da pasta campartilhada lá do servidor de arquivos Windows. Ok, agora, vamos desmontar:

# umount /mnt/ntserver

Criando o script de backup do PostgreSQL

Criando a pasta onde ficará armazenado localmente os Dumps

# mkdir /home/bkp_pg

Crie o arquivo chamado bkp.sh

# vim /etc/init.d/bkp.sh

Insira o seguinte conteúdo:

#!/bin/sh
# script que gera backup de bases de dados PostGreSQL
# Referencia: http://www.htmlstaff.org/postgresqlmanual/app-pgdump.html
# Jonas Ferreira - jonas.ferreira@gmail.com - http://jf.eti.br
# C 2010 03 19
#

# VARIAVEIS ##################
export PGPASSWORD=postgres            # Exportando a senha do PostGreSQL para o ambiente (Ubuntu)
vU="postgres"                          # Usuario no PostGreSQL
vP="postgres"                        # Senha
vB=nome_base                             # Base De dados
vBI="/usr/lib/postgresql/8.3/bin/"     # Diretorio raiz dos binarios do PostGreSQL
vR="/home/"                                # Diretorio raiz
vD="bkp_pg/"                     # Destino do Backup
vPre="basePG"                       # Prefixo no nome do arquivo de saida
vE=".dmp"                              # extencao do arquivo de saida
vH="localhost"                      # Host do servidor
vAno=`date +%Y`                     #Ano
vMes=`date +%m`                     #Mes
vDia=`date +%d`                     #Dia
vHor=`date +%H`                     #Hora
vMin=`date +%M`                     #Min
vCod=`date +%N`                     #date [date (GNU coreutils) 5.3.0]
vDat="$vAno$vMes$vDia-$vHor$vMin-$vCod"
vA=$vPre"-"$vB"-"$vDat$vE

# VALIDACAO ##################
if [ -z $vU ]; then
echo "Sem usuario";
exit 0;
fi
if [ -z $vP ]; then
echo "sem senha";
exit 0;
fi
if [ -z $vB ]; then
echo "informe o nome da base de dados";
exit 0;
fi

# BACKUP #####################
echo "# Gerando backup. Aguarde..."
echo "# Destino: $vR$vD"
echo "# Nome do arquivo: $vA"

echo "#################################"

echo "# Compactando backup. Aguarde..."

# Caso queira gerar com inserts (arquivo fica maior)
#$vBI""pg_dump -U $vU -h $vH --inserts $vB | gzip -c > $vR$vD$vA.out.gz

# Caso queira gerar com copy (arquivo fica menor)
$vBI""pg_dump -U $vU -h $vH  $vB | gzip -c > $vR$vD$vA.out.gz

echo "#################################"
echo "# Transferindo o o arquivo para o servidor Windows..."

# Montando a pasta
mount -t smbfs //192.168.0.10/pasta_compartilhada /mnt/ntserver -o username=usuario_de_dominio,password=senha_de_dominio

# copiando o arquivo
cp $vR$vD$vA.out.gz /mnt/ntserver

# desmontando a pasta
umount /mnt/ntserver

# limpando a variavel de ambiente
export PGPASSWORD=
exit

Setando permissão de execução no script:

# chmod +x /etc/init.d/bkp.sh

Colocando o script na Crontab:

# crontab -e

Adicione a seguinte linha:

#Realizando Backup do PostgreSQL – Todos os dias a meia noite
00 00 * * * /etc/init.d/bkp.sh

Salve o arquivo e pronto, já pode testar:

# /etc/init.d/bkp.sh

Como saída, você verá algo como:

# Gerando backup. Aguarde…
# Destino: /home/bkp_pg/
# Nome do arquivo: basePG-nome_base-20111116-2012-048760000.dmp
#################################
# Compactando backup. Aguarde…
#################################
# Transferindo o o arquivo para o servidor Windows…

Verifique na pasta de destino se foi criado o arquivo:

# ls /home/bkp_pg

Deve listar o arquivo compactado:

basePG-nome_base-20111116-2012-048760000.dmp.out.gz

Verifique também lá no servidor de arquivo do Windows, na pasta compartilhada, se este mesmo arquivo existi por lá.

Pronto, você acabou de implementar uma solução de Dump de uma base PostgreSQL e transferiu para um servidor de arquivos Windows. Espero que seja útil para você.

DELETE FROM tabela WHERE date < DATE_SUB(NOW(), INTERVAL 30 DAY);

Schema Sync é uma interessante ferramenta que pode te ajudar muito, por exemplo, considere o seguinte caso:

• Estamos trabalhando em dois ambientes distintos, um de desenvolvimento e outro de produção. No ambiente de desenvolvimento realizamos várias modificações no esquema de Banco de Dados, até chegar o momento de precisarmos aplicar tais modificações no Banco de produção. Se não tivermos feito uma lista de cada alteração (não considerando ferramentas que armazenam logs das transações) ai teremos um grande problema.

Justamente ai que entra o Schema Sync, que basicamente faz a comparação das Bases de Dados (desenvolvimento e produção) e gera um script.sql com as mudanças para que você possa aplicar no ambiente de produção, além disso também gera um script para reverter as mudanças caso tenha feito algo errado.

Muito útil…

$sql_colnotnull = "SELECT c.column_name FROM information_schema.columns c WHERE c.column_name <> 'id' and c.is_nullable = 'NO' and table_name = '$tablename'";

Como resetar a senha de Root do Mysql
===================================

[root@servidor ~]# lsof -i :3306
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
mysqld 31792 mysql 3u IPv4 434089 TCP *:mysql (LISTEN)
[root@servidor ~]# kill -9 31792
[root@servidor ~]# /etc/init.d/mysql start
Mysql Started

[root@servidor ~]# mysql
Access denied for user ‘root’@'localhost’ (using password: NO)

[root@servidor ~]# /etc/init.d/mysql stop

[root@servidor ~]# mysqld_safe –skip-grant-tables &

[root@servidor ~]#
[root@servidor ~]# mysql -u root
mysql>
mysql> use mysql;
mysql> update user set password=PASSWORD(“NEW-ROOT-PASSWORD”) where
User=’root’;
mysql> flush privileges;
mysql> quit

NEW-ROOT-PASSWORD above is whatever password you want to set.

[root@servidor ~]# # /etc/init.d/mysql stop
[root@servidor ~]# lsof -i :3306
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
mysqld 31792 mysql 3u IPv4 434089 TCP *:mysql (LISTEN)
[root@servidor ~]# kill -9 31792
[root@servidor ~]# fuser -k /usr/bin/mysqld_safe ( in
case you see mysql process is still running )

[root@servidor ~]# vi /root/.my.cnf
[root@servidor ~]# cat /root/.my.cnf
[client]
user=”root”
pass=”NEW-ROOT-PASSWORD”
[root@servidor ~]#

[root@servidor ~]# service mysql restart

[root@servidor ~]# mysql
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 4.1.21-standard-log

Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the buffer.

mysql> quit
Bye
[root@servidor ~]#

A grande maioria das pessoas são muito relaxadas quando se trata de fazer backups regulares do Banco de Dados, alegando que dá muito trabalho, ou com aquele pensamento: “quais são as chances que vai acontecer comigo uma perda geral de dados?”

Mas e se o backup acontecesse automaticamente todos os dias, armazenando a cópia do Banco em outro servidor de forma segura? Seria ótimo! Vejamos então como fazer isso:

1 – Registar uma nova conta do Gmail

O Gmail oferece 7 GB de armazenamento e até 20MB de arquivos anexados por mensagem (O maior tamanho de anexo que encontrei para uma conta de e-mail gratuito). É grátis e é completamente fora do seu servidor de hospedagem, por isso, se o seu provedor perder tudo, você não terá perdido os seus backups.

Vá até http://mail.google.com/ e “Inscreva-se no Google Mail”. O cadastro leva apenas um minuto para preencher e agora você terá 7GB de espaço de armazenamento gratuito.

2 – Instalar o Plugin

Existem vários plugins de backup diferente, mas vamos utilizar aqui o WP-DB Manager, porque é o único que eu sei que vai funcionar, e porque você pode contar que ele será atualizado a cada nova versão do WordPress.

Baixe o plugin, faça o upload para a pasta plugins e ative-o como qualquer outro plugin.

Você então tem que procurar a pasta wp-content/backup-db, e fazer o upload do arquivo .htaccess da pasta do plugin.

Se a pasta db-backup não existir, você deve criá-la e dar previlégios total (CHMOD 777) (Na maioria dos clientes FTP, você pode dar um “CHMOD” com um clique direito e escolhendo “chmod” ou “atributos de arquivo” etc).

3 – Definir as configurações

Um link chamado “Database” será adicionado ao seu painel principal do WP-Admin. Clique nele, depois clique na aba “Opções do DB”.

Na seção de agendamento automático, escolha todos os dias, Gzip Sim e digite o seu endereço do Gmail. Agora clique em “Update Options” e está feito.

4 – Lycos Mail, para quando o seu banco de dados for muito grande

A desvantagem do método acima é que você está limitado a um tamanho máximo de 20MB de seu banco de dados.

O Banco do wordPress tende a ser pequeno, e gzippiando o arquivo irá lhe ajudar imensamente, mas se seu site crescer acima do limite de 20MB, você terá que encontrar uma conta de e-mail melhor.

Nesse caso, tente Lycos Mail. Eles oferecem 3 GB de armazenamento gratuito, mas ilimitado tamanho de anexo de email.

No entanto, com a versão gratuita, você deve entrar a cada 30 dias, ou eles vão excluir permanentemente todos os seus e-mails. Você pode evitar as exclusões da Lycos comprando uma conta Profissional, que custa U$5,95 dólares por ano (ainda assim muito barato).

É isso…

Você conhece o Rollback em Bancos transacionais? É uma mão na roda, quando se precisa recuperar algo que você fez e se arrependeu, como alteração dem vários campos com valores errados, ou até mesmo excluiu um ou mais registros e deu COMMIT. Sim, você pode recuperar os dados…

É uma tarefa muito simples, basta fazer um select normalmente na  tabela,  com os campos e condições que você quer e, no FROM, após o nome da tabela, colocar “as of timestamp systimestamp – interval ‘X’ minute“, onde esse “X” é o tempo que passou desde a a besteira que  fez até agora.

Veja a seguinte situação hipotética:

Imagine que se tenha uma tabela CLIENTE e você atualiza os clientes que não fazem compras há mais de 1 mês para Inativos. Você faz isso com um update,  atualizando o campo STATUS_CLIENTE para “I”, de inativo,  depois de fazer um select que retorna os  clientes que não compraram no último mês.

Após a execução do update (COMMIT), alguns clientes estavam com o STATUS “A” de Ativo, “D” de Devedor, “V” de VIP. Passa 30 minutos seu chefe entra na sala, e lhe fala que esse update não pode ser feito em clientes VIP, e agora? Faz assim:

select ID_CLIENTE
from CLIENTE
as of timestamp systimestamp - interval '30' minute
where STATUS_CLIENTE = 'V';

PRONTO! Peguei todo mundo que tava com o campo STATUS_CLIENTE = ‘V’ 30 minutos atrás. Com os IDs, é possível fazer um novo  update, passando esse pessoal que  está com o STATUS = ‘I’, pra ‘V’.

Via: Estação ZEN

Este é um problema bastante comum entre desenvolvedores que lidam com banco de dados:
Realiza-se uma busca (SELECT) e como resultado tem-se uma lista de ID´s. Agora como trazer os dados desses ID´s?

Algumas pessoas utilizam a seguinte lógica para solucionar este problema:

 SELECT * FROM países
foreach($países as $país) {
SELECT * FROM ciudades WHERE país = $país
foreach ($ciudades as $ciudad) {

Como pode-se ver, não é apenas confuso de ler como também é impossível de crescer logicamnte. Sem falar que gera um gasto excessivo de memória.

Ai é que entra os JOIN´s…

Por exemplo, usando JOIN, pode-se ter um set de resultados de países com a seguinte query:

SELECT * FROM localidade. AS dir
JOIN países AS p ON p.país = dir.pais
WHERE … qualquer condição

Esta busca geraria o seguinte resultado hipotético (veja que esta organizado pela coluna ‘pais’):

p.id  |  p.pais   | dir.id  | dir.pais  | dir.localidade
1     |  USA      | 3       | USA       | 200 West Chadderdon Avenue
2     |  Mexico   | 4       | Mexico    | 823 Monte Libano
4     |  Colombia | 2       | Colombia  | Carrera 9B Bis #117-32
3     |  Colombia | 1       | Colombia  | Calle 127 #42-45

Fácil né? Bem, parece simples a primeira vista, porém com isso estamos apenas raspando a superfície do problema, como por exemplo, se existir duas tabelas que não necessariamente contenham dados simétricos.

Para solucionar este problema, tem que se usar os JOINS por completo: LEFT JOIN, RIGHT JOIN, INNER JOIN e OUTER JOIN.

Vejamos o exemplo abaixo de duas tabelas que contenham alguns dados em comum:

id nombre       id  nombre
-- ----         --  ----
1  Pirata       1   Rutabaga
2  Mico         2   Pirata
3  Ninja        3   Darth Vader
4  Spaghetti    4   Ninja

Certo? Agora vejamos como mesclar os dados com JOIN, no caso o INNER JOIN:

SELECT * FROM TablaA
INNER JOIN TablaB
ON TablaA.name = TablaB.name

id  name       id   name
--  ----       --   ----
1   Pirata     2    Pirata
3   Ninja      4    Ninja

Como resultado teremos uma lista com registros que existam tanto em A como em B simultaneamente.

FULL OUTER JOIN

SELECT * FROM TablaA
FULL OUTER JOIN TablaB
ON TablaA.name = TablaB.name

id    name       id    name
--    ----       --    ----
1     Pirata     2     Pirata
2     Mico       null  null
3     Ninja      4     Ninja
4     Spaghetti  null  null
null  null       1     Rutabaga
null  null       3     Darth Vader

Gerará uma lista com incluem todos os resultados de A e B, assim não existirá relação alguma entre os campos.

LEFT OUTER JOIN

SELECT * FROM TablaA
LEFT OUTER JOIN TablaB
ON TablaA.name = TablaB.name;

id  name       id    name
--  ----       --    ----
1   Pirata     2     Pirata
2   Mico       null  null
3   Ninja      4     Ninja
4   Spaghetti  null  null

Todos os resultados que se encontram na tabela A e os resultados na mesma ordem na tabela B.

Usos e Derivações:

Agora que vimos como que funciona o JOIN, vejaamos outros exemplos com JOIN´s completas:

SELECT * FROM TablaA
LEFT OUTER JOIN TablaB
ON TablaA.name = TablaB.name WHERE TablaB.id is null;

id  name       id     name
--  ----       --     ----
2   Mico       null   null
4   Spaghetti  null   null

Só quero ver os registros únicos que existam na tabela A

SELECT * FROM TablaA
FULL OUTER JOIN TablaB
ON TablaA.name = TablaB.name
WHERE TablaA.id is null
OR TablaB.id is null

id    name       id    name
--    ----       --    ----
2     Mico       null  null
4     Spaghetti  null  null
null  null       1     Rutabaga
null  null       3     Darth Vader

Mostra-me os registros que não tenham relação alguma entre a tabela A e tabela B

Veja que o LEFT JOIN é intercambiável em sintaxe (mas não na lógica) com o RIGHT JOIN, onde:

SELECT * FROM TablaA
LEFT JOIN TablaB
ON TablaA.name = TablaB.name

… é equivalente a:

SELECT * FROM TablaB
RIGHT JOIN TablaA
ON TablaA.name = TablaB.name

Fonte: http://pt.wikibooks.org/wiki/PostgreSQL_Pr%C3%A1tico/DML/Consultas_Join

Uma das melhores apostilas de Postgresql, um pouco antiga, porém extremamente útil. Você verá em detalhes:

• Instalação
• DDL (Data Definition Language)
• DML (Data Manipulation Language)
• Funções Internas
• Funções Definidas pelo Usuário e Triggers
• DCL (Data Control Language) – Administração
• Transações
• Administração
• Replicação
• Configurações
• Metadados (Catálogo)
• Conectividade
• Ferramentas
• Apêndices
• Exercícios

Tudo em Português.

Download:  http://www.fop.unicamp.br/