[MS SQL Server] - Cursores - exemplo básico de utilização

Cursores são estruturas da linguagem T-SQL que permitem o processamento das linhas retornadas por uma consulta (SELECT), através de estruturas complexas de programação, como repetições ou  comandos condicionais. 

O exemplo básico de cursor consiste em uma repetição (loop) onde um mesmo conjunto de comandos é executado para todas as linhas do retorno de uma consulta. 
No exemplo abaixo, utiliza-se um cursor para executar a chamada da procedure sp_helptext para cada procedure de um banco de dados. As procedures foram obtidas através de uma consulta na viewROUTINES do Schema INFORMATION SCHEMA. 

DECLARE @schemaName VARCHAR(30)
    , @procName VARCHAR(30)
    , @fullName VARCHAR(60)

-- Cursor para percorrer os nomes dos objetos
DECLARE cursor_objects CURSOR FOR
    SELECT
          ROUTINE_SCHEMA
        , ROUTINE_NAME
    FROM
        INFORMATION_SCHEMA.ROUTINES
    WHERE
        ROUTINE_TYPE = 'PROCEDURE'

-- Abrindo Cursor para leitura
OPEN cursor_objects

-- Lendo a próxima linha
FETCH NEXT FROM cursor_objects INTO @schemaName, @procName

-- Percorrendo linhas do cursor (enquanto houverem)
WHILE @@FETCH_STATUS = 0
BEGIN

    SELECT @fullName = @schemaName + '.' + @procName

    EXEC sp_helptext @fullName

    -- Lendo a próxima linha
    FETCH NEXT FROM cursor_objects INTO @schemaName, @procName
END

-- Fechando Cursor para leitura
CLOSE cursor_objects

-- Desalocando o cursor
DEALLOCATE cursor_objects 

Algumas considerações:

• Um cursor deve estar sempre associado a uma consulta, especificada ao declarar o cursor.

• O comando FETCH popula as variáveis recebidas como parâmetro com os valores da próxima linha da consulta a ser lida. O número de variáveis passadas como parâmetro deve ser igual ao número de colunas retornadas na consulta associada ao cursor.

• A variável global @@FETCH_STATUS retorna o resultado da última operação FETCH executada por um cursor na conexão.
  O status 0 significa que o comando FETCH retornou uma linha, qualquer outro resultado significa que não houve linha retornada.

• Cursores são estruturas relativamente lentas se comparadas ao desempenho de consultas do banco. O uso descuidado dessa ferramenta pode causar sérios problemas de performance.
  

Referencia:

http://www.sqlserverdicas.com/2010/12/cursores-exemplo-basico-de-utilizacao.html

[MS SQL Server] - Inserindo o resultado de uma consulta em uma tabela já existente

No artigo anterior, verificamos como inserir os resultados de uma consulta em uma nova tabela utilizando a cláusula INTO do comando SELECT. Agora, vamos explorar como inserir o resultado de uma consulta em uma tabela já existente.

O comando INSERT possui uma sintaxe alternativa que auxilia a execução desta tarefa. Veja abaixo: 

INSERT INTO tabelaDestino

SELECT campo1, campo2, ... , campoN
FROM tabelaOrigem
WHERE condicionais

Utilizando a tabela Funcionarios do artigo anterior, criaremos 

CREATE TABLE Funcionarios
(
    idFuncionario INT IDENTITY (1,1) PRIMARY KEY
    , nome VARCHAR(100) NOT NULL
    , dataAdmissao DATETIME NOT NULL
    , dataDemissao DATETIME NULL
)

-- Inserindo dados fictícios para testes
INSERT INTO Funcionarios VALUES
    ('Evandro', '2001-07-03', NULL)
    ,('José','2002-02-09',NULL)
    ,('Ronaldo','1995-09-25','2001-05-03')
    ,('Márcia','2003-03-22','2004-06-04')
    ,('Régis','1997-09-25','2004-08-07')
    ,('Renata','2008-02-27',NULL)
    ,('Mariana','2009-01-15',NULL)

