Vamos ver o exemplo abaixo:

1) Criei uma tabela chamada t1

SQL> create table t1 (colvar varchar2(10), colnum number);

2) Vamos preencher dados de testes nessa tabela para realizar algumas queries e ver como essa conversão é perigosa em alguns casos e em outros nem tanto.

SQL> begin

2    for i in 1..1000000 loop

3      insert into t1 values (i, i);

4    end loop;

5   commit;

6* end;

/

3) Vamos coletar estatísticas dessa nova tabela para que o otimizador tenha mais informação para decidir sobre como vai resolver as queries

SQL> exec dbms_stats.gather_table_stats(user, ‘T1′, null, method_opt=>’FOR TABLE FOR ALL COLUMNS SIZE REPEAT’, cascade=>true);;

4) Criei um índice na coluna com tipo de dados varchar e também na coluna numerica, note que apenas tenho 1 ocorrência de valores para cada linha, poderia até criar uma PK nessa coluna.

SQL> create index ix1 on t1(colvar);

SQL> create index ix2 on t1(colnum);

5) Vamos primeiro checar planos de execução em cima do tipo de dados varchar;

SQL> select * from t1 where colvar=1;

Plano de Execuc?o

———————————————————-
Plan hash value: 3617692013
————————————————————————–
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
————————————————————————–
|   0 | SELECT STATEMENT  |      |     1 |    12 |   669   (6)| 00:00:09 |
|*  1 |  TABLE ACCESS FULL| T1   |     1 |    12 |   669   (6)| 00:00:09 |
————————————————————————–

Predicate Information (identified by operation id):

—————————————————

1 – filter(TO_NUMBER(“COLVAR”)=1)

Estatisticas
———————————————————-
12  recursive calls
0  db block gets
2358  consistent gets
1630  physical reads
0  redo size
410  bytes sent via SQL*Net to client
364  bytes received via SQL*Net from client
2  SQL*Net roundtrips to/from client
4  sorts (memory)
0  sorts (disk)
1  rows processed

Obs.: Note o que o omitizador do Oracle faz, filter(TO_NUMBER(“COLVAR”)=1), por isso ele não usou o índice.

6) Agora vamos ajudar o otimizador e passar o tipo de dados correto:

SQL> select * from t1 where colvar=’1′;

Plano de Execuc?o

———————————————————-

Plan hash value: 748304776

————————————————————————————
| Id  | Operation                   | Name | Rows  | Bytes | Cost (%CPU)| Time     |
————————————————————————————
|   0 | SELECT STATEMENT            |      |     1 |    12 |     1   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| T1   |     1 |    12 |     1   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | IX1  |     1 |       |     1   (0)| 00:00:01 |
————————————————————————————

Predicate Information (identified by operation id):
—————————————————

2 – access(“COLVAR”=’1′)

Estatisticas
———————————————————-
1  recursive calls
0  db block gets
5  consistent gets
3  physical reads
0  redo size
414  bytes sent via SQL*Net to client
364  bytes received via SQL*Net from client
2  SQL*Net roundtrips to/from client
0  sorts (memory)
0  sorts (disk)
1  rows processed

Obs.: Podemos notar que o Oracle agora decidiu por um plano muito mais tranquilo e fez muito menos esforço para entregar a única linha para o usuário.

7) Agora vamos fazer o mesmo comparativo com o tipo de dados numérico

SQL> select * from t1 where colnum=’1′;

Plano de Execuc?o
———————————————————-
Plan hash value: 3248492971
————————————————————————————
| Id  | Operation                   | Name | Rows  | Bytes | Cost (%CPU)| Time     |
————————————————————————————
|   0 | SELECT STATEMENT            |      |     1 |    12 |     1   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| T1   |     1 |    12 |     1   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | IX2  |     1 |       |     1   (0)| 00:00:01 |
————————————————————————————
Predicate Information (identified by operation id):

—————————————————

2 – access(“COLNUM”=1)

