Arquivo

Posts Tagged ‘Banco de dados’

Java + JDBC: imprimindo informações de tabelas

Preciso pegar as informações das tabelas/colunas nas quais fiz uma query, e sempre esqueço… Fica a dica aqui com um código bem bobinho. sugestões são bem vindas.

		Statement stmt = connection.createStatement();
		ResultSet rs = stmt.executeQuery("SELECT * FROM TABLE FETCH FIRST 10 ROWS ONLY");

		ResultSetMetaData rsmd = rs.getMetaData();
		int columnCount = rsmd.getColumnCount();

		// The column count starts from 1
		for (int i = 1; i <= columnCount; i++ ) {
		  String name = rsmd.getColumnName(i);
		  System.out.print(name + "|");
		}
		System.out.println();
		
		while (rs.next()) {
			String toPrint = "";
			for (int col = 1; col <= columnCount; col++) {
				toPrint += rs.getString(col) + "|";
			}
			System.out.println(toPrint);
		}

Diferença entre os comandos CONNECT e ATTACH no DB2

fevereiro 23, 2011 1 comentário

Muitos novos usuários tem dúvidas sobre os comandos CONNECT e ATTACH no DB2.

Para falar a diferença, primeiro tenho que dar um conceito: O DB2 trabalha com Instancias, uma Instancia pode ter N bancos de dados. Em um computador, posso ter N Instancias, cada uma com N bancos de dados.

Dito isso, posso definir:

  • Attach é utilizado em uma applicação que precisa trabalhar a nivel de instância, por exemplo, alterando parametros da instância.
  • Connect é utilizado em aplicações que vão trabalhar com um banco de dados em específico.

Para poder conectar em uma instância do DB2, é necesário setarmos a variável de instancia DB2INSTANCE (export DB2INSTANCE=banana), e então utilizar o comando:

db2 attach to banana

Agora, supondo que eu tenha um banco de dados chamado abacaxi, e quero me conectar nele, o comando é:

db2 connect to abacaxi

Enjoy!

Boas práticas para Banco de Dados

Em geral, DBAs e Desenvolvedores não conhecem muito bem boas práticas para otimizarem seu ambiente/aplicação, muitas vezes isso decorre da falta de boa formação ou falta de experiência mesmo. Para ajudar com isso, a IBM dispões de um site muito interessante com uma coleção de boas práticas para DB2, porém boa parte pode ser aplicada para outros BDs. O site fala desde instalação até escrita de aplicações.

O link para o mesmo está aqui.

Aproveitando o post, a algum tempo eu criei um artigo com boas práticas em SQL para desenvolvedores que pode ser útil, aqui está o link.

Enjoy!

Instalando e configurando o PostgreSQL 8.4 no Ubuntu

Instalando e configurando o PostgreSQL 8.4 no UbuntuNo meu ambiente de desenvolvimento, eu sempre utilizo dois bancos: o Postgres e o DB2. Basicamente devido ao fato de minha instalação de DB2 ser pesada pois tenho várias configurações de Data Warehouse e um banco muito carregado, o que torna o banco mais pesado para meu simples desktop. Então, para debugar meus softwares, vou com meu postgres levinho mesmo.

Minha idéia aqui é mostrar como instalar e configurar o PostgreSQL 8.4 no Ubuntu 9.04. As configurações são as mesmas para a instalação em Windows, a única diferença obvia é que você irá ter que ir ao site do postgres e baixar o Installer do Windows.

Vamos lá, iniciamos a instalação com o comando:

$ sudo apt-get install postgresql-8.4 postgresql-client-8.4

Recomendo também instalar o pgAdmin, que é uma ferramenta para administrar o postgres:
$ sudo apt-get install pgadmin3 pgadmin3-data

Algo que aconteceu comigo na migração para o Ubuntu 9.04, foi que tive que remover o Postgres 8.3 (apt-get purge postgresql-8.3) para conseguir iniciar o 8.4 corretamente. Se você concluir meus passos aqui e mesmo assim não conseguir conectar no Postgres, recebendo algum erro, provavelmente terá que dar o purge. (talvez com mais tempo de pesquisa eu poderia descobrir qual era o problema… se alguem passar por isso me diga please).

