[PostgreSQL] - Alterando o encoding de um banco

Bem, essa dica não serve para converter um banco já existente de UTF-8 para LATIN1, para isso existem outras técnicas. A idéia apresentada aqui é para quando você tem um Dump LATIN1 e precisa restaurar em um novo servidor com o mesmo encoding, mas  o Locale de seu Sistema Operacional não permite que você crie um banco LATIN1.

O erro de Locale aparece quando você executa:

# CREATE DATABASE xpto ENCODING ‘latin1′ TEMPLATE template0;
ERROR: encoding “LATIN1″ does not match locale “pt_BR.UTF-8″
DETAIL: The chosen LC_CTYPE setting requires encoding “UTF8″.

Ocorre devido ao Locale estar configurado para UTF-8, você pode corrigir o locale, mas também pode simplesmente criar o banco em UTF-8 e depois alterar para LATIN1

# CREATE DATABASE xpto TEMPLATE template0;

Assim você acabou de criar o banco xpto com encoding UTF-8, para conferir basta dar um \l no PSQL.

Agora para alterar para LATIN1 basta executar:
# update pg_database set encoding = pg_char_to_encoding(‘LATIN1′) where datname = ‘xpto’;

Pronto, confira novamente com \l que o encoding já esta alterado.

Agora é só restaurar seu dump.

Referencia:
http://jf.eti.br/alterando-o-encoding-de-um-banco-postgresql/

[PostgreSQL] - Script para Pré-Configuração do Linux

Bom pessoal,

Abaixo, Script de pré-configuração de SO Linux :

#!/bin/bash
# insere paramentros no /etc/sysctl.conf para o postgres
echo ' ' >> /etc/sysctl.conf
echo '# postgres' >> /etc/sysctl.conf
echo 'kernel.shmmni = 4096' >> /etc/sysctl.conf
echo 'kernel.sem = 250 32000 100 128' >> /etc/sysctl.conf
echo 'net.ipv4.ip_local_port_range = 9000 65500' >> /etc/sysctl.conf
echo 'net.core.rmem_default = 1048576' >> /etc/sysctl.conf
echo 'net.core.rmem_max = 1048576' >> /etc/sysctl.conf
echo 'net.core.wmem_default = 262144' >> /etc/sysctl.conf
echo 'net.core.wmem_max = 262144' >> /etc/sysctl.conf

# recarrega confs do /etc/sysctl.conf
sysctl -p

# insere limits de utilizacao do postgres no SO
echo ' ' >> /etc/security/limits.conf
echo '# postgres' >> /etc/security/limits.conf
echo 'postgres  soft    nofile  1024' >> /etc/security/limits.conf
echo 'postgres  hard    nofile  65536' >> /etc/security/limits.conf

[PostgreSQL] - Checklist de Performance

Cinco Princípios de Hardware para Configurar o seu Servidor PostgreSQL

Discos > RAM > CPU

Se você vai gastar dinheiro em um servidor PostgreSQL, gaste em arranjos de discos de alta performance e tenha processadores medianos e uma memória adequada. Se você tiver um pouco mais de dinheiro, adquira mais RAM. PostgreSQL, como outros SGDBs que suportam ACID, utilizam E/S muito intensamente e é raro uma aplicação utilizar mais a CPU do que a placa SCSI (com algumas exceções, claro). Isto se aplica tanto a pequenos como grandes servidores; obtenha uma CPU com custo baixo se isso permitir você comprar uma placa RAID de alta performance ou vários discos.

Mais unidades de discos == Melhor

Tendo múltiplos discos, o PostgreSQL e a maioria dos sistemas operacionais irão paralelizar as requisições de leitura e gravação no banco de dados. Isto faz uma enorme diferença em sistemas transacionais, e uma significativa melhoria em aplicações onde o banco de dados inteiro não cabe na RAM. Com os tamanhos mínimos de discos (72GB) você será tentado a utilizar apenas um disco ou um único par espelhado em RAID 1; contudo, você verá que utilizando 4, 6 ou até 14 discos irá render um impulso na performance. Ah, e SCSI é ainda significativamente melhor em fluxo de dados em BD que um IDE ou mesmo um Serial ATA.