Estatisticas

———————————————————-

1  recursive calls
0  db block gets
5  consistent gets
2  physical reads
0  redo size
414  bytes sent via SQL*Net to client
364  bytes received via SQL*Net from client
2  SQL*Net roundtrips to/from client
0  sorts (memory)
0  sorts (disk)
1  rows processed

Quando passamos o tipo de correto para ajudar o otimizador o Oracle faz exatamente o mesmo plano:

SQL> select * from t1 where colnum=1;

Plano de Execuc?o

———————————————————-
Plan hash value: 3248492971
————————————————————————————
| Id  | Operation                   | Name | Rows  | Bytes | Cost (%CPU)| Time     |
————————————————————————————
|   0 | SELECT STATEMENT            |      |     1 |    12 |     1   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| T1   |     1 |    12 |     1   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | IX2  |     1 |       |     1   (0)| 00:00:01 |
————————————————————————————

Predicate Information (identified by operation id):
—————————————————

2 – access(“COLNUM”=1)

Estatisticas
———————————————————-
1  recursive calls
0  db block gets
5  consistent gets
0  physical reads
0  redo size
414  bytes sent via SQL*Net to client
364  bytes received via SQL*Net from client
2  SQL*Net roundtrips to/from client
0  sorts (memory)
0  sorts (disk)
1  rows processed

Fica a lição aprendida de que temos que tomar cuidado com conversão implícita de dados, de qualquer maneira, porém, se ela foi feita em uma coluna com tipo de dados numérico o otimizador do Oracle não faz nenhuma besteira. Sabem por que? Simples, em uma coluna com tipo de dados numérico eu só posso gravar number, ao passo que em colunas de dados varchar eu posso gravar number, datas e strings.

Tomem cuidado, pois uma pequena query fazendo uma coisa errada pode significar muito tempo perdido, pois o Oracle teria que sempre ler 23Mb no caso de testes acima para me fornecer a informação de apenas 1 linha.

Att,

Mufalani

Como o cliente usa aplicações web conectadas usando pool de conexões, essa situação se agravou devido ao fato de segmentos temporários alocados em uma sessão somente são desalocados quando ela se desconecta do banco de dados, então o perfil dessa aplicação era encher dezenas de gigabytes em alguns minutos. O que me chamou a atenção foi ver segmentos do tipo LOB sendo alocados constantemente (v$tempseg_usage), porém, eu estava fazendo join com a v$session e os sql_id’s estavam sendo atualizados a todo instante, e isso não me dava uma  figura exata do que realmente estava acontecendo.

Verifiquei também que algumas das queries nessas sessões estavam usando a função WM_CONCAT tinham custo bem baixo, executavam em segundos e as outras, em sua grande maioria, usavam muito pouco ORDER BY, GROUP BY ou HASH JOINS que são rotinas que exigem da área temporária do Oracle.

Vou mostrar um caso de testes em uma base logado como SYS, pode fazer conectado com um usuário que tenha privégios de create table, consulta ao dicionário de dados ou acesso as views v$sql,v$tempseg_usage,v$session e dba_objects.

1) Criação de uma tabela “t” com algumas linhas

SQL> create table t as select * from dba_objects;

Table created.

2) Verificação de quantas linhas existem na tabela “t”

SQL> select count(1) from t;

COUNT(1)
———-
93701

3) A query abaixo mostra a quantidade de espaço usada por uma sessão conectada como “SYS”, inicialmente irá mostrar nada

select
s.sid
, s.serial#
, s.sql_id
, s.username
, t.segtype
, s.program
, t.blocks
, round((t.blocks*8096)/1024/1024,2) uso_mbs
from
v$session s
, v$tempseg_usage t
, v$sql sql
where
t.session_addr = s.saddr
and t.sqladdr = s.sql_address
and t.session_num=s.serial#
and s.sql_id = t.sql_id
and s.sql_id = sql.sql_id
and s.sql_child_number=sql.child_number
and s.username =’SYS’;