O próximo passo é setar uma senha para o usuário postgres com os seguintes comandos:

sudo su postgres -c psql postgres
ALTER USER postgres WITH PASSWORD ‘password’;
\q

O primeiro comando chama o utilitário psql com o usuário postgres e conecta no postgres especificamente no database postgres.
O segundo comando altera a senha do usuário postgres.
O terceiro comando finaliza o psql.
Note que a palavra password deve ser substituida pela password que você desejar.

Feito a instalação e mudança de senha do usuário postgres, você estará apto a desenvolver um trabalho no seu computador conectando normalmente ao postgres, porém, se a idéia é disponibilizar o acesso ao banco para receber conexões de outras máquinas, você vai ter que alterar dois arquivos para isso. Para isso, vá para o diretório /etc/postgres/8.4/main

Edite o arquivo postgresql.conf

Na linha listen_addresses, troque o localhost por *, ficando a linha assim:

listen_addresses = ‘*’

Dessa forma seu postgres vai “escutar” não só conexoes provenientes da sua própria máquina.

A próxima configuração no mesmo arquivo é habilitar a encriptação de passwords, para fazer isso descomente a linha abaixo simplesmente removendo o # da frente dela:

password_encryption = on

Finalmente a próxima configuração é no arquivo pg_hba.conf. Neste arquivo você consegue restringir o acesso ao seu banco de dados por IP. Normalmente queremos liberar o acesso para todos os IPs em uma faixa, no meu exeplo, quero liberar para todas as máquinas da rede 10.5.2.*, então eu adiciono a seguinte linha no meu pg_hba.conf:

host all all 10.5.2.0 255.255.0.0 md5

Feito isso, basta reiniciar o postgres com o comando:

sudo /etc/init.d/postgresql-8.4 restart

Enjoy!

Introdução a Data Warehouse (DW for dummies)

OBS: Este artigo destina-se a pessoas que tem conhecimentos básicos sobre banco de dados e querem saber o que é Data Warehouse.

Em uma empresa que utiliza um sistema de banco de dados, diariamente são efetuadas N transações. Quando uma compra é efetuada por exemplo, ocorrem várias operações no banco (selects, inserts, updates e deletes). Imagine um sistema maior agora, o que registra as ligações em uma empresa de telefonia celular. Pensando superficialmente, quando você inicia uma ligação, um insert é executado, registrando os dados da ligação, tais como horário de início e número discado. Quando você desliga seu celular, é efetuado um update na linha que foi inserida, registrando dentre outros dados, a hora na qual a ligação foi finalizada. Estas base de dados, tem que estar preparadas para responder rapidamente a transações pequenas e rápidas. Tais bases tem que ter um nível de disponibilidade altíssimo. Não podem cair nunca! Elas são conhecidas como bancos de dados transacionais ou OLTP – Online Transaction Processing ou Processamento de transações em tempo-real.

Os gerentes da empresa de telefonia demandam relatórios sobre as ligações, então naturalmente você já deve estar imaginando um gigantesco select sendo feito na tabela de ligações, cruzando dados com a tabela de clientes, cidades, estados, país, etc, etc, etc. Tudo isso para um simples relatório para ver os dados sobre as ligações que foram feitas em um determinado período por exemplo.

Você acha possível rodar este “simplesselect na base que está sofrendo as operações para cadastro de ligações? Sim, possível até que é! Porém é arriscadíssimo e demorado. Um select como este pode facilmente gerar um estouro de memória em uma base, pode retardar outras operações, dentre vários outros problemas.

Qual a solução? Por que não fazer uma “cópia” dos dados em um outro banco de dados distinto, o qual poderá sofrer enormes selects sem afetar o sistema da empresa que não pode parar ou sofrer com lentidão. Essa base criada é a tal de Data Warehouse, também conhecida como DW!

Mas em quais momentos essa “cópia” é feita? Depende! Cada empresa define o momento mais oportuno. Pode ser semanalmente, duas vezes por semana, antes de rodar a folha de pagamentos, etc. Geralmente as grandes empresas de telefonia iniciam a alimentação seus DWs a meia noite (e terminam por volta das 5 da manhã). Tente ligar para a sua operadora neste horário e perceba que o atendente vai falar que o sistema está lento.

