Recebi um email de um leitor solicitando uma solução para que fosse desenvolvida uma função semelhante ao SUM, já nativo do banco de dados Oracle, só que fizesse multiplicação e não soma, como o SUM faz atualmente!

Por exemplo:

Tabela: FATORIAL
Campo: VALOR

Valor
5
6
3
2
3

Portanto, se usarmos o SUM, teriamos um resultado assim: 5 + 6 + 3 + 2 + 3 = 19
O pretendido é: 5 * 6 * 3 * 2 * 3 = 540

A sugestão que dei foi: Criar uma função própria que faça a multiplicação dos valores. A implementação/testes ficou assim:


SQL> --Cria tabela
SQL> create table fatorial(campo1 number, valor number);
Tabela criada.
SQL> --Insere valores
SQL> insert into fatorial values (1,2);
1 linha criada.
SQL> insert into fatorial values (1,3);
1 linha criada.
SQL> insert into fatorial values (2,4);
1 linha criada.
SQL> insert into fatorial values (2,4);
1 linha criada.
SQL>


Em seguida criamos a seguinte function:


SQL> create or replace function mult_vals(p_filtro number) return number is
2 v_retorno number;
3 begin
4 v_retorno := 0;
5 for i in (select valor from fatorial where campo1 = p_filtro)
6 loop
7 if (v_retorno = 0) then
8 v_retorno := 1;
9 end if;
10 v_retorno := v_retorno*i.valor;
11 end loop;
12 return v_retorno;
13 end;
14 /
FunþÒo criada.
SQL>


E depois é só testar:


SQL> select campo1, mult_vals(campo1)
2 from fatorial
3 group by campo1;
CAMPO1 MULT_VALS(CAMPO1)
---------- -----------------
1 6
2 16
SQL>


Funcionou como uma luva não?

É isso, o que não tem nativo a gente faz!
Neste caso fiz algo bem específico, só pra atender a necessidade que nosso leitor precisava, mas podemos pensar em algo mais genérico, se necessário! Usando SQL Dinâmico, passando nome do campo a ser multiplicado e nome da tabela! Fica a sugestão!

Agradecendo ao nosso leitor Rodrigo Vieira pela solicitação!!

Grande abraço, espero que gostem.

Com a contribuição do nosso amigo e leitor Robson Cristovão, está aí um guia básico de SQL que pode ser bastante útil para quem está começando no mundo SQL e tem algumas dúvidas quanto ao uso e sitaxe de alguns comandos SQL! Fica a dica!

AND | OR:
SELECT nome_coluna(s)
FROM nome_tabela
WHERE condiçao
AND | OR condiçao


ALTER TABLE (add coluna):
ALTER TABLE nome_tabela
ADD nome_coluna datatype


ALTER TABLE (drop column):
ALTER TABLE nome_tabela
DROP COLUMN nome_coluna


AS (alias for column):
SELECT nome_coluna AS coluna_apelido
FROM nome_tabela


AS (alias for table):
SELECT nome_coluna
FROM nome_tabela AS tabela_apelido


BETWEEN:
SELECT nome_coluna(s)
FROM nome_tabela
WHERE nome_coluna
BETWEEN valor1 AND valor2


CREATE (database):
CREATE DATABASE nome_base_de_dados


CREATE (index):
CREATE INDEX nome_indice
ON nome_tabela (nome_coluna)


CREATE (table):
CREATE TABLE nome_tabela(
nome_coluna1 tipo_dado,
nome_coluna2 tipo_dado,...)


CREATE (unique index):
CREATE UNIQUE INDEX nome_indice
ON nome_tabela (nome_coluna)


CREATE (view):
CREATE VIEW nome_da_view AS
SELECT nome_coluna(s)
FROM nome_tabela
WHERE condiçao


DELETE:
DELETE FROM nome_tabela
OU
DELETE FROM nome_tabela
WHERE condiçao


DROP (database):
DROP DATABASE nome_base_de_dados


DROP (index):
DROP INDEX nome_tabela.nome_indice


DROP (table):
DROP TABLE nome_tabela


GROUP BY:
SELECT nome_coluna1,SUM(nome_coluna2)
FROM nome_tabela
GROUP BY nome_coluna1


HAVING:
SELECT nome_coluna1,SUM(nome_coluna2)
FROM nome_tabela
GROUP BY nome_coluna1
HAVING SUM(nome_coluna2) valor_da_condiçao


IN:
SELECT nome_coluna(s)
FROM nome_tabela
WHERE nome_coluna
IN (valor1,valor2,..)


