terça-feira, 20 de abril de 2010

Erros de "Permission Denied na Criação de Tablespaces"

Em muitos casos os problemas que mais incomodam são os mais simples. No caso do Postgresql, um problema bem comum mas que causa estresse é a falta de permissão para a criação de tablespaces.

Tablespaces permitem um maior controle sobre a localização física dos dados, metadados, índices e estatísticas do banco. Informações sobre criação de tables paces podem ser obtidas aqui. O postgresql utiliza o sistema de arquivos fornecido pelo sistema operacional, o que muitas vezes gera problemas de autorização de acesso que impedem a sua criação, o clássico erro "permission denied".

Neste post vamos mostrar como definir corretamente as permissões para criação de tablespaces em ambiente windows.

Passo 1: Criar pasta do tablespace.
Crie uma pasta sem arquivos dentro para a definição do novo tablespace.

Passo 2: Abrir tela de configuração
Entre no Windows Explorer e acione o menu "Ferramentas/ Opções de Pasta...".
O sistema apresentará uma tela com as opções de pasta.
Desmarque a opção "Usar Compartilhamento Simples de Arquivo (Recomendado)" e confirme a operação. Isso habilitará a aba de segurança das pastas, que serrá utilizada para definir as permissões para a criação do tablespace.

Passo 3: Configuração da segurança da pasta
Na pasta criada para o tablespace, clique com o botão direito e acione o menu “Propriedades”.

Em seguida, clique na aba segurança.

Na tela apresentada, clique em “Adicionar”. Aparecerá uma tela como a que aparece abaixo. Defina o local (no botão "Locais") e, no nome do objeto, coloque o usuário do banco que vai ter acesso ao tablespace. Confirme com o botão “OK”.

Na aba de segurança aparecerá o novo usuário. Marque a opção de “Controle Total”, o que fará com que o banco de dados possa efetivamente acessar o tablespace.


Passo 4: Criação do tablespace.

Utilize para isso o comando CREATE TABLESPACE.


Este post teve contribuição de Jeferson Gallina.

segunda-feira, 8 de março de 2010

PostgreSQL 9.0: Quais são as novidades? A visão das "funcionalidades da semana" - Parte 1!!!

O PostgreSQL está em sua quarta versão alfa, e começam a aparecer indicações das novas funcionalidades e alterações que foram introduzidas. O informe semanal "PostgreSQL Weekly News", organizado por David Fetter apresenta uma seção chamada "Feature of the Week", ou funcionalidade da semana, descrevendo uma alteração em desenvolvimento. Os informes originais podem ser consultados aqui.

Abaixo listo as últimas funcionalidades citadas, agregando algum comentário quando pertinente:

28/03/2010 - Implementação do conceito de blocos anônimos de código (anonymous code blocks) através do comando DO nas linguagens PL/pgsql, PL/Perl, e PL/LOLCODE.

Estes blocos compreendem comandos que podem ser executados em um bloco de código sem um nome, utilizando as poderosas linguagens procedurais do PostgreSQL. Desta forma podem ser executados blocos de código sem que se precise criar funções dentro do banco. Parece uma ótima forma de se criar scripts.

O exemplo abaixo eu peguei aqui:

DO $$DECLARE r record;
BEGIN
FOR r IN SELECT table_schema, table_name FROM information_schema.tables
WHERE table_type = 'VIEW' AND table_schema = 'public'
LOOP
EXECUTE 'GRANT ALL ON ' || quote_ident(r.table_schema) || '.' || quote_ident(r.table_name) || ' TO webuser';
END LOOP;
END$$;

21/03/2010 - Campos do tipo Hstore não tem mais o limite de 64kB para o limite de chaves e suportam árvore B e classes de operadores hash, permitindo GROUP BY, DISTINCT, etc.

Obs: Você sabe por acaso o que é HSTORE? Eu também não sabia, mas é um módulo que implementa um tipo de dados chamado HSTORE que agrega ao mesmo tempo uma chave e um valor, ambos strings. Este novo tipo de dado é útil para uma série de cenários. Mais informações podem ser obtidas aqui.