Em seguida, criaremos a tabela para armazenar os funcionários demitidos (FuncionariosDemitidos), com a mesma estrutura da tabela Funcionarios

-- Criando a tabela de Funcionários demitidos com a mesma estrutura original
CREATE TABLE FuncionariosDemitidos
(
    idFuncionario INT 
    , nome VARCHAR(100) NOT NULL
    , dataAdmissao DATETIME NOT NULL
    , dataDemissao DATETIME NULL
)

Para preencher a nova tabela, basta utilizar o comando INSERT com a sintaxe indicada:

-- Inserindo os dados dos funcionários demitidos
INSERT INTO FuncionariosDemitidos      
    SELECT *
    FROM Funcionarios
    WHERE
        dataDemissao is not null

Algumas consideraçõe sobre este procedimento:

• Ao contrário do comando SELECT com a cláusula INTO, o comando INSERT não cria a tabela tabelaDestino. Ou seja, a tabela tabelaDestino precisa obrigatoriamente existir.
• Evite utilizar o caracter curinga * para definir os campos a serem inseridos na tabelatabelaOrigem, principalmente quando esta possuir campos com auto-numeração (IDENTITY)

Para maiores informações sobre o comando INSERT, consulte no MSDN:
INSERT (T-SQL)
http://www.sqlserverdicas.com/2011/01/inserindo-o-resultado-de-uma-consulta_25.html

[MS SQL Server] - Alterando o Schema de uma tabela

O uso de schemas é uma boa prática para organizar a estrutura e as permissões de um banco de dados SQL Server.

Todos os objetos pertencentes a um Schema herdam suas permissões (desde que não existam permissões explícitas para cada objeto). Além disso, cada objeto pertence a um, e somente um, Schema.

Apesar do schema fazer parte da identificação de todo objeto, o simples renomeio de uma tavela  não possibilita associá-la a outro Schema.

Para realizar esta tarefa, deve-se utilizar a cláusula TRANSFER do comando ALTER SCHEMA.

Veja a sintaxe abaixo:

ALTER SCHEMA nome_do_schema TRANSFER outro_schema.nome_da_tabela; 

Note que o uso desta cláusula permite que a tabela nome_data_tabela seja "importada" para o Schema nome_do_schema.

No exemplo abaixo, 2 Schemas são criados (Marketing e RecursosHumanos). Em seguida, cria-se a a tabela Funcionario no Schema Marketing. Suponhamos que esta seja uma associação equivocada, e que a tabela Funcionario deva pertencer ao Schema RecursosHumanos.

-- Criando Schema para a área de Marketing
CREATE SCHEMA Marketing
GO

-- Criando Schema para a área de RecursosHumanos
CREATE SCHEMA RecursosHumanos
GO

-- Criando tabela Funcionario no Schema Marketing
CREATE TABLE Marketing.Funcionario
(
id int identity(1,1) PRIMARY KEY,
nome VARCHAR(100)
)
GO

/* Alterando o Schema da tabela Funcionario. 
(DE: Marketing PARA: RecursosHumanos) */
ALTER SCHEMA RecursosHumanos TRANSFER Marketing.Funcionario
GO

Observações:

• Tome cuidado ao alterar nomes ou schemas de objetos de um banco de dados. Tenha sempre em mente que este objeto pode ser referenciado por aplicações ou mesmo por outros objetos existente no banco de dados. Caso isso aconteça, estas referências serão inválidas.

[MS SQL Server] - Desabilitando restrições ao inserir muitos registros

O uso de restrições (CONSTRAINTS) nas tabelas de um banco de dados é extremamente recomendável para garantir a integridade dos dados armazenados.

Entretanto, quando os registros são inseridos ou alterados em tabelas que possuam contraints, o SQL Server precisará validar todas as constraints para cada cada alteração realizada, o que diminui a performance destas operações.

Em situações comuns de uso do banco de dados, esse impacto não é percebido, principalmente se o banco de dados foi implementado seguindo as boas práticas. Por outro lado, em uma carga de dados, ou em qualquer situação onde seja necessário realizar muitas inserções ou alterações de registros, essa verificação adicional pode impactar severamente na perfomance destas operações.