Separe o Log de Transações do Banco de Dados:

Assumindo que você já investiu dinheiro num arranjo com tamanho decente num conjunto de discos, existe um monde de opções mais inteligentes do que jogar tudo num único RAID. De inicio coloque o log de transações (pg_xlog) no seu próprio recurso de discos (um arranjo ou um disco), o que causa uma diferença de cerca de 12% na performance de bancos de dados com grande volume de gravações. Isto é especialmente vital em pequenos sistemas com discos SCSI ou IDE lentos: mesmo em um servidor com dois discos, você pode colocar o log de transações sobre o disco do sistema operacional e tirar algum benefício.

RAID 1+0/0+1 > RAID 5:

RAID 5 com 3 discos tem sido um desafortunado padrão entre vendedores de servidores econômicos. Isto possibilita a mais lenta configuração de discos possível para o PostgreSQL; você pode esperar pelo menos 50% a menos de velocidade nas consultas em relação ao obtido com discos SCSI normais. Por outro lado, foque em RAID 1 ou 1+0 para um conjunto de 2, 4 ou 6 discos. Acima de 6 discos, o RAID 5 começa a ter uma performance aceitável novamente, e a comparação tende a ser bem melhor com base na sua controladora individual. No entanto, o mais importante, usar uma placa RAID barata pode ser um risco; é sempre melhor usar RAID por software do que um incorporado numa placa Adaptec que vem com seu servidor.

Aplicações devem rodar bem junto:

Outro grande erro que eu vejo em muitas organizações e colocar o PostgreSQL em um servidor com várias outras aplicações competindo pelos mesmos recursos. O pior caso é colocar o PostgreSQL junto com outros SGDBs na mesma máquina; ambos bancos de dados irão lutar pela banda de acesso aos discos e o cache de disco do SO, e ambos vão ter uma performance pobre. Servidores de arquivo e programas de log de segurança também são ruins. O PostgreSQL pode compartilhar a mesma máquina com aplicações que utilizam principalmente CPU e RAM intensamente, como o Apache, garantindo que exista RAM suficiente.

[MySQL] - Migrando MySQL para PostgreSQL

Bom pessoal, segue abaixo instruções para migração de bancos de dados MySQL para PostgreSQL com a ferramenta da EnterpriseDB.

Link para download da Ferramenta:

https://www.dropbox.com/s/0en05h9goejgapz/EnterpriseDB-MigrationToolkit.zip?dl=0

Podemos também fazer o download pelo site da EnterpriseDB:
http://www.enterprisedb.com/products-services-training/products-overview/postgres-plus-solution-pack/migration-toolkit

Migra Somente estrutura do Banco de dados sem chaves estrangeiras

cmd>runMTK.bat -schemaOnly -allTables -constraints -skipFKConst -sourcedbtype mysql employees

Migra somente os dados através de lotes de dados

cmd>runMTK.bat -dataOnly -fetchSize 1 -sourcedbtype mysql employees

Migra todo banco de dados com constraints e dados

cmd>runMTK.bat -fetchSize 1 -sourcedbtype mysql employees

-------

Configuração do arquivo "toolkit.properties":

SRC_DB_URL=jdbc:mysql://127.0.0.1/employees
SRC_DB_USER=root
SRC_DB_PASSWORD=teste

TARGET_DB_URL=jdbc:postgresql://localhost:5432/exemplo
TARGET_DB_USER=postgres
TARGET_DB_PASSWORD=teste

-------

Dentro da pasta do aplicativo, existe um arquivo chamado "mtk-readme.txt" que possui o help do utilitário.

-------

OBS:

Tendo o Java já instalado na sua maquina copie todos os .jar da pasta lib para a pasta C:\Program Files (x86)\Java\jre6\lib\ext ou lib\ext dentro da sua versão do Java que está instalada.

[JASPER] - Configurando formatação de Data

Bom Pessoal ,