As técnicas envolvidas nesta “cópia” são as mais diversas possíveis. Porém você deve ter reparado que todas as ocorrências da palavra cópia no texto acima estão entre aspas certo? Normalmente, não é feita uma simples cópia. São copiados somente os dados relevantes para o DW, ou seja, os dados que serão utilizados nos relatórios, prognósticos, previsões, etc. Neste momento também podem ocorrer algumas transformações nos dados, alguma conversão, a aplicação de uma equação, de-normalização, etc. A esta operação é dado o nome de ETL – Extraction, Transformation and Load.

Este processo de carregamento também é chamado de um processo Batch ou em Lote. Pois movimenta grande quantidade de dados de uma só vez.

Um Data Warehouse tem que ser otimizado para sofrer enormes operações de busca, porém um DW não sofre somente selects. Cada dia mais os DWs estão ficando “espertos”, o termo utilizado comercialmente é SMART. O que é isso exatamente? Imagine que você carregou seu DW com os dados das ligações e quer gerar um relatório que além dos dados cadastrados em banco irá trabalhar com os mesmos para gerar forecasts, ou seja, previsões, dentre outras. Então várias operações podem ocorrer em banco para preparar os dados. Com base nos dados “antigos”, o banco deve ser capaz de mostrar tendências de comportamento por exemplo. Então acabam ocorrendo outras operações no DW além do select para preparar os dados.

Em teoria, qualquer banco de dados disponível no mercado pode ser utilizado com um DW. Obviamente que vão existir diferenças em desempenho, recursos e escalabilidade. É perfeitamente possível se criar um DW utilizando o MySQL, porém análises técnicas apontam que o mesmo não tem o nível de escalabilidade de um IBM DB2 ou um Oracle por exemplo. Convém a empresa interessada fazer uma extensa pesquisa de mercado antes de escolher seu produto.

Quanto a equipamentos, normalmente um banco de dados já demanda um servidor muito poderoso e enorme quantidade de memória ram. Para um DW, as exigências são maiores ainda. É importante observar que quando falo “um servidor”, quero dizer um servidor de banco de dados que pode ser constituído por um ou N computadores. Em grandes bancos, um DW pode ser 50 computadores, cada um com 8 processadores de 8 cores e 200 gigas de memória ram por computador. Os dados em si são armazenados em equipamentos chamados storages, totalizando uma capacidade de vários Terabytes!

Enfim, espero ter dado uma boa visão introdutória sobre DW. Se quiser se aprofundar mais, sugiro procurar por livros relacionados. O “Papa” do DW é o autor Ross Kimball, qualquer livro dele vai agregar muito.

Em breve postarei artigos sobre storages e servidores. Estou aberto a sugestões, críticas e dúvidas.

Enjoy!

Instalando e configurando o PostgreSQL 8.3 no Ubuntu

Instalando e configurando o PostgreSQL 8.3 no UbuntuNo meu ambiente de desenvolvimento, eu sempre utilizo dois bancos: o Postgres e o DB2. Basicamente devido ao fato de minha instalação de DB2 ser pesada pois tenho várias configurações de Data Warehouse e um banco muito carregado, o que torna o banco mais pesado para meu simples desktop. Então, para debugar meus softwares, vou com meu postgres levinho mesmo.

Minha idéia aqui é mostrar como instalar e configurar o PostgreSQL 8.3 no Ubuntu 8.04. As configurações são as mesmas para a instalação em Windows, a única diferença obvia é que você irá ter que ir ao site do postgres e baixar o Installer do Windows.

Vamos lá, iniciamos a instalação com o comando:

$ sudo apt-get install postgresql-8.3 postgresql-client-8.3

Recomendo também instalar o pgAdmin, que é uma ferramenta para administrar o postgres:
$ sudo apt-get install pgadmin3 pgadmin3-data

Algo que aconteceu comigo na migração para o Ubuntu 8.04, foi que tive que remover o Postgres 8.2 (apt-get purge postgresql-8.2) para conseguir iniciar o 8.3 corretamente. Se você concluir meus passos aqui e mesmo assim não conseguir conectar no Postgres, recebendo algum erro, provavelmente terá que dar o purge. (talvez com mais tempo de pesquisa eu poderia descobrir qual era o problema… se alguem passar por isso me diga please).

