Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da SQL Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
dê seu feedback
post favorito
Artigo SQL Magazine 70 - Dez problemas e soluções no dia a dia do DBA PostgreSQL
O artigo trata dez cenários problemáticos que podem ocorrer no cotidiano da administração do banco PostgreSQL e possíveis soluções para estes problemas.
SQL Magazine 70
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da SQL Magazine 70
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da SQL Magazine 70
PostgreSQL
De que trata o artigo:
O artigo trata dez cenários problemáticos que podem ocorrer no cotidiano da administração do banco PostgreSQL e possíveis soluções para estes problemas.
Para que serve:
Através destes cenários, que são bastante próximos de possíveis problemas que ocorrem no dia-a-dia, o leitor será esclarecido sobre qual é a melhor metodologia de resolução de problemas diante dos fatos.
Em que situação o tema é útil:
O artigo esta recheado de dicas e soluções úteis não somente para solucionar problemas mas para também realizar a manutenção preventiva diária.
Especialistas em software indicam uma crescente na adoção de soluções free (gratuitas ou de código aberto) como um mecanismo para driblar os incautos da crise mundial. Diante deste fato, usar o PostgreSQL não é apenas uma opção para redução de custo operacional em um projeto, mas também é usar um SGDB com poder suficiente para atender grandes demandas. Apenas para informação, projetos como a ferramenta de comunicação SKYPE foi desenvolvida utilizando o SGBD PostgreSQL. Um caso de sucesso como este já demonstra a aplicabilidade deste banco.
Ruma à versão 8.4, o PostgreSQL é um atrativo para gerentes de T.I e DBAs. Porém, mesmo com uma vasta documentação, administrar banco de dados exige muitas vezes mais do que um bom conhecimento técnico. Problemas podem surgir e nem sempre a solução é encontrada em um manual. O propósito deste artigo é justamente este: auxiliar os que estão iniciando projetos em PostgreSQL e terão pela frente uma longa peleja. Sendo assim, convido os leitores a escreverem enviando problemas para que em uma segunda fase possamos transformar o problema em uma solução compartilhada através de artigos.
Os cenários que iremos abordar são:
1. O sistema está com falta de espaço em disco;
2. Sistema amanhece travado quando o Vacuum entra em execução;
3. O pg_dump não está realizando backup. Foi descoberta uma tabela corrompida;
4. Há valores duplicados na tabela e não conseguimos criar uma Chave Primária;
5. De repente aparecem muitos processos em “IDLE IN TRANSACTION” e os outros processos entram em waiting travando a aplicação;
6. Meu sistema está lento demais;
7. Quando executo o relatório o sistema trava;
8. Nunca tenho certeza se o Slony está replicando;
9. Nunca tenho certeza se as novas tabelas estão sendo replicadas;
10. Estou em dúvida em saber qual é a melhor estratégia de Backup.
O ambiente adotado
Neste artigo iremos reforçar as soluções em ambiente Linux/Unix, embora algumas soluções possam ser empregadas em Windows. O fato é que ao se falar de PostgreSQL, o Linux é o sistema operacional que melhor se encaixa como S.O. para montar um ambiente de produção. Em hardwares de mercado como HP, DELL e IBM, a distribuição deve tender para o Red Hat Enterprise ou o SuSE devido à política de homologação destes marcas. Em nosso caso, por se tratar de um laboratório, estaremos utilizando o Ubuntu 9.04 juntamente com o PostgreSQL 8.3 e Slony I por ser a solução de replicação mais comum. O ambiente foi montado através do gerenciador de pacotes do Debian (APT).
Resumo do ambiente:
· S.O = Ubuntu Server 9.04 i386
· SGBD = PostgreSQL 8.3
· Replicação = Slony I
· HD = Partição de 1 G para o PostgreSQL e 300Mb para o pg_xlog
Para montar os 10 cenários que iremos seguir neste artigo, foi também necessário realizar a criação de uma base de dados de exemplo. Para isso, criamos a base com o nome revista contendo por enquanto duas tabelas: a tabela usuario (Tabela 1) e a tabela produto (Tabela 2).
Coluna
Tipo
id_usuario
INT4
CPF
VARCHAR(11)
nome_usuario
"
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVP
Dez problemas e soluções no dia a
dia do DBA PostgreSQL
De que trata o artigo:
O artigo trata dez cenários problemáticos que podem ocorrer no cotidiano da administração do banco PostgreSQL e possíveis soluções para estes problemas.
Para que serve:
Através destes cenários, que são bastante próximos de possíveis problemas que ocorrem no dia-a-dia, o leitor será esclarecido sobre qual é a melhor metodologia de resolução de problemas diante dos fatos.
Em que situação o tema é útil:
O artigo esta recheado de dicas e soluções úteis não somente para solucionar problemas mas para também realizar a manutenção preventiva diária.
Especialistas em software indicam uma crescente na adoção de soluções free (gratuitas ou de código aberto) como um mecanismo para driblar os incautos da crise mundial. Diante deste fato, usar o PostgreSQL não é apenas uma opção para redução de custo operacional em um projeto, mas também é usar um SGDB com poder suficiente para atender grandes demandas. Apenas para informação, projetos como a ferramenta de comunicação SKYPE foi desenvolvida utilizando o SGBD PostgreSQL. Um caso de sucesso como este já demonstra a aplicabilidade deste banco.
Ruma à versão 8.4, o PostgreSQL é um atrativo para gerentes de T.I e DBAs. Porém, mesmo com uma vasta documentação, administrar banco de dados exige muitas vezes mais do que um bom conhecimento técnico. Problemas podem surgir e nem sempre a solução é encontrada em um manual. O propósito deste artigo é justamente este: auxiliar os que estão iniciando projetos em PostgreSQL e terão pela frente uma longa peleja. Sendo assim, convido os leitores a escreverem enviando problemas para que em uma segunda fase possamos transformar o problema em uma solução compartilhada através de artigos.
Os cenários que iremos abordar são:
1. O sistema está com falta de espaço em disco;
2. Sistema amanhece travado quando o Vacuum entra em execução;
3. O pg_dump não está realizando backup. Foi descoberta uma tabela corrompida;
4. Há valores duplicados na tabela e não conseguimos criar uma Chave Primária;
5. De repente aparecem muitos processos em “IDLE IN TRANSACTION” e os outros processos entram em waiting travando a aplicação;
6. Meu sistema está lento demais;
7. Quando executo o relatório o sistema trava;
8. Nunca tenho certeza se o Slony está replicando;
9. Nunca tenho certeza se as novas tabelas estão sendo replicadas;
10. Estou em dúvida em saber qual é a melhor estratégia de Backup.
O ambiente adotado
Neste artigo iremos reforçar as soluções em ambiente Linux/Unix, embora algumas soluções possam ser empregadas em Windows. O fato é que ao se falar de PostgreSQL, o Linux é o sistema operacional que melhor se encaixa como S.O. para montar um ambiente de produção. Em hardwares de mercado como HP, DELL e IBM, a distribuição deve tender para o Red Hat Enterprise ou o SuSE devido à política de homologação destes marcas. Em nosso caso, por se tratar de um laboratório, estaremos utilizando o Ubuntu 9.04 juntamente com o PostgreSQL 8.3 e Slony I por ser a solução de replicação mais comum. O ambiente foi montado através do gerenciador de pacotes do Debian (APT).
Resumo do ambiente:
· S.O = Ubuntu Server 9.04 i386
· SGBD = PostgreSQL 8.3
· Replicação = Slony I
· HD = Partição de 1 G para o PostgreSQL e 300Mb para o pg_xlog
Para montar os 10 cenários que iremos seguir neste artigo, foi também necessário realizar a criação de uma base de dados de exemplo. Para isso, criamos a base com o nome revista contendo por enquanto duas tabelas: a tabela usuario (Tabela 1) e a tabela produto (Tabela 2).
Coluna
Tipo
id_usuario
INT4
CPF
VARCHAR(11)
nome_usuario
"
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da SQL Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
3 COMENTÁRIOS
Priscila Azarias
Parabéns pelo artigo. Excelente.
Ajuda muito quem está começando com o PostgreSQL
Parabéns
Abraços
[há +1 ano] -
Responder
Erivando S. Ramos
Não apenas para iniciantes, mas para dba experientes também podem cair em alguma destas cascas de banana!
Ótimo artigo e manual de bolso.
Ótimo artigo e manual de bolso.
[há +1 ano] -
Responder
Veronica Dos Santos
Existe alguma configuração de timeout de conexão para evitar estas sessões perdidas como IDLE IN TRANSACTION?
[há +1 mês] -
Responder
Artigo SQL Magazine 52 - Estudos de Caso de Projeto de Bancos de Dados para Contas a Pagar e Receber
Artigo da SQL Magazine 26 - SQL Server 2000 fail-over clustering Parte II: Instalação e Configuração
Artigo SQL Magazine 23 - Influenciando o otimizador de consulta baseado em custo do Oracle - Parte 3
Artigo SQL Magazine 20 - Influenciando o otimizador de consulta baseadoem custo do Oracle - Parte II
Você está em:
canal SQL
Publicidade
Carlos Eduardo Smanioto
Space do autor
Carlos Eduardo Smanioto
www.datapower.com.br
carlos.smanioto@datapower.com.br
Formado em Ciências da Computação, é consultor na área de T.I. Atua a mais de 10 anos com banco de dados PostgreSQL e segurança da informação, possui em seu mini-bio diversos artigos, palestras realizadas. Trabalha com...
Space do autor
1
0