14/03/2010 - Em PL/pgsql, o comando MOVE agora funciona de forma compreensível com Cursores.

Obs: Não deu para entender o problema que havia antes, mas este comando reposiciona o cursor sem recuperar dados (NEXT, PRIOR, FIRST, LAST, ABSOLUTE count, RELATIVE count, FORWARD, ou BACKWARD).

07/03/2010 - A saída do EXPLAIN pode ser formatada como XML, JSON, YAML e o mecanismo de análise está muito mais simples. O formato tradicional de texto ainda é o formato padrão.

Obs: Os novos formatos permitem a definição de relatórios e ferramentas de análise dos resultados do comando Explain, facilitando a otimização de consultas.

28/02/2010 - A suíte pgbench agora é multi-threaded, o que lhe permite tirar partido de múltiplos núcleos de CPU.

Obs: O pgbench é um utilitário que faz o benchmark de desempenho do servidor. Pode ser utilizada para testes de estresse, carga e performance. O uso de múltiplas threads faz com que os resultados sejam mais confiáveis e obtidos em menor tempo.

21/02/2010 - Agora você pode controlar o comportamento de valores distintos para cada coluna com ALTER TABLE ALTER COLUMN ... ... SET (parâmetro = valor ,...) onde parâmetro pode ser uma das n_distinct e n_distinct_inherited. Valores positivos são assumidos como sendo o número de valores distintos aceitos, 0 diz que o planejador da consulta deve utilizar os resultados do comando ANALYZE, e os números negativos (que devem estar entre -1 e 0) fazem com que o planejador estime o número de valores distintos como o número de linhas multiplicado pelo valor absoluto do número.

Obs: Funcionalidade de performance, para consultas específicas.

14/02/2010 - Violações de restrição de unicidade de valor agora geram mensagens de erro mais detalhadas.

Obs: Agora fica mais fácil encontrar a causa de exceções de valores repetidos e como resolvê-las.

31/01/2010 - A checagem de constraints de não repetição de valores pode agora ser adiada até a hora do commit.

Obs: Funcionalidade de performance, para consultas específicas.

24/01/2010 - A sintaxe DROP IF EXISTS agora trabalha em colunas e restrições.

Obs: Sintaxe interessante para os desenvolvedores de ferramentas de banco de dados.

17/01/2010 - O Vacuum full foi alterado para gerar novos arquivos para tabelas e índices por padrão. Esta implementação é baseada no antigo comando CLUSTER e mais eficiente e efetiva. A funcionalidade antiga do VACUUM FULL ainda pode ser acessada através do comando VACUUM FULL INPLACE, mas será incompatível com o Hot Standby.

Obs: O Vacuum Full Implace só parece ser vantajoso para sistemas com pouco espaço em disco. A nova Implementação promete ganho de tempo nas manutenções de banco.

10/01/2010 - Agora você pode armazenar em log o estado de consultas SQL, erros, etc, usando "%e" na sua log_line_prefix.

03/01/2010 - No psql o uso de "\d" agora mostra quantas tabelas herdadas uma tabela-mãe tem, e "\d+" lista os nomes das tabelas herdadas.

Obs: Alteração de pouco impacto para quem não utiliza recursos objeto-relacionais.

27/12/2009 - Hot Standby. Após 1,5 anos de desenvolvimento, você pode finalmente executar consultas somente leitura PITR contra os escravos. Graças ao Simon Riggs, Heikki Linnakangas, qualquer muitos outros esforços incessantes.

Obs: O melhor uso de hardware promete ganho de desempenho e redução de custos para grandes sistemas escaláveis e resistentes a falhas. Esta é uma das funcionalidaes que merecerá bastante atenção dos DBAs.

20/12/2009 - Cláusulas WHEN sobre Triggers. Na versão 8.5 Alpha3 você será capaz de criar triggers com uma cláusula WHEN para que as mesmas executem apenas se os valores ou condições específicas ocorrerem. Graças Itagaki Takahiro e a equipe da NTT.