Vou deixar uma dica aqui para efetuar formatação de data em tempo de execução no Jasper:

http://jasper-bi-suite.blogspot.com.br/2013/05/date-parameters-in-ireport-designer-or.html

Exemplo:

new SimpleDateFormat("dd/MM/yyyy").format(new Date().getTime())

[SQL] - BD de Cep 2014 para MySQL, PostgreSQL e Oracle

Bom pessoal, venho compartilhar a base de CEP 2014(17/01/2014) do Brasil em vários bancos de dados para facilitar o cadastro de endereçamento em diversa aplicações.

Segue abaixo, link para download:
https://www.dropbox.com/s/78zuhdotwdqr4kb/banco_de_dados_cep_17_01_2014.rar?dl=0

Espero que possa ajudar desenvolvedores que precisem de uma base de dados de endereçamento atualizada.

[SQL] - BD de Municípios IBGE 2013 e 2014 ( Oracle, MySQL, PostgreSQL e MS SQL Server)

Bom pessoal, venho compartilhar base de municípios do IBGE 2013 e 2014 atualizada para diversos bancos de dados, sendo Oracle, MySQL, PostgreSQL e MS SQL Server.

Segue abaixo, link para download:
https://www.dropbox.com/s/we4vis6p96cpkux/municipio_ibge.zip?dl=0

Espero que possa ajudar.

[MySQL] - Gerando XML de Consultas

Bom pessoal essa dica é para gerar XML de consultas no MySQL.

Comando:
mysql --xml -uroot -e "select * from information_schema.schemata" -p > resultset.xml

Documentação: http://dev.mysql.com/doc/refman/5.6/en/mysql-command-options.html#option_mysql_xml

Transações no PostgreSQL

O que são transações?

Transações são conjuntos de instruções enviadas ao banco de dados que devem ser tratadas com uma única operação. Ou o servidor realiza tudo ou não realiza nada. O exemplo clássico usado em 110% dos cursos de bancos de dados é a famosa transação financeira de transferência de fundos. Imagine que Mônica deseje transferir 100,00 reais para a conta de Cebolinha. Esta operação na realidade se divide em duas. Um débito na conta de Mônica e um crédito de mesmo valor na conta de Cebolinha (a ordem não interfere). Agora, se logo após o débito na primeira conta, o servidor sair do ar antes de que possa executar a segunda. Para onde foram os 100,00 reais?
Existem quatro características que os SGBDs devem garantir se pretendem lidar com transações com segurança. O conjunto dessas características é conhecido como ACID (atomicity, consistency, isolation, durability). Vejamos o que significam:

Transações no MySQL

Bom pessoal, vou disponibilizar material de estudo sobre transações no MySQL:

https://www.dropbox.com/s/7q359tc553jdnaj/Transaccao.doc

[MySQL] - Alterando o Collation do BD e Tabelas

Bom pessoal, nesse post vou colocar os comandos para fazer a alteração de Collation do seu banco de dados MySQL, como também das suas tabelas e colunas:

1. Alterar o collation da base de dados:

ALTER DATABASE ‘base-de-dados’ DEFAULT CHARACTER SET charset COLLATE collation;

Ex:
ALTER DATABASE `base_de_dados` DEFAULT CHARACTER SET latin1 COLLATE latin1_general_ci;
ALTER DATABASE `base_de_dados` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;

2. Alterar o collation da tabela:

ALTER TABLE ‘tabela’ DEFAULT CHARACTER SET charset COLLATE collation;

Ex:
ALTER TABLE `produtos` DEFAULT CHARACTER SET latin1 COLLATE latin1_general_ci;
ALTER TABLE `clientes` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;

3. Alterar o collation do campo de uma tabela:

ALTER TABLE tabela CHANGE campo_nomeatual campo_novonome tipo(tamanho) CHARACTER SET encoding COLLATE collation;

Ex:
ALTER TABLE `produtos` CHANGE `nome` `nome` TEXT CHARACTER SET latin1 COLLATE latin1_general_ci;
ALTER TABLE `clientes` CHANGE `nome` `nome` VARCHAR( 10 ) CHARACTER SET utf8 COLLATE utf8_general_ci;