no rows selected

4) Usando a função WM_CONCAT para concatenar alguns dados e mostrar na mesma linha:

SQL> set long 20000

SQL> select wm_concat(owner||’ ‘||object_type||’ ‘||object_name)
from t
where rownum < 5001;

WM_CONCAT(OWNER||”||OBJECT_TYPE||”||OBJECT_NAME)
——————————————————————————–
JOB_NAME,SYS INDEX I_DIR$INSTANCE_ACTTYP,SYS INDEX I_DIR$INSTANCE_END_TIME,SYS T
ABLE DIR$RESONATE_OPERATIONS,SYS INDEX I_DIR$RESONATE_UI,SYS INDEX I_DIR$RESONAT
E_STATUS,SYS INDEX I_DIR$RESONATE_END_TIME,SYS INDEX I_DIR$RESONATE_ALERT_NAME,S
YS TABLE DIR$ALERT_HISTORY,SYS INDEX I_DIR$ALERT_HISTORY_NAME,SYS INDEX I_DIR$AL
ERT_HISTORY_ACTION_ID,SYS INDEX I_DIR$ALERT_HISTORY_REASON_ID,SYS INDEX I_DIR$AL
ERT_HISTORY_AT,SYS TABLE DIR$REASON_STRINGS,SYS INDEX I_DIR$REASON_STRINGS_UI,SY
S TABLE DIR$DATABASE_ATTRIBUTES,SYS INDEX I_DIR$DB_ATTRIBUTES_UI,SYS TABLE DIR$V
ICTIM_POLICY,SYS TABLE DIR$NODE_ATTRIBUTES,SYS INDEX I_DIR$NODE_ATTRIBUTES_ATTR,
SYS TABLE DIR$SERVICE_ATTRIBUTES,SYS INDEX I_DIR$SERVICE_ATTRIBUTES_UI,SYS INDEX
I_DIR$SERVICE_ATTRIBUTES_ATTR,SYS TABLE CACHE_STATS_1$,SYS INDEX I_CACHE_STATS_
1,SYS SEQUENCE CACHE_STATS_SEQ_1,SYS TABLE CACHE_STATS_0$,SYS INDEX I_CACHE_STAT

5) Rodei a query novamente do passo 3 e olha o resultado:

SID    SERIAL# SQL_ID        USERNAME     SEGTYPE   PROGRAM                                      BLOCKS    USO_MBS
———- ———- ————- ———— ——— —————————————- ———- ———-
1758       3047 1xk8hsn1wacp7 SYS          LOB_INDEX sqlplus@oraclehomolog (TNS V1-V3)              2944      22,73
1758       3047 1xk8hsn1wacp7 SYS          LOB_DATA  sqlplus@oraclehomolog (TNS V1-V3)             41984     324,16

6) Vamos checar que sql_id é esse que tanto usa área temporária do Oracle

SQL> select sql_fulltext from v$sql where sql_id=’1xk8hsn1wacp7′;

SQL_FULLTEXT
——————————————————————————–
select wm_concat(owner||’ ‘||object_type||’ ‘||object_name)
from t
where rownum < 5001

Checando no Metalink eu achei a nota abaixo, que nem precisa abrir para entender o recado.

WMSYS.WM_Concat Should not be used for customer applications, it is an internal function [ID 1336219.1]

Para os que não puderam comparecer, digo que perderam uma excelente oportunidade de passar o dia com grandes nomes da Comunidade Oracle no mundo. Irei postar algumas fotos do GUOB:

Tom Kyte, autor do popular site AskTom Blog

Andrew Holdsworth, Líder do Time da Oracle Real World Database Performance

Graham Wood, renomado arquiteto em Oracle Database Performance e uma das mentes por trás do AWR e ASH

Agenda do evento

Presidente do GUOB, Eduardo Hahn fazendo a abertura do evento