O próximo passo é setar uma senha para o usuário postgres com os seguintes comandos:

sudo su postgres -c psql postgres
ALTER USER postgres WITH PASSWORD ‘password’;
\q

O primeiro comando chama o utilitário psql com o usuário postgres e conecta no postgres especificamente no database postgres.
O segundo comando altera a senha do usuário postgres.
O terceiro comando finaliza o psql.
Note que a palavra password deve ser substituida pela password que você desejar.

Feito a instalação e mudança de senha do usuário postgres, você estará apto a desenvolver um trabalho no seu computador conectando normalmente ao postgres, porém, se a idéia é disponibilizar o acesso ao banco para receber conexões de outras máquinas, você vai ter que alterar dois arquivos para isso. Para isso, vá para o diretório /etc/postgres/8.3/main.

Edite o arquivo postgresql.conf. (dica: se não tiver permissão para editar, va em um terminal e digite “sudo gedit /etc/postgres/8.3/main/postgresql.con”)

Na linha listen_addresses, troque o localhost por *, ficando a linha assim:

listen_addresses = ‘*’

Dessa forma seu postgres vai “escutar” não só conexoes provenientes da sua própria máquina.

A próxima configuração no mesmo arquivo é habilitar a encriptação de passwords, para fazer isso descomente a linha abaixo simplesmente removendo o # da frente dela:

password_encryption = on

Finalmente a próxima configuração é no arquivo pg_hba.conf. Neste arquivo você consegue restringir o acesso ao seu banco de dados por IP. Normalmente queremos liberar o acesso para todos os IPs em uma faixa, no meu exeplo, quero liberar para todas as máquinas da rede 10.5.2.*, então eu adiciono a seguinte linha no meu pg_hba.conf:

host    all    all    10.5.2.0    255.255.0.0    md5

Feito isso, basta reiniciar o postgres com o comando:

sudo /etc/init.d/postgresql-8.3 restart

Enjoy!

Boas práticas em SQL para desenvolvedores

dezembro 19, 2007 11 comentários

Boas práticas em SQL para desenvolvedoresQuem nunca ouviu alguem reclamar: “o sistema está lento hoje!!!”? Nestes relatos de degradação de desempenho, frequentemente levantamos que esta degradação é decorrente de instruções SQL mal estruturadas ou ainda banco de dados mal planejado, o que, num efeito cascata, só é sentido conforme o sistema vai sendo utilizado, as tabelas sendo povoadas, etc. O SGDB começa a exigir muito processamento, memória e a gerar gargalos na rede, causando assim, efeitos no desempenho da aplicação e na rede!

Outro fato é que atualmente, boa parte dos desenvolvedores desenvolvem código SQL sem ter muito conhecimento sobre fundamentos de banco de dados. Tal falta de conhecimento gera a produção de código ineficiente e com baixa performance. É comum ver equipes de desenvolvimento que não tem um DBA, ficando assim, o desenvolvedor com a tarefa de criar um banco de dados.

Com estes problemas em mente, resolvi criar este post com algumas dicas para que os desenvolvedores tenham algum conteúdo básico e rápido e melhorem suas instruções SQL e a criação de banco de dados.

Tentarei ser o mais genérico possível para conseguir cobrir os bancos de dados mais utilizados atualmente (DB2, Oracle, MySql, Postgres, etc), porém, algumas dicas podem não ser aplicáveis a todos os bancos.

É importante lembrar que praticamente todas as dicas são “debatíveis” em diferentes cenários, portanto, fiquem a vontade para comentar.

Vamos lá:

1- Normalize seu banco de dados. Isso quer dizer básicamente, divida tabelas grandes em tabelas menores e remova redundancia, ou seja, que dados estejam duplicados sem real necessidade.

2. Em instruções select, evite usar “*”. Seja restritivo, traga somente os campos realmente necessários, isso alivia a memória do servidor, diminue tráfego na rede, etc. Algumas pessoas defendem que tambem não devem ser criados determinados campos, por exemplo, você tem A + B e pretende guardar C onde C = A + B. Ao invéz de criar uma coluna para armazenar C, passe a utilizar “select (A+B) AS C from tabela”. Esse pensamento pode não ser necessariamente válido para Dws. Vamos supor que você tem uma tabela enorme com dados sobre salário por ano. Você pode armazenar o percentual de ajuste e o valor ajustado, fazendo ai uma “desnormalização” para que o comando que vai recuperar os valores do salário não “frite” a CPU forçando-a a fazer muitas contas e perdendo muito desempenho.