Fonte:

http://ajuda.uolhost.com.br/index.php?p=resposta&res=891#rmcl

[Oracle] - Script par extrair DDL de tablespaces

Bom pessoal, segue abaixo script para geração de SQL para criação de tablespaces no Oracle:

set pagesize 0
set feedback off
set linesize 1000
spool cre_tbs.sql
select 'create tablespace ' || df.tablespace_name || chr(10)
|| ' datafile ''' || df.file_name || ''' size ' || df.bytes
|| decode(autoextensible,'N',null, chr(10) || ' autoextend on maxsize '
|| maxbytes)
|| chr(10)
|| 'default storage ( initial ' || initial_extent
|| decode (next_extent, null, null, ' next ' || next_extent )
|| ' minextents ' || min_extents
|| ' maxextents ' || decode(max_extents,'2147483645','unlimited',max_extents)
|| ') ;'
from dba_data_files df, dba_tablespaces t
where df.tablespace_name=t.tablespace_name;
spool off
set pagesize 20
set feedback on
set linesize 150

A consulta não é de minha autoria e o original pode ser encontrado em:
http://toolkit.rdbms-insight.com/gen_cre_ts.php

[Oracle] - Uso nls_language em funções SQL

Poucas pessoas sabem que boa parte das funções SQL do Oracle suportam sobrepor as configurações da sessão no que tange o NLS (national language support), abaixo exemplos da utilização dessa sintaxe:

TO_DATE ('1-JAN-99', 'DD-MON-YY', 'nls_date_language = American') 
TO_CHAR (hire_date, 'DD/MON/YYYY',  'nls_date_language = French')  
TO_NUMBER ('13.000,00', '99G999D99', 'nls_numeric_characters = '',.''')  
TO_CHAR (salary, '9G999D99L', 'nls_numeric_characters = '',.''
                               nls_currency = '' Dfl''') 
TO_CHAR (salary, '9G999D99C', 'nls_numeric_characters = ''.,''
                               nls_iso_currency = Japan') 
NLS_UPPER (last_name, 'nls_sort = Swiss')  
NLSSORT (last_name, 'nls_sort = German')

Fonte: http://download.oracle.com/docs/cd/B10500_01/server.920/a96529/ch7.htm

http://oraclemais.blogspot.com.br/2010/09/uso-nlslanguage-em-funcoes-sql.html 

[Oracle] - Habilitando autoextend para datafiles

O DBA hoje em dia não precisa mais se preocupar com o overhead causado pela extensão automática dos datafiles. Soluções como gerenciamento local das tablespaces e infraestrutura de hardware mais competentes absorvem quase que totalmente o impacto. Sendo assim, habilitar esse recurso ajuda a deixar a administração do banco mais fácil.
Ex.:
alter database datafile '+DATA/dr/datafile/users.264.708874247' autoextend on next 256M;

Nesse exemplo estou habilitado a extensão automática para o datafile (autoextend on) e estou informando de quantos em quantos megas eu quero que isso aconteça (next 256M).

Para habilitar para todos os datafiles:

spool runts.sql

select
'alter database datafile '||
file_name||
' '||
' autoextend on;'
from
dba_data_files;

@runts

Fonte:
http://oraclemais.blogspot.com.br/2010/06/oracle-autoextend-on.html

[Oracle] - FKs apontando para as PKs e UKs de uma tabela

As vezes acontece o erro abaixo quando tentamos truncar ou deletar todas as informações de uma tabela. Pare resolver é necessário identificar quais tabelas apontam para a tabela que eu quero truncar e precisamos desabilitar essas FKs.

Erro Oracle:
ORA-02266: unique/primary keys in table referenced by enabled foreign keys

1 - Identificando as FKs:

SELECT owner,
table_name,
constraint_name
FROM all_constraints ci
WHERE ci.constraint_type = 'R'
AND (ci.r_owner , ci.r_constraint_name) IN
(SELECT owner,
constraint_name
FROM all_constraints c
WHERE owner = '&dono'
AND table_name = '&tabela'
AND constraint_type IN ('P','U')
)

2 - Desabilite as constraints retornadas:

ALTER TABLE owner.tabela DISABLE CONSTRAINT nome_constraint;

3 - Execute o truncate das tabelas filhas e pai:

TRUNCATE TABLE owner.tabela_filha;
TRUNCATE TABLE owner.tabela_pai;


4 - Habilite as constraints retornadas:

ALTER TABLE owner.tabela ENABLE CONSTRAINT nome_constraint;

Fonte:
http://oraclemais.blogspot.com.br/2010/11/fks-apontando-para-as-pks-e-uks-de-uma.html

[Oracle] - Verificando o andamento do Job do datapump(expdp/impdp)

Para saber o andamento de um job do datapump faça o seguinte select:

SELECT job_name "Nome",
owner_name "Dono" ,
workers ,
job_mode "Modo" ,
dp.state "Status" ,
ROUND((sofar*100)/totalwork,2) "% Completado"
FROM gv$session_longops sl, gv$datapump_job dp
WHERE sl.opname = dp.job_name
AND sofar != totalwork

Fonte:
http://oraclemais.blogspot.com.br/2009/07/datapump.html

[Oracle] - Job para gerar estatísticas para um schema

No Oracle nós temos o otimizador baseado em regra, que é o mais antigo e hoje na versão 10g nem é mais suportado, eo o basedo em custo. Esse último necessita de estatísticas geradas nos objetos, pois é baseado nelas que ele gera os planos de execução e quanto mais atualizadas elas estiverem teoricamente melhor serão os planos de execução gerados.

O script abaixo cria um job usando a dbms_job que gera estatíticas para um schema todos os dias as 3 da manhã:

O script:

declare
   l_job number;
begin
   dbms_job.submit(
      l_job,
      'dbms_stats.gather_schema_stats( ''SCOTT'' );',
      trunc(sysdate)+1+3/24,
      'trunc(sysdate)+1+3/24' );
end;
/

Explicando o start time e o interval:
trunc(sysdate)
pega o dia atual a meia noite (00:00)
trunc(sysdate)+1
Adiciona um dia quer dizer amanhã meia noite
trunc(sysdate)+1+3/24
Adiciona 3 horas (3/24) o que quer dizer que o job vai rodar pela primeira vez amanhã as 03:00 e nos dias subsequentes nesse mesmo horário.

Fonte:
http://oraclemais.blogspot.com.br/2006/07/job-para-gerar-estatsticas-para-um.html

[PostgreSQL] - Consultando e eliminando sessões ativas

Bom pessoal vou mostrar como listar/matar as sessões ativas no PostgreSQL . O sql a seguir lista todas as sessões ativas.
   
select datname,
       procpid,
       usename,
       application_name,
       client_addr,
       client_hostname,
       backend_start
  from pg_stat_activity

Obs: A coluna procid foi renomeada para pid a partir da versão 9.2 do PostgreSQL

Com a lista de usuário em mãos, podemos optar por "matar" a sessão de algum usuário ativo, para isto basta executar o comando abaixo, substituindo o "procpid' pelo valor retornado da consulta anterior.
   
select pg_terminate_backend(procpid);

E para eliminar todas as conexões ativas, menos a conexão atual.
   
SELECT pg_terminate_backend(procpid)
   FROM pg_stat_activity
  WHERE procpid <> pg_backend_pid();

Fonte:
http://fabriciodev.blogspot.com.br/2012/03/consultando-e-eliminando-sessoes-ativas_20.html

[LINUX] - Expandindo o volume de uma partição no Grupo do LVM

No exemplo desse post, o servidor foi instalado com um disco de 15gb, porém o disco foi expandido para 60gb.  O disco utilizado é o ‘/dev/xvda’.  É possível que adicionando o disco a operação seja semelhante. 

Crie a partição disponível

# cfdisk /dev/xvda