Uma voz da Oracle do brasil, Vera Cook, falando para o Grupo de Usuários Oracle do Brasil

Início da palestra e início das melhores dicas de performance

Hora do networking no coffe-break oferecido aos participantes do GUOB

Mais  coffe-break e mais networking para o pessoal do evento

Meu momento fã, Tom Kyte e Mufalani

Momento fã novamente com Andrew, Mufalani e Graham

Graham vestindo a role de DBA para mostrar como uma aplicação pode complicar um banco de dados

Andrew vestindo a role do Arquiteto de sistemas, estragando as coisas para Graham

Sala cheia preenchendo suas avaliações sobre o evento, o que valia um passe livre para o próximo GUOB.

Encerramento do evento feito pelo presidente, Eduardo Hahn e início do sorteio.

Ganhador da primeira entrada para o próximo GUOB

Ganhador do segundo passe para o próximo GUOB

Ganhador do terceiro passe livre para o próximo GUOB

Espero que as pessoas que participaram tenham aproveitado tanto quanto eu aproveitei, é trabalhoso, mas depois que o evento sai do papel está sendo executado vemos o quanto é gratificante fazer parte de tudo isso.

Agradeço imensamente as pessoas que puderam compareceram e esperamos vê-los nos próximos eventos.

Qualquer dúvida ou comentário, entre em contato rodrigo@mufalani.com.br

Forte abraço,

Mufalani

No dia 05/11 vai acontecer mais um encontro promovido pelo GUOB em São Paulo onde o assunto é APEX , o APEX Tour América latina que é mais um tour de alto nível organizado pelo GUOB, o LAOUC e a Oracle. Esse tour vai passar somente pela Argentina e Uruguai além do Brasil. Então corra e não deixe de fazer sua inscrição para um evento sobre tecnologia Oracle.

O APEX (APplication EXpress) é uma tecnologia livre da Oracle, e para quem não ouviu ainda sobre o mesmo eu sugiro dar uma conferida em http://www.oracle.com/technetwork/developer-tools/apex/index.html

No Site do evento que é todo escrito em APEX, você poderá realizar a sua inscrição para o evento. Agora vem a melhor parte, o evento é gratuito, só que as vagas são limitadas, então corra faça sua inscrição que pode ser realizada pelo link que está no site do GUOB http://www.guob.com.br/ ou diretamente pelo site do evento.

Att,

@mufalani

Amigos,

Gostaria de convidá-los a participar do Guob Tech Day 2012 que será ainda maior do que o evento de 2011. Vagas são limitadas e as inscrições já estão abertas

Link para inscrições

Estarão presentes palestrantes como Tom Kyte, Graham Wood, Andrew Holdsworth, Dimitri Gielies, Craig Shallahamer, Tim Tow, Bruno Souza, Patanjali Venkatacharaya, Dana Singleterry e Francisco Munoz Alvarez.

Este ano, contaremos com a presença do evento mundialmente conhecido, Real World Performance, onde Tom Kyte, Graham Wood e Andrew Holdsworth realizam simultaneamente um grande workshop sobre performance de banco de dados e aplicações.

Reservem já suas passagens e hotéis!!!

Nos encontramos lá!!!

Abraços,

@mufalani

Na documentação oficial do 10gr2 (versão 10.1 foi onde a Oracle introduziu essa package) podemos achar mais informações

http://docs.oracle.com/cd/B19306_01/appdev.102/b14258/d_monitor.htm#sthref4019]:

A maneira mais fácil de realizar trace de um usuário foi utilizando a procedure DBMS_MONITOR.CLIENT_ID_TRACE_ENABLE que nos permite informar o valor para a coluna que quando igual ao da coluna CLIENT_IDENTIFIER da V$SESSION nos produz no diretório UDUMP os traces que eu precisava. Só esbarrei em um problema, como alguns blogs que consultei na net dizem que o client_identier é o username, errado, a coluna client_identifier assim como a coluna client_info são preenchidas através de packages DBMS_SESSION e DBMS_APPLICATION_INFO respectivamente e os valores na visão vem nulos por padrão.