INSERT:
INSERT INTO nome_tabela
VALUES (valor1, valor2,....)
OU
INSERT INTO nome_tabela
(nome_coluna1, nome_coluna2,...)
VALUES (valor1, valor2,....)


LIKE:
SELECT nome_coluna(s)
FROM nome_tabela
WHERE nome_coluna
LIKE padrao


ORDER BY:
SELECT nome_coluna(s)
FROM nome_tabela
ORDER BY nome_coluna [ASC | DESC


SELECT:
SELECT nome_coluna(s)
FROM nome_tabela


SELECT (all):
SELECT * FROM nome_tabela


SELECT (distinct):
SELECT DISTINCT nome_coluna(s)
FROM nome_tabela


SELECT (into - usado para criar cópias auxiliares das tabelas):
SELECT * INTO new_nome_tabela
FROM original_nome_tabela
OU
SELECT nome_coluna(s)
INTO new_nome_tabela
FROM original_nome_tabela


TRUNCATE:
TRUNCATE TABLE nome_tabela


UPDATE:
UPDATE nome_tabela
SET nome_coluna=novo_valor
[, nome_coluna=novo_valor]
WHERE nome_coluna = algum_valor


WHERE:
SELECT nome_coluna(s)
FROM nome_tabela
WHERE condiçao


Espero que gostem.

Atc.
Gerson Júnior
gerson.vasconcelos@gmail.com

A dica de hoje é a respeito do seguinte…

Muitas vezes temos a necessidade de fazer algumas alterações nas nossas tabelas, nosso modelo, etc. E aí precisamos levantar quais tabelas recerenciam uma determinada tabela ou coluna, quais as filhas dessas colunas, quais as foreign key que fazem referência a elas e etc.

Aí, podemos usar o seguinte select:


select distinct c.table_name
from dba_constraints c,
dba_cons_columns cc
where c.constraint_type = 'R'
and cc.owner = c.owner
and cc.constraint_name = c.r_constraint_name
and cc.owner = &SCHEMA
and cc.table_name = &TABELA
and cc.column_name = &COLUNA


Claro que temos que mudar os parâmetros &SCHEMA, &TABELA e &COLUNA, para recuperar as tabelas que são filhas da tabela que você deseja.

Exemplo fica melhor não? Vamos lá:

Eu preciso descobrir quais as tabelas que fazem referência a alguma coluna da tabela SOURCE, para tal fazemos o seguinte select:


SQL> select DISTINCT C.TABLE_NAME
2 from dba_constraints c,
3 dba_cons_columns cc
4 where c.constraint_type = 'R'
5 and cc.owner = c.owner
6 and cc.constraint_name = c.r_constraint_name
7 and cc.owner = 'ORABUGIT'
8 and cc.table_name = 'SOURCES'
9 /
TABLE_NAME
------------------------------
PEOPLE_EQUIPS


Como podemos ver, obtemos como resposta a tabela PEOPLE_EQUIPS, portanto podemos ver que nesta tabela tem alguma coluna que referencia através de foreign key uma coluna da tabela SOURCE.

Espero que a dica seja útil!!

Abraços.

Atc.
Gerson Júnior
gerson.vasconcelos@gmail.com

Hoje vai mais uma dica de SQL e PL/SQL.

Até o dia de hoje, eu nunca tinha necessitado usar expoente no SQL / PL/SQL, nunca tinha pego nenhum problema em desenvolvimento que precisasse ser usado potência, expoente e tal.

Porém, hoje uma amiga desenvolvedora, Leilah, precisou dessa funcionalidade e aí discutimos um pouco sobre o assunto. Descobri portanto, que no Oracle, não precisamos fazer muita conta e nem usar sintaxes esquisitas para usar potência e elevar um número a uma determinada potência, basta usarmos a função POWER, isso mesmo, funciona assim:

Exemplo SQL:

SQL> select power(2,3) from dual;
POWER(2,3)
----------
8

Neste exemplo, temos 2 elevado a 3, que nos dá 8 como resultado…

Exemplo PL/SQL:

SQL> declare
2 v_num number;
3 begin
4 v_num := power(2,3);
5 dbms_output.put_line('O numero 2 elevado a 3 é: '||to_char(v_num));
6 end;
7 /
O numero 2 elevado a 3 é: 8
Procedimento PL/SQL concluÝdo com sucesso.


Pronto pessoal, fica aí a dica de utilização de potência em PL/SQL.

Espero que gostem.

Grande abraço.

Atc.
Gerson Júnior
gerson.vasconcelos@gmail.com

Recebi um email do amigo Vitor Ugo sobre uma solicitação que ele havia recebido para criação de um Job.

Até aí moleza, como podemos ver no post: Job no Oracle criar um Job é fácil! Só que este Job tem uma particularidade, ele deve rodar apenas no primeiro sábado de cada mês.

Com isso, fiz a dica para Vitor, dele colocar o job para executar todo dia, e antes de chamar a procedure do job fazer um teste e identificar se era o primeiro sábado, se sim, beleza roda a procedure, senão, não faz nada! Funcionaria, porém não é uma solução das mais bonitas, porque mesmo sem fazer nada, o job executaria todos os dias.

Foi então que o Vitor desenvolveu um select, que recupera o primeiro sábado do mês seguinte, e resolveu todos os problemas.

Segue o select desenvolvido por Vitor:


select LEAST(NEXT_DAY(ADD_MONTHS(trunc(sysdate,'MM')+(8/24),1)-1,7),
next_day(ADD_MONTHS(trunc(sysdate,'MM')+(8/24),1),7)) from dual;


Neste select o “7″ indica que é um sábado, caso desejem outro dia da semana, basta que vocês alterem esse número para o dia desejado!

É isso, fica aí a dica. Espero que gostem

Abraço a todos.

Atc.
Gerson Júnior
gerson.vasconcelos@gmail.com

Estamos aqui novamente para compartilhar mais uma experiência.

Dessa vez com algo bastante básico para quem quer se especializar em performance de aplicações, que é o meu caso!!

Em alguns momentos na nossa vida de DBA nos deparamos com processos que são um tanto quanto complexos de serem analisados, por exemplo: Uma procedure que demora muito ou uma query que demora demais para retornar ou um procedimento inteiro que tem todas as querys otimizadas mas demora muito entre outras coisas. Para que possamos analisar estes tipos de problemas, temos um grande aliado que é o SQL_TRACE, ele vai gerar uma espécie de “relatório” com todas as query´s envolvidas no processamento, e nos mostrar o que cada query fez, o plano de execução de cada uma, quanto tempo demorou para rodar, quanto de CPU consumiu, quantas vezes foi executada, isso nos dá uma visão exata do que está ocorrendo, podendo ser até um erro de lógica na aplicação, onde por exemplo, devido a um erro uma determinada query é executada milhares de vezes sem necessidade.

Hoje vou mostrar como fazemos para gerar um trace de uma determinada operação no banco e como formatar este trace de forma que possamos ler e entender o passo a passo da execução. Vamos lá!

O primeiro passo é alterar a sessão que o processo vai rodar para que o trace seja gerado, isso pode ser feito com o comando:

ALTER SESSION SET SQL_TRACE=TRUE;

Após este commando, podemos executar a nossa rotina lenta, que um arquivo será gerado com o que esta rotina fez.

Begin
Nossa_Rotina_Lenta(1,4,4);
End;

Após a conclusão do processamento, devemos ir até o local onde foi gerado o arquivo, no meu caso, o arquivo é gerado no caminho: {ORACLE_BASE}\admin\negraod\udump

Se você tentar abrir o arquivo gerado, possivelmente não vai conseguir entender nada! Para que nosso arquivo fique legível, vamos usar um utilitário chamado TKPROF. Esse utilitário tem como objetivo interpretar o trace e deixar ele num formato legível.

O uso do TKPROF é da seguinte forma: tkprof trace.trc arquivo_saida.txt explain=usuário/senha@banco

Depois deste comando executado, no seu arquivo de saída, terá um conteúdo parecido com este:

********************************************************************************
count = Numero de vezes que o procedimento foi executado
cpu = Tempo em segundos executando pelo CPU
elapsed = Tem em segundos para execução do procedimento
disk = Numero de leituras físicas no disco
rows = Numero de linhas processadas pelo comando
********************************************************************************

SELECT COUNT(*)
FROM dual

call count cpu elapsed disk query current rows
——- —– —– ——- ——- ——- ——- ——-
Parse 1 0.02 0.02 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 0.00 0.00 0 1 4 1
——- —– —– ——- ——- ——- ——- ——-
total 4 0.02 0.02 0 1 4 1

Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 121

Rows Row Source Operation
——- —————————————————
1 SORT AGGREGATE
1 TABLE ACCESS FULL DUAL

Neste exemplo, conseguimos ler e ver o que aconteceu com a query, além do plano de execução que ela utilizou para executar.

Depois disso é analisar as query´s mais complexas e atacar na mudança delas, em muitos casos é necessário a mudança da lógica da rotina, para que se possa ganhar alguma performance!

É isso pessoal. Espero que ajude vocês!

Atc.
Gerson Júnior
gerson.vasconcelos@gmail.com

Bom, hoje tivemos mais um desafio bem interessante.

Recebemos um dump de um determinado cliente, o arquivo de dump (X.dmp) veio com 260Gb em um único arquivo. Infelizmente, na máquina Linux onde a base está instalada não tinha nenhum disco com esta quantidade de espaço livre. E agora pra importar esse dump??

Vasculhamos nossos servidores e achamos um servidor com mais de 260Gb livre, dando sopa! Que beleza, problema resolvido!

Idéia 1: Descompactamos os 260Gb neste servidor e a partir dele fazemos o import na máquina destino, tudo certo! NÃO! Este servidor roda Oracle 10G e o servidor de destino roda Oracle 9i, não funciona! Que falta de sorte!

Idéia 2: Descompactamos neste servidor e através da rede, criamos um mapeamento da máquina onde será importado, para esta máquina que tem espaço sobrando e tudo certo! Ok? NÃO de novo. O servidor que tem esse espaço é um Windows 2003 Server, e a máquina onde a base está rodando e o dump teria que ser importada, estava rodando Linux… Red Hat Enterprise.

Mas… porque não? Será que não tem como fazer? Pesquisando na internet achei alguns sites que explicavam como fazer e aí decidi testar. E, para alegrar ainda mais minha sexta-feira, funcionou beleza! Como se fosse uma pasta na máquina Linux.

Segue o passo a passo:


Inicialmente deve-se verificar os compartilhamentos disponíveis na máquina destino
[oracle@oracle9i oracle]$ smbclient -L 192.168.0.13 -U oracle
Password:
Sharename Type Comment
--------- ---- -------
IPC$ IPC IPC remoto
D$ Disk Recurso compartilhado padrão
RV Disk
SQLLDR Disk
ADMIN$ Disk Administração remota
C$ Disk Recurso compartilhado padrão

Depois disso já podemos listar o conteúdo da pasta, que já será exibido o conteúdo do mapeamento em questão
[root@oracle9i root]# ls /mnt/Dump_Carref
IN


É isso!

Espero que seja útil também pra vocês!

Grande abraço.

Atc.
Gerson Júnior
gerson.vasconcelos@gmail.com

Creio que muita gente está pensando e vivendo um grande dilema: Migro ou não para o Windows 7.

Comprei uma máquina nova, um Dell Vostro 1320, como todas as máquinas recentes eu tinha direito ao upgrade gratuito do Vista para o Windows 7, e claro eu decidi arriscar instalar o 7 pra ver como sairia no ambiente de trabalho, enfim no dia a dia de um DBA.

Meio receioso… com o CD do XP Professional do lado, para que em caso de problemas, não perdesse tempo, iniciei a instalação.

Primeira coisa: Particionar o HD, claro… C:\ e D:\, arquivos todos no D:\ e S.O no C:\ em caso de problemas… Formata apenas o C:\, instala o S.O novo e tá tudo certo!

Para este passo, evitando quebrar cabeça, pesquisei alguém que já tivesse feito algo e achei um vídeo no Youtube que explicava direitinho como fazer. O vídeo é Como Formatar um Computador e instalar o Windows 7. Claro que eu já tinha uma noção boa, mas usando Windows XP… o vídeo serve só pra conferir se não tem nenhuma particularidade, e não tem!

Pronto… Windows 7 Ultimate instalado! Rodando 100%

Agora vem o desafio, instalar o Oracle!

Pesquisei em alguns sites, e confirmei que existe uma versão do Oracle para Windows Vista e que funciona no Windows 7. Como todo e qualquer download de produtos Oracle, fui até o OTN (http://otn.oracle.com) e dei uma pesquisada nas versões disponíveis do Database, e encontrei a tal versão para Vista, que pode ser encontrada no link: Oracle 10g para Windows Vista e 2k8, depois do download, fiz a instalação! Ele deu um erro dizendo que o S.O não era homologado para aquela versão do Oracle. Solução: Marcar o checkbox dizendo que tá sabendo, mas quer instalar assim mesmo! Pronto. Instalado, Oracle no ar, rodando, sem problema algum! Já dei shutdown/startup pra ver se ia subir numa boa, e até então tudo certo!

Depois disso vem as nossas queridas ferramentas! Tão importantes no nosso dia a dia!

Até então estão instaladas e funcionando normalmente:

- PL/SQL Developer (FrontEnd Oracle)
- Toad (FrontEnd Oracle)
- UltraEdit (Editor poderoso de Texto)
- UltraVNC (Irmão do VNC fee e mais poderodo)
- One Studio (Ferramenta de controle de solicitações)
- Putty (Ferramenta de conexões com ambientes Unix)

Tudo isso funcionando normalmente, como se fosse o bom e velho XP, só que muito mais rápido e muito mais bonito!

As demais atividades que precisamos fazer como DBA, podemos conectar via Terminal Server e fazer sem problemas, como sempre fizemos! No mais, está tudo certo! Rodando, funcionando e aprovado!

Estou agora desfrutando da novidade, como diria Jessier Quirino: “Eu ando é na frente, feito bengala de cego!”

Abraço a todos.

Atc.
Gerson Júnior
gerson.vasconcelos@gmail.com

Bom, atendendo à dica do amigo Alessandro Varela (http://blogdovarela.com.br) hoje falarei sobre: Como definir corretamente a periodicidade da execução dos seus Job’s! Complica não? É nada!! Vamos lá!

Espero que todos tenham lido o post que fiz falando sobre Job’s, caso não tenha lido, ainda dá tempo, basta ler o post Jobs no Oracle.

Bom, quando fazemos a criação de um Job, é porque temos a necessidade que uma determinada tarefa seja executada de tempos em tempos, e para isso geralmente precisamos definir um intervalo para que o Job seja executado novamente. Por exemplo: Quero que meu Job rode a cada hora, quero que meu Job rode todo dia de 23:00, quero que meu job rode a cada 5 minutos, e assim por diante. Só que no momento de fazer esta parametrização é quando começa a confusão, pois, as pessoas esquecem de que o Job vai rodar sozinho e ele é quem tem que definir a próxma execução! Para simplificar isso, vamos lá!

Todo mundo lembra no post anterior que eu falei que para criar um Job usamos a package DBMS_JOB e a procedure DBMS_JOB.SUBMIT(...), certo? Pois é, nesta procedure, um dos parâmetros que é passado é um tal de INTERVAL, ou seja, o intervalo entre cada execução do seu Job. É aqui que mora o X (xis) da questão! É neste parametro que vamos informar de quanto em quando tempo nosso Job vai rodar.

O que tem que ser considerado aqui, é que o Job será executado automaticamente (essa é a razão do seu existir) e é justamente por isso que rola a confusão, quando este parâmetro for usado já não estaremos mais na data “agora”, estaremos na data de execução do Job, sei lá, 23:00! E aí o banco vai usar este parâmetro INTERVAL para setar o campo NEXT_DATE, que é a próxima data em que o Job será executado, ou seja você tem que levar em consideração que o banco sempre vai usar sysdate para calcular este valor.

Como é de rotina, vamos para os exemplos que tudo vai ficar mais claro.
Exemplos mais comuns:

Job para rodar de hora em hora:
Interval -> ’sysdate + 1/24′
Ou seja, se este Job rodar dia 25/10/2009 às 14:00, quando for somada 1 hora, teremos 15:00 como NEXT_DATE.

Job para rodar a cada 5 minutos.
Interval -> ’sysdate + 5/1440′
Ou seja, se este Job rodar dia 25/10/2009 às 14:00, quando for somado 5 minutos (1/1440), teremos 14:05 como NEXT_DATE.

Job para rodar uma vez por mês:
Interval -> ‘add_months(sysdate, 1)’
Ou seja, se executar dia 25/10/2009, aplicando este valor acima, teriamos 25/11/2009 como NEXT_DATE.

Esse foi um dos casos mais estranhos, pedido através do blog pra mim…
Job para rodar em um dia específico a cada ano e numa determinada hora:
‘add_months(to_date(to_char(sysdate, ”DD/MM/YYYY”)||” 05:00”, ”DD/MM/YYYY HH24:MI”), 12)’
Ou seja, se o job rodar dia 25/10/2009 as 15:00, e aplicarmos esta fórmula aí, teremos 25/10/2010 05:00 como NEXT_DATE.

Uma dica legal para você fazer esta fórmula que será o NEXT_DATE do seu Job é dar select em sysdate usando a dual. Que eu creio ser o que o banco faz na hora de rodar o Job.

Por exemplo:
Se executarmos o comando:
select sysdate, sysdate + 1/24 from dual
Vamos obter como retorno:

sysdate sysdate + 1/24
20/10/2009 15:55:35 20/10/2009 16:55:35


Isso aí nos dá a hora atual e a hora atual somado 1 hora. Assim você monta seu NEXT_DATE facilmente!

É isso pessoal, espero que tenha ficado claro e que daqui pra frente seja mais fácil montar seus Jobs para as mais diversas necesidades.

Qualquer coisa, estamos por aqui!

Atc.
Gerson Júnior
gerson.vasconcelos@gmail.com