Para contornar esta situação, é possível desabilitar a verificação de constraints, desde que se tenha a garantia de que os dados a serem inseridos/atualizados estão em conformidade com as restrições do banco.

A cláusula NOCHECK do comando ALTER TABLE desabilita estas verificações.

Sintaxe

ALTER TABLE NomeDaTabela
       NOCHECK CONSTRAINT NomeDaConstraint

Exemplo

ALTER TABLE Cliente
       NOCHECK CONSTRAINT fk_cliente_x_empresa

ReferênciaALTER TABLE (Transact-SQL)

http://www.sqlserverdicas.com/2010/08/desabilitando-restricoes-ao-inserir.html

[MS SQL Server] - Inserindo o resultado de uma consulta em uma nova tabela

Esta é uma tarefa simples, muito utilizada para fazer backup de tabelas ou extrair dados segundo um filtro.

Se a tabela ainda não existir, pode-se utilizar a cláusula INTO do comando SELECT para inserir os resultados em uma nova tabela com as mesmas colunas definidas no retorno do comando SELECT.

Para exemplificar, criaremos uma tabela simples para simular o cadastro de funcionários de uma empresa:

CREATE TABLE Funcionarios
(
    idFuncionario INT IDENTITY (1,1) PRIMARY KEY
    , nome VARCHAR(100) NOT NULL
    , dataAdmissao DATETIME NOT NULL
    , dataDemissao DATETIME NULL
)

-- Inserindo dados fictícios para testes
INSERT INTO Funcionarios VALUES
    ('Evandro', '2001-07-03', NULL)
    ,('José','2002-02-09',NULL)
    ,('Ronaldo','1995-09-25','2001-05-03')
    ,('Márcia','2003-03-22','2004-06-04')
    ,('Régis','1997-09-25','2004-08-07')
    ,('Renata','2008-02-27',NULL)
    ,('Mariana','2009-01-15',NULL)

Veja abaixo como o comando SELECT (com a cláusula INTO) pode ser utilizado para extrair os funcionários demitidos de uma empresa (Data de demissão preenchida) e armazená-los em uma nova tabela FuncionariosDemitidos: 

-- Criando tabela com os funcionários demitidos
SELECT * 
INTO FuncionariosDemitidos 
FROM Funcionarios
WHERE 
    dataDemissao is not null 

Observe o resultado de uma consulta sobre a nova tabela FuncionariosDemitidos:

 

Observe que apenas as linhas com a coluna DataDemissao preenchida foram inseridas na nova tabela.

Além disso, o nome dos campos criados na nova tabela são idênticos aos da tabela original.

Para maiores sobre a cláusula INTO do comando SELECT, consulte no MSDN: 
INTO Clause (Transact-SQL)

Referencia:

http://www.sqlserverdicas.com/2011/01/inserindo-o-resultado-de-uma-consulta.html

[ORACLE] - Formatação de Datas em texto no Oracle

Bom pessoal, segue abaixo formatação de datas para exemplo com os links para pesquisa quando necessário:

SELECT to_char(SYSDATE, 'DD/MM/YYYY HH24:MI:SS') AS data_e_hora_inteira,
       to_char(SYSDATE, 'HH24:MI:SS') AS hora_inteira,
       to_char(SYSDATE, 'HH') AS hora_h12,
       to_char(SYSDATE, 'WW') AS SEMANA,
       to_char(SYSDATE, 'W') AS SEMANA1,
       to_char(SYSDATE, 'IW') AS SEMANA2,
       to_char(SYSDATE, 'Day', 'nls_language =''BRAZILIAN PORTUGUESE''') AS nome_dia,
       to_char(SYSDATE, 'Month', 'nls_language =''BRAZILIAN PORTUGUESE''') AS nome_mes,
       to_char(SYSDATE, 'YEAR', 'nls_language =''BRAZILIAN PORTUGUESE''') AS nome_ano,
       to_char(SYSDATE, 'DD', 'nls_date_language = PORTUGUESE') AS dia,
       to_char(SYSDATE, 'MM', 'nls_date_language = PORTUGUESE') AS mes,
       to_char(SYSDATE, 'YYYY', 'nls_date_language = PORTUGUESE') AS ano,
       to_char(SYSDATE, 'HH24') AS hora_h24,
       to_char(SYSDATE, 'MI') AS minuto,
       to_char(SYSDATE, 'SS') AS segundo,
       to_char(SYSDATE,
               ('DAY, dd "de" FMMONTH "de" YYYY'),
               'nls_date_language = PORTUGUESE') AS data_literal,
       to_char(SYSDATE,
               ('DAY, dd "," FMMONTH "," YYYY'),
               'nls_date_language = AMERICAN') AS data_literal_americana,
       to_char(SYSDATE,
               'yyyy-MON-dd, FMDAY',
               'nls_date_language = AMERICAN') data_padrao_americano,
       to_char(SYSDATE,
               'FMDAY , dd/MM/yyyy',
               'nls_date_language = PORTUGUESE') data_padrao_brasil,
       sessiontimezone AS timezone_da_sessao,
       current_date AS data_formato_timezone
FROM   dual;

Tabelas de parâmetros

Parâmetros	Descrição
YEAR	Ano (Ex: dois mil e onze, twenty eleven)
YYYY  YYY  YY  Y	Ano (Ex: 2011)  Ano (Ex: 011)  Ano (Ex: 11)  Ano (Ex: 1)
Q	Quadrimestre (1,2,3,4)
MM	Mês (Ex: 10)
MON	Abreviatura do nome do Mês (Ex: OUT)
MONTH	Nome do Mês (Ex: Outubro)
RM	Mês em números romanos (Ex: X)
WW	Semana do Ano de 1 a 53
W	Semana do mês de 1 a 5
D	Dia da semana de 1 a 7 (1 = Domingo até 7=Sábado)
DAY	Nome do dia da semana (Ex: Sabádo)
DD	Dia do Mês de 1 a 31
DDD	Dia do Ano de 1 a 366
DY	Abreviatura do dia da semana (Ex: SÁB)
HH	Hora de 1 a 12
HH12	Hora de 1 a 12
HH24	Hora de 1 a 24
MI	Minutos
SS	Segundos
SSSSS	Milésimos

Fonte:

http://ss64.com/ora/syntax-fmt.html

http://infolab.stanford.edu/~ullman/fcdb/oracle/or-time.html

[PostgreSQL] - Monitorando Locks no Banco de dados

Bom pessoal, segue abaixo consulta para monitorar os locks(Bloqueios de Tabelas e Registros) existentes no seu Banco de Dados PostgreSQL:

  SELECT bl.pid                 AS blocked_pid,
         a.usename              AS blocked_user,
         ka.current_query       AS blocking_statement,
         now() - ka.query_start AS blocking_duration,
         kl.pid                 AS blocking_pid,
         ka.usename             AS blocking_user,
         a.current_query        AS blocked_statement,
         now() - a.query_start  AS blocked_duration
  FROM  pg_catalog.pg_locks         bl
   JOIN pg_catalog.pg_stat_activity a  ON a.procpid = bl.pid
   JOIN pg_catalog.pg_locks         kl ON kl.transactionid = bl.transactionid AND kl.pid != bl.pid
   JOIN pg_catalog.pg_stat_activity ka ON ka.procpid = kl.pid
  WHERE NOT bl.granted;

For PostgreSQL >= 9.2:

  SELECT bl.pid                 AS blocked_pid,
         a.usename              AS blocked_user,
         ka.query               AS blocking_statement,
         now() - ka.query_start AS blocking_duration,
         kl.pid                 AS blocking_pid,
         ka.usename             AS blocking_user,
         a.query                AS blocked_statement,
         now() - a.query_start  AS blocked_duration
  FROM  pg_catalog.pg_locks         bl
   JOIN pg_catalog.pg_stat_activity a  ON a.pid = bl.pid
   JOIN pg_catalog.pg_locks         kl ON kl.transactionid = bl.transactionid AND kl.pid != bl.pid
   JOIN pg_catalog.pg_stat_activity ka ON ka.pid = kl.pid
  WHERE NOT bl.granted;