Abaixo segue um exemplo de uma trigger de logon que serve para preencher a coluna client_identifier da v$session com o mesmo valor igual ao nome do usuário que estou me conectando ao banco. Isso é bom para não ter que solicitar nenhuma mudança em aplicações existentes.

CREATE OR REPLACE TRIGGER TESTE.SET_TRACE AFTER LOGON ON DATABASE

DECLARE

USUARIO VARCHAR2(30);

BEGIN

USUARIO := SYS_CONTEXT(‘USERENV’,'SESSION_USER’);

IF USUARIO IN (‘TESTE’) THEN — só faz isso para o usuário teste

DBMS_SESSION.SET_IDENTIFIER(‘TESTE’);

END IF;

EXCEPTION WHEN OTHERS THEN
NULL;
END;
/

Lembrando que podemos colocar qualquer valore string nesse campo.

No nosso caso, eu coloquei TESTE para ficar mais fácil o entendimento, espero que não confundam, no select abaixo podemos conferir todo mundo que está conectado com o usuário TESTE e que a trigger fez sua mágica.

SELECT *
FROM V$SESSION
WHERE CLIENT_IDENTIFIER=’TESTE’;

Feito isso, podemos então ligar o trace dos usuários que se conectaram no banco com a conta TESTE. Para tal, utilizamos a dbms_monitor conforme o exemplo abaixo:

BEGIN
DBMS_MONITOR.CLIENT_ID_TRACE_ENABLE(‘TESTE’, TRUE, FALSE);
END;
/

Verifique que está habilitado consultando a visão abaixo:

SELECT *
FROM DBA_ENABLED_TRACES;

Depois de coletar traces por um período que achar razoável, pode desabilitar a coleta de traces, e verificar sempre se ele está desligado. Uma vez quase enchi o disco da Oracle home de um servidor que administrava.

Desabilitando o trace:

BEGIN
DBMS_MONITOR.CLIENT_ID_TRACE_DISABLE(‘TESTE’);
END;
/

Depois de desabilitar o trace, use o trcsess para juntar os traces em um único arquivo

trcsess [output=

] [session=] [clientid=] [service=] [action=] [module=]

output=

output destination default being standard output.
session= session to be traced.
Session id is a combination of session Index & session serial number e.g. 8.13.
clientid= clientid to be traced.
service= service to be traced.
action= action to be traced.
module= module to be traced.
Space separated list of trace files with wild card ‘*’ supported.

Depois disso, use o tkprof para formatar o trace de forma que melhor queira:

Usage: tkprof tracefile outputfile [explain= ] [table= ]
[print= ] [insert= ] [sys= ] [sort= ]
table=schema.tablename Use ‘schema.tablename’ with ‘explain=’ option.
explain=user/password Connect to ORACLE and issue EXPLAIN PLAN.
print=integer List only the first ‘integer’ SQL statements.
aggregate=yes|no
insert=filename List SQL statements and data inside INSERT statements.
sys=no TKPROF does not list SQL statements run as user SYS.
record=filename Record non-recursive statements found in the trace file.
waits=yes|no Record summary for any wait events found in the trace file.
sort=option Set of zero or more of the following sort options:
prscnt number of times parse was called
prscpu cpu time parsing
prsela elapsed time parsing
prsdsk number of disk reads during parse
prsqry number of buffers for consistent read during parse
prscu number of buffers for current read during parse
prsmis number of misses in library cache during parse
execnt number of execute was called
execpu cpu time spent executing
exeela elapsed time executing
exedsk number of disk reads during execute
exeqry number of buffers for consistent read during execute
execu number of buffers for current read during execute
exerow number of rows processed during execute
exemis number of library cache misses during execute
fchcnt number of times fetch was called
fchcpu cpu time spent fetching
fchela elapsed time fetching
fchdsk number of disk reads during fetch
fchqry number of buffers for consistent read during fetch
fchcu number of buffers for current read during fetch
fchrow number of rows fetched
userid userid of user that parsed the cursor

Abraços,

@mufalani

Está chegando o Collaborate 12.

Do dia 22 até 26 de Abril de 2012 ocorrerá um grande evento para a comunidade Oracle em Las Vegas nos Estados Unidos e se você gostaria muito de estar por lá para participar do evento, mas não pode,  poderá acompanhá-lo online, assim como eu e diversas pessoas ao redor do mundo.

O Collaborate 12 é um evento organizado pelo IOUG/AOUG/Quest para a comunidade Oracle e terá muitas apresentações sobre diversos assuntos interessantes como Exadata, Cloud Computing, Virtualização, além dos casos de sucessos de migrações entre outros.

Alguns palestrantes que já passaram aqui no Guob e que estarão presentes no evento:

Kai Yu (Dell, inc)
Arup Nanda (Starwood Hotels & Resorts)
Craig Shallahamer (Orapub, inc)

Além deles diversos nomes conhecidos no mercado além de funcionários da própria Oracle serão palestrantes deste evento maravilhoso.

Se puder ir estar presente no evento, tenho certeza de que será incrível!

O custo total com a viagem é pouco alto, então, para diminuir esse custo, o pessoal da organização vai disponibilizar o evento na modalidade virtual class ao custo de US$ 99,00  (4 dias de palestras incríveis com os maiores nomes do mundo Oracle).

Para obter o desconto tem que usar o código de desconto LAOUC12.

O valor cheio do evento é US$299,00 sendo que informando o código tem US$200,00 de desconto.

Ao clicar na imagem ao lado, você será direcionado para fazer a inscrição diretamente no site do IOUG (www.ioug.org) com seu cartão de crédito através de paypal. Muito simples e prático e ainda tem a comodidade de poder acompanhar um evento dessa magnitude sem precisar sair da sua casa. Achei muito legal essa ideia a que venham outros eventos como este e que possamos cada vez mais compartilhar conhecimento, fazer amigos e networking.

Vou anexar a agenda do evento para que tenham como verificar os assuntos que serão discutidos em suas respectivas datas:

Agenda Collaborate 12 – Virtual

Eu irei postar no site do GUOB (www.guob.com.br) bastante informações sobre o evento e aqui também no meu blog.

Abraços,

@mufalani

Quando achamos que é só mais um evento com palestras sobre Oracle, nos enganamos. Os eventos do GUOB, para mim, são excelentes pois além de aprendermos sempre um pouco mais sobre tecnologia Oracle ainda podemos nos encontrar e conhecer pessoas maravilhosas. Depois de assistir a palestra de Craig Shallahamer, a palavra evangelista Oracle teve outro significado.

Sempre revemos velhos amigos, conhecemos pessoas com as quais, antes só trocávamos e-mails em listas de discussão e mais, podemos ver nossos grandes ídolos. Essas pessoas que sempre admiramos suas carreiras, seus pensamentos e posts em blogs e que o GUOB proporciona o acesso a elas. Em 2010 pudemos ver nada mais nada menos que Tom Kyte e Francisco Muñoz Alvarez e vários outros ACE’s directors, em 2011 pude conhecer pessoalmente Arup Nanda, Graham Wood, Debra Lilley, Kuassi Mensah, Kai Yu, Hans Forbrich. Ontem, abrindo muito bem o calendário de 2012 pude chegar perto de uma das mentes mais brilhantes do mundo Oracle Craig Shallahamer que nos abrilhantou mostrando um pouco de seus conhecimentos sobre performance em sua primeira palestra “UNit of work time based performance analysis” e me surpreendeu dando um show em sua segunda palestra do dia “Introduction to Oracle buffer cache internals” onde ele deu nada mais nada menos que um show, prendendo a atenção dos ouvintes e com certeza nunca vi alguém falar  com tanto entusiasmo e em poucos minutos mostrou no detalhe o que alguns demoram horas para explicar e enteder.

Essa foto aqui eu vou guardar de recordação, pena que eu esqueci de levar o meu livro para ele autografar.

    Gostaria de agradecer a presença de todos que puderam prestigiar o evento e principalmente ao Eduardo Hahn que dedica muito do seu tempo a fazer do Guob o evento da magnitude que ele é. Obrigado à todos do conselho do Guob também, e por poder fazer parte desse time maravilhoso.

Abraços e se agendem, pois 2012 será um ano cheio de eventos!!!

Atenciosamente,

Rodrigo Mufalani

– 1) ELIMINAÇÃO DO TIPO CASO ELE EXISTA