Obs: Esta alteração permite triggers mais específicas com menos validações internas, possivelmente impactando positivamente seu desempenho.

13/12/2009 - Constraints de exclusão (por Jeff Davis) permitem que você especifique como únicos "dados" que abranjam um intervalo, como uma área geométrica, um período de tempo, ou um array.

Obs: Função importante para quem trabalha com lógicas de negócios no banco de dados.

Abaixo, a redação oficial da coluna:

07/03/2010 - EXPLAIN output can be formatted as XML, JSON, and YAML, making machine parsing much simpler. The traditional text format is still the default format.

28/02/2010 - The pgbench suite is now multi-threaded, allowing you to take advantage of multiple CPU cores.

21/02/2010 - You can now control the behavior of distinct values per column using ALTER TABLE...ALTER COLUMN...SET (parameter=value,...) where parameter can be one of n_distinct and n_distinct_inherited. Positive numbers are assumed to be the number of distinct values, 0 tells the planner to use the results from ANALYZE, and negative numbers (which should be between -1 and 0, cause the planner to estimate the number of distinct values as the estimated number of rows multiplied by the absolute value of the number.

14/02/2010 - Uniqueness violations now raise more detailed error messages.

31/01/2010 - Uniqueness constraints can now be deferred until commit time.

24/01/2010 - The DROP IF EXISTS syntax now works on columns and constraints.

17/01/2010 - VACUUM FULL has been changed to now generate all-new files for the vacuumed table and indexes. This is based on the old CLUSTER command, and is both more efficient and more effective. The old functionality of VACUUM FULL can still be accessed via VACUUM FULL INPLACE, but will be incompatible with Hot Standby.

10/01/2010 - You can now log SQL state for queries, errors, etc., using %e in your log_line_prefix.

03/01/2010 - In psql, \d now shows how many inherited tables a parent has, and \d+ lists them.

27/12/2009 - Hot Standby. After 1.5 years of development, you can at last run read-only queries against PITR slaves. Thanks to Simon Riggs, Heikki Linnakangas, any many others for unceasing efforts.

20/12/2009 - WHEN clauses on Triggers. In 8.5Alpha3, you will be able to create triggers with a WHEN clause so that they will only execute if specific values or conditions occur. Thanks Itagaki Takahiro and the NTT team.

13/12/2009 - Exclusion Constraints (by Jeff Davis) allow you to specify as "unique" data which covers a range, such as a geometric area, a period of time, or an array.

O que acharam destas novas funcionalidades?

Elas impactarão o seu trabalho atual?

quinta-feira, 4 de março de 2010

Acompanhe o Status do Servidor no PgAdmin III

Acompanhar os acessos ao banco de dados é uma necessidade para quem lida com aplicações de maior porte. O PgAdmin III apresenta um bom painel que premite acompanhar o servidor, mostrando as conexões, bloqueios, transações correntes e o arquivo de log de auditoria.

O recurso pode ser utilizado através do menu "Ferramentas/ Status do Servidor". Abaixo, uma visualização da tela apresentada.


segunda-feira, 1 de março de 2010

DreamCoder for PostgreSQL: Ferramenta Visual

Uma das maiores queixas dos profissionais de banco de dados é a falta de ferramentas visuais robustas.


As opções abertas contribuem para reduzir este problema, mas ainda apresentam deficiências e lacunas de importantes funcionalidades que restringem sua utilização e difusão. Ao mesmo tempo, versões freeware de softwares comerciais podem ser úteis em virtude de suas funcionalidades, apesar de não terem seu código disponibilizado.


O DreamCoder for PostgreSQL é uma opção freeware que promete facilitar o trabalho com este banco de dados uma rápida análise da ferramenta mostrou pontos fortes e deficiências importantes. O software pode ser baixado aqui.


Abaixo, uma tela com a interface da ferramenta.




O editor de plpgsql apresenta bons recursos de formatação que promovem a produtividade.
Vide imagem abaixo.



Pontos Fortes:

- Versão Freeware (a Enterprise pode ser baixada com )
- Atualização Recente (02 de 2010)
- Bom editor de Pl/ PgSQL
- Bons recursos visuais para visualização e navegação nos objetos do banco, mostrando propriedades e dependências.
- Configuração de autosubstituição de caracteres.

Pontos Fracos:

- Não apresenta funções de engenharia reversa e importação.
- Não apresenta assistentes para a criação de tabelas, índices e outros objetos do banco, que devem ser manuseados via DDL, função básica em qualquer ferramenta visual de desenvolvimento.
- Ausência de versão para Linux
- Falta de recursos mais avançados, restritos à versão entreprise.


Resultado geral:

É uma ferramenta boa para os usuários da plataforma Windows que utilizem muito código Pl/ PgSQL. As futuras versões podem trazer avanços mais significativos. Só deve ser utilizada após testes criteriosos. A versão entreprise não foi avaliada neste post.

Versão Alfa do PostgreSQL 9.0 Lançada!

A versão de desenvolvimento ALFA do PostgreSQL 9.0 está disponível para downloads e testes.

Na verdade, é a quarta versão alfa, uma vez que três versões anteriores haviam sido lançadas como sendo para o PostgreSQL 8.5.

Faça o download aqui!

Veja as notas de lançamento com os avanços desta versão aqui!

sexta-feira, 19 de fevereiro de 2010

Select - Cláusulas FOR UPDATE, FOR SHARE e NOWAIT

Influenciar nos mecanismos de bloqueio do banco de dados nem sempre é um processo intuitivo. No entanto, pode ser bastante útil para garantia da confiabilidade de resultados e para ajustes de desempenho.

A existência de bloqueios sobre os dados acessados durante o acesso concorrente não pode ser ignorada em sistemas com grande número de transações concorrentes mesmo no Postgres que utiliza o protocolo de bloqueios multiversão (MVCC - MultiVersion Concurrency Control). 

O PostgreSQL oferece algumas cláusulas relativamente simples que permitem este tipo de controle no caso de consultas no banco de dados: FOR UPDATE, FOR SHARE e NOWAIT.

O uso de consultas com a cláusula FOR UPDATE obriga o servidor a bloquear os registros consultados para leitura e escrita durante o transcorrer da transação. Desta forma se garante que o que está sendo visualizado corresponde ao que está armazenado no banco de dados.

Por sua vez, a cláusula FOR SHARE efetua bloqueio de escrita, mas permite que leituras sejam feitas aos dados consultados.

Em resumo, a cláusula FOR UPDATE restringe os acessos aos dados consultados, enquanto que a FOR SHARE explicitamente autoriza acessos de leitura aos dados consultados. O tipo de transação é que determina se e quando utilizar estas cláusulas.

É importante salientar que ambas as cláusulas se referem apenas os dados que são recuperados na consulta.

Adicionalmente, a cláusula NOWAIT pode ser utilizada tanto com FOR UPDATE quanto com FOR SHARE, e força a ocorrência de erro caso o servidor tenha de esperar para a obtenção de bloqueios nos dados consultados. Desta forma, sacrifica-se a transação para que não se perca tempo na fila de espera por bloqueios.

As cláusulas UNION, INTERSECT e EXCEPT até o momento não são compatíveis com FOR UPDATE e FOR SHARE.

Para os próximos exemplo, serão utilizadas as seguintes tabelas:

CREATE TABLE pai (codpai integer,nomepai varchar(50));
CREATE TABLE filho (codpai integer,codfilho integer,nomefilho varchar(50));

Exemplos:

1 - Sintaxe simples com FOR UPDATE.

SELECT * FROM pai FOR UPDATE;

2 - Sintaxe simples com FOR SHARE.

EXPLAIN SELECT * FROM pai FOR SHARE;

3 - Uso de FOR SHARE em consulta com junção.

SELECT *
FROM pai p, filho f
WHERE p.codpai = f.codpai
FOR SHARE;

4 - Uso de NOWAIT.

SELECT * FROM pai FOR UPDATE NOWAIT;

5 - Uso de FOR UPDATE em transação de atualização.

BEGIN;
SELECT * FROM pai FOR UPDATE;
UPDATE pai SET nomepai = nomepai ' Father';
COMMIT;

quarta-feira, 27 de janeiro de 2010

Algoritmos: Caixa de Banco Simulado no PostgreSQL

Ao retirar dinheiro de um caixa eletrônico, solicitamos uma quantia e o caixa decide quantas notas de cada tipo disponível nós receberemos. O algoritmo que faz esta decisão é relativamente simples.

Abaixo coloco uma função que recebe uma solicitação de dinheiro e calcula quantas notas de 100, 50, 10, 5 e 1 serão retornadas ao solicitante:

--Retornando notas do caixa eletrônico
--Notas de 1, 5, 10, 50 e 100
CREATE OR REPLACE FUNCTION caixa_elet (pvalor integer) RETURNS text AS $$
DECLARE
sretorno text;
qnota1 integer;
qnota5 integer;
qnota10 integer;
qnota50 integer;
qnota100 integer;
BEGIN
sretorno := '';
qnota100 := (pvalor - (pvalor % 100))/100;
qnota50 := ((pvalor % 100) - (pvalor % 50)) /50;
qnota10 := ((pvalor % 50) - (pvalor % 10)) /10;
qnota5 := ((pvalor % 10) - (pvalor % 5)) /5;
qnota1 := ((pvalor % 5) - (pvalor % 1)) /1;
sretorno := 'Total: ' || pvalor || chr(10) || 'Notas de 100:' || qnota100 || chr(10) || 'Notas de 50:' || qnota50 || chr(10) || 'Notas de 10:' || qnota10 || chr(10) || 'Notas de 5:' || qnota5 || chr(10) || 'Notas de 1:' || qnota1;
RETURN sretorno; -- Retorna as linhas
END;
$$ LANGUAGE plpgsql;

Chamada da função e resultado apresentado:

SELECT caixa_elet(1078);

"Total: 1078
Notas de 100:10
Notas de 50:1
Notas de 10:2
Notas de 5:1
Notas de 1:3"

SELECT caixa_elet(2189);

"Total: 2189
Notas de 100:21
Notas de 50:1
Notas de 10:3
Notas de 5:1
Notas de 1:4"

Agora, gostaria de fazer algumas perguntas para os programadores de plantão:
- O código da função caixa_elet está correto?
- O código da função caixa_elet pode ser melhorado de que formas?
- Que alterações seriam necessárias para acrescentar notas de 20?

Aguardo suas contribuições nos comentários!

quinta-feira, 21 de janeiro de 2010

8.5 sai de cena antes de ser lançado: nova versão do Postgres será a 9.0!

O anúncio não é oficial, mas a versão 8.5 terá sua numeração alterada para 9.0. Os testes e o desenvolvimento continuam normalmente.

As razões envolvendo a mudança compreendem o aumento das funcionalidades da nova versão e da abrangência das alterações no código, o grande tempo desde a primeira versão 8.* e um benefício em termos de marketing, pela insinuação de uma mudança mais substancial refletida na alteração de 8.4 para 9.0.

Você concorda com essa atitude?

terça-feira, 5 de janeiro de 2010

PostgreSQL e JDBC: Ótimo exemplo de código!

A utilização de linguagem java nas aplicações com PostgreSQL depende de um middleware para o acesso aos dados. O JDBC oferece conexões com segurança e confiabilidade. Mas como implementar estes acessos?

O link abaixo apresenta um ótimo exemplo introdutório de código java para acesso ao Postgres via JDBC. Confira aqui.

sexta-feira, 18 de dezembro de 2009

Onde esse elefante está? O que nos diz o google insights sobre o ano de 2009?

As pesquisas na internet dizem muito sobre a aceitação de produtos, serviços, candidatos a cargos eletivos e sobre o uso de programas e sistemas. Com o PostgreSQL não é diferente. Fiz uma breve pesquisa sobre o ano de 2009 no google insights e os resultados compartilho neste post. O levantamento do ano passado está aqui.

As imagens capturadas e os dados foram todos coletados dia 18/12/2009.

- O ano de 2009 foi relativamente estável. Houve uma queda nas buscas com a festas de fim de ano e um aumento nas pesquisas durante o lançamento da nova versão 8.4, em meados de abril. A figura 1 mostra a evolução destas buscas no ano.


Considerando os últimos 4 anos, houve uma diminuição nas buscas. No entanto isto não significa necessariamente perda de espaço, podendo indicar também uma maior disseminação do conhecimento sobre o banco, que reduz a necessidade de pesquisas na rede.


- No mundo, Japão e Rússia crescem no ranking relativo de buscas e recuperam as primeiras posições perdidas em 2008 para Cuba e China.


- No mundo ganha destaque a busca "PostgreSQL MySQL", indício de que o PostgreSQL não é considerado uma alternativa tão natural ao Oracle ou ao Sql Server, mas uma boa opção em relação ao MySQL (Esta é apenas uma suposição que carece de mais comprovação!).

- No Brasil destaco as buscas "PostgreSQL Windows" e "PostgreSQL Linux". A pontuação destas buscas mostra que a compatibilidae com vários sistemas operacionais é um importante fator para os projetos de software nacionais.

- O Brasil continua em uma posição intermediária. Na América do Sul o destaque fica para a Bolívia, que ocupa a quarta posição entre os 10 maiores índices de busca pelo PostgreSQL no Google.

- Dentre os estados brasileiros, Distrito Federal e Ceará ocupam as duas primeiras posições. Santa Catarina, Paraná e Rio Grande do Sul estão nas três posições subsequentes, o que mostra a força do PostgreSQL na Região Sul.


Não recomendo que estes dados sejam utilizados para a tomada de decisões. São informações retrospectivas sujeitas a erros estatísticos! 2009 está consumado. Agora é trabalhar pelo 2010!

quinta-feira, 17 de dezembro de 2009

GreenSQL: O Rinoceronte Amigo do Elefante!

Segurança nunca é demais e cautela e caldo de galinha não fazem mal a ninguém! No caso do PostgreSQL não é diferente, e qualquer atualização de segurança é sempre recomendada.

O GreenSQL é um firewall de código aberto que visa proteger bases de dados de ataques tipo "SQL Injection", verificando os comandos submetidos ao banco, restringindo comandos de administrador para criação e destruição de tabelas e outros objetos e impedindo a submissão de códigos maliciosos. Seu símbolo é o do Rinoceronte.



A versão mais recente agregou o suporte ao PostgreSQL ao do MySQL já existente. Espera-se que o Rinoceronte possa agir como guarda costas do elefante a partir deste lançamento! Abaixo, uma imagem da arquitetura do GreenSQL.

A licença é GPL. Teste e me diga o que achou!

quinta-feira, 10 de dezembro de 2009

Enquete aponta que PostgreSQL Crescerá com a Compra do MySQL

A compra recente da Sun pela Oracle, incluindo o banco MySQL começa a trazer mudanças no mercado. Segundo enquete realizada pelo "The 451 Group", há uma tendência de redução do market share do MySQL em detrimento do PostgreSQL e do novo banco de dados MariaDB, que seria um fork livre do MySQL com um processamento de consultas novo e bastante promissor.

Este autor acha que há espaço para todos, e acredita no crescimento do PostgreSQL independentemente do apresentado pelas demais alternativas. Aproveita para lembrar que enquetes revelam apenas intenções, e que o mercado pode tomar outra direção.

O que você acha? O que tem acontecido na sua empresa?

O artigo original pode ser obtido aqui.