3. Existe muito debate sobre essa: Não utilize seu banco de dados para armazenar imagens, ao invéz disso, armazene a URL. Vale lembrar que os bancos de dados atuais estão cada vez mais aprimorados na manipulação de imagens, portanto, aqui abre-se espaço para uma enorme discussão, benchmarck, etc.

4. Para obter maior performance, utilize chaves primárias numéricas ou ainda campos pequenos nas chaves.

5. Utilizando-se stored procedures e functions ao invéz de escrever código no seu programa, vai garantir maior desempenho e segurança para seu sistema como um todo.

6. Utilize o conceito de transações. Vários problemas podem ocorer, por exemplo, a rede cair. Aprenda sobre commit e rollback.

7. Use sempre o tipo de dados correto para armazenar os dados. Por exemplo, não armazene sexo, que vai ser M ou F em um campo Varchar, use apenas 1 caractere: CHAR(1).

8. Evite o uso de cursores, eles consomem muito tempo já que “navegam” registro por registro.

9. Otimize a clausula WHERE: Simples exemplos são o uso de “>” e “>=”. Se você quer retornar todas as pessoas de uma tabela que tem idade “> 3”, use no where “>=4”, dessa forma o banco não fará o scan das páginas até encontrar o 3. Esse princípio é válido desde que você tenha um índice na idade.

10. Quando possivel, crie instruções SQL idênticas, pois no momento da execução de uma instrução, o banco compila a mesma e a preserva em memória, na próxima execução, não vai precisar compilar novamente. Uma ótima técnica para fazer isso é utilizar variáveis nas suas instruções ao invés de passar parametros para o banco.

11. Utilize os mecanismos do banco de dados para persistência: Primary Key, Foreign Key, etc são feitos e otimizados para isso.

12. Quando possivel, trave (lock) uma tabela para executar alguma operação que vai demandar muito acesso a esta tabela, por exemplo, se você vai alterar a estrutura de uma tabela grande ou importar dados neste tabela (falando-se de tabelas realmente grandes).

13. Sempre utilize o nome das colunas em instruções SELECT, INSERT, UPDATE evitando utilizar “*”.

14. Evite utilizar o operador “LIKE”, ele pode facilmente fazer o desempenho de um banco de dados ruir!

15- Utilize EXISTS ao invéz de COUNT para verificar se existe um determinado registro em uma tabela. É comum ver desenvolvedores fazendo um “select count(X) from Y” para verificar se o COUNT é maior que 0. Utilizando-se EXISTS, o sgbd vai parar no primeiro registro encontrado, se utilizar count, o banco vai varrer toda a tabela.

16- Em joins de tipos de dados diferentes, o SGBD vai ter que converter o tipo hierarquicamente inferior para o outro tipo a fim de efetuar a comparação, e assim, não vai utilizar um índice caso exista.

17. Sobre índices:

  • Não crie indices em campos que são alterados constantemente, pois o banco vai ter que atualizar toda sua estrutura de índices em qualquer update feito no campo.
  • Prefira criar os indices em chaves primárias e estrangeiras, e em suas queries, utilize estes índices.
  • Não tenha muitos índices em seu banco, só o necessário: uma breve explicação sobre o motivo disso, é que o banco de dados mantem toda uma estrutura para gerenciar os índices, então, quanto mais índices, mais tempo/processamento o SGBD vai utilizar para a manutenção dos mesmos.
  • No momento de importação/importação de uma base de dados, não exporte/importe índices. Isso vai consumir mais tempo/processamento. Tambem pode-se não fazer backup de índices.
  • Não crie índices em colunas que possuem pouca variação de valores.

18. Entenda os fundamentos de banco de dados. Uma ótima leitura é o livro “Sistema de Banco de Dados”, de Abraham Silberschatz, Henry F. Korth e S. Sudarshan lançado no Brasil pela Editora Elsevier.