DROP TYPE TP_USUARIO CASCADE;

– 2) PRECISAMOS PARA ISSO DE UM TIPO PARA QUE POSSAMOS EXECUTAR A CONSULTA NO ORACLE

CREATE TYPE TP_USUARIO AS (
“NO_USUARIO” VARCHAR(70),
“NO_USUARIO_FONETIZADO” VARCHAR(70),
“NO_MAE” VARCHAR(70),
“NO_MAE_FONETIZADO” VARCHAR(70),
“NO_PAI” VARCHAR(70),
“NO_PAI_FONETIZADO” VARCHAR(70)
);

– 3) CRIACAO DA FUNÇÃO NO POSTGRES

CREATE OR REPLACE FUNCTION FC_CONSULTA_ORACLE(text)
RETURNS SETOF TP_USUARIO AS
$BODY$
use DBI;

# usa o modulo DBI
my $consulta = shift;

# Definicao da variavel de entrada da funcao
return unless (defined $consulta);

# Abre a conexao com o banco de dados Oracle
my $db_ora = DBI->connect(“dbi:Oracle:teste”,
“meuteste”,
“**************”) # Senha fica exposta por isso criaremos usuarios especificos
# para conexao com o Oracle
or die “Nao obtive acesso ao banco: ” . DBI->errstr;