[MySQL] - Rotina para limpar bases de dados

Aqui está um script legal que vai apagar todos os seus bancos de dados MySQL, menos os bancos de dados mysql e information_schema.
Eu uso esse script sempre quando eu quero reconstruir meu servidor de replicação.

mysql -uroot -p  -e "show databases" | grep -v Database |
grep -v mysql| grep -v information_schema| grep -v test | 
grep -v OLD |gawk '{print "drop database " $1 ";select sleep(0.1);"}' |
mysql -uroot -ppassword

O comando vai criar a declaração de banco de dados apagar os bancos de dados, menos os bancos de dados mysql e information_schema.

A saída seria algo de tipo:

[root@home]#  mysql -uroot -p  -e "show databases" | grep -v Database | grep -v mysql| grep -v information_schema|grep -v bih002_bin_logs | grep -v test | grep -v OLD |gawk '{print "drop database " $1 ";select sleep(0.1);"}'
drop database callroom;select sleep(0.1);
drop database callroom_mgm;select sleep(0.1);
drop database dialogus;select sleep(0.1);
drop database limesurvey;select sleep(0.1);

Fonte: http://www.aodba.com/pt/blog/2015/02/19/como-apagar-todos-os-bancos-de-dados-em-mysql/

[MySQL] - Verificando tabelas InnoDB fragmentadas e reorganizando os dados

O que são tabelas fragmentadas?

Se houver inserções aleatórias em ou exclusões dos índices de uma tabela, os índices podem se tornar fragmentados.
A fragmentação significa que a ordem física das páginas de índice no disco não está próxima a ordem do índice dos registros nas páginas ou que há muitas páginas sem uso no bloco de 64 páginas que foram alocados para o índice.
Os sintomas de tabelas fragmentadas pode ser que a tabela pode ter mais espaço em disco do que o necessário ou os resultados pode retornar mais lento, com mais de disco I/O do que o necessário. Usuários INNODB precisa verificar a fragmentação muitas vezes, porque quando as marcas INNODB dados como excluído, ele nunca substitui os blocos com novos dados. Ele só os marca como inutilizável. Como resultado, o tamanho dos dados é artificialmente e recuperação de dados é retardado.

SELECT 
TABLE_SCHEMA, TABLE_NAME, CONCAT(ROUND(data_length / ( 1024 * 1024 ), 2), 'MB') DATA, 
CONCAT(ROUND(data_free  / ( 1024 * 1024 ), 2), 'MB')FREE 
              from information_schema.TABLES 
          where TABLE_SCHEMA 
       NOT IN ('information_schema','mysql') and Data_free < 0;

Agora crie uma rotina de executar o script abaixo.

 #!/bin/bash
 
MYSQL_LOGIN='-u<user name> --password=<passowrd>'
 
for db in $(echo "SHOW DATABASES;" | mysql $MYSQL_LOGIN | grep -v -e "Database" -e "information_schema")
do
        TABLES=$(echo "USE $db; SHOW TABLES;" | mysql $MYSQL_LOGIN |  grep -v Tables_in_)
        echo "Switching to database $db"
        for table in $TABLES
        do
                echo -n " * Optimizing table $table ... "
                echo "USE $db; OPTIMIZE TABLE $table" | mysql $MYSQL_LOGIN >/dev/null
                echo "done."
        done
done
 

É importante lembrar que quando de-fragmentam uma tabela, o processo irá bloquear a tabela, por isso certifique-se de que você pode fazer esse bloqueio.

Fonte: http://www.aodba.com/pt/blog/2015/02/19/verifique-se-ha-fragmentacao-em-mysql-e-corrigi-lo/

[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.

[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] - 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