# Variavel que recebe a consulta para execucao
my $sel = $db_ora->prepare($consulta)
or die “Nao pude preparar a consulta: ” . $db_ora->errstr;

# Execucao da query que foi passada na chamada da funcao
$sel->execute() or die “Nao pude executar a consulta: ” . $sel->errstr;

# Loop com a variavel $row para retornar as varias linhas da query
while (my $row = $sel->fetchrow_hashref)
{
return_next($row);
}

# Disconexao do Oracle
$db_ora->disconnect;

return;
$BODY$
LANGUAGE ‘plperlu’ VOLATILE
COST 100
ROWS 1000;

– 4) TORNANDO O POSTGRES O DONO DA FUNÇÃO
ALTER FUNCTION FC_CONSULTA_ORACLE(text) OWNER TO postgres;

– 5) EXEMPLO DE CONSULTA USANDO A FUNÇÃO NO ORACLE

select a.”NO_USUARIO”
, a.”NO_USUARIO_FONETIZADO”
, a.”NO_MAE”
, a.”NO_PAI”
from fc_consulta_oracle(‘select
NO_USUARIO
, NO_USUARIO_FONETIZADO
, NO_MAE
, NO_PAI
from
tm_usuario
where
rownum < 10′) a;

/*

Para essa consulta funcionar, precisa do módulo perl DBI instalado, existe na comunidade
um database link também usando o DBI/DBD, porém, ele faz sempre acesso full
por isso eu criei essa função em perl dentro do postgres para realizar esse acesso “indexado”.
Quando eu tive que colocar essa rotina em funcionamento, a tabela tinha mais de 100Gb em dados,
imaginem quão desastroso seria um fullscan a todo acesso vindo do postgres…
Se você tem mais facilidade com Java, pode usar a mesma tecnologia e escrever uma função
em Java fazendo acesso no Oracle via JDBC.

*/