Depois de muito tempo sem postar, estou eu aqui de novo para falar de mais um recurso usado no nosso Diaadia.

Desta vez o problema foi o seguinte:

Temos uma base de produção 9i que está em plena fase de migração para 11g, claro que para que esta migração aconteça, temos que ter a homologação de vários sistemas em 11g, que atualmente rodam na nossa base de produção 9i. Em uma das homologações deste sistema, o analista nos acionou informando que um processo que rodava na base 9i em 10 minutos, já estava a mais de 1 hora rodando na base 11g, sem sucesso.

Vamos as análises…

Passo 1: Identificar que comando estava causando nosso problema, para isso solicitei ao analista rodar a rotina dele habilitando um trace, para tentarmos identificar. Foi solicitado adicionar os seguintes comandos na execução:

begin
--Habilita geracao do trace.
execute immediate('alter session set tracefile_identifier=''TRACE_PROC_LENTA''');
sys.dbms_support.start_trace(true, true);
-- Call the procedure
PROCEDURE_DO_ANALISTA_LENTA;
--Finaliza geracao do trace.
sys.DBMS_SUPPORT.STOP_TRACE;
end;
/

Após concluído o processo, temos que procurar na nossa pasta UDUMP o trace que foi gerado com o identificador “_TRACE_PROC_LENTA”.

Analisando o trace…

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 791 0.02 1.25 0 3 0 0
Execute 72124 9.77 127.63 365 3759 75246 7469
Fetch 81349 109.26 2466.37 229643 14999926 0 75146
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 154264 119.05 2595.27 230008 15003688 75246 82615


Identificamos que o processo rodou em 2595.27 segundos, total!

E temos um comando único, que rodou em 2289.73 segundos. Ficou claro que este é o culpado não??


select COL1, COL2, COL3 from MINHA_TABELA

Rows Row Source Operation
------- ---------------------------------------------------
1 TABLE ACCESS BY INDEX ROWID MINHA_TABELA (cr=7 pr=0 pw=0 time=68 us cost=5 size=33 card=1)
13 INDEX RANGE SCAN MINHA_TABELA_IDX2 (cr=4 pr=0 pw=0 time=40 us cost=4 size=0 card=1)(object id 32870)


Como podemos ver, este select está sendo executado utilizando um índice, o MINHA_TABELA_IDX2. Ótimo, agora vamos comparar este plano de execução, com o plano de execução que temos em produção. Eis o plano de produção:


Rows Row Source Operation
------- ---------------------------------------------------
1 TABLE ACCESS BY INDEX ROWID MINHA_TABELA (cr=7 pr=0 pw=0 time=68 us cost=5 size=33 card=1)
13 INDEX RANGE SCAN MINHA_TABELA_PK (cr=4 pr=0 pw=0 time=40 us cost=4 size=0 card=1)


Opa…. qual a diferença? Nesta base a minha query acessa os dados pela PK, e não pelo índice! Matamos a parada!!!

Como resolver?

A base onde a homologação estava sendo feita era uma base 11g criada com uma cópia antiga de produção, que não vinha sendo coletada estatística, que estava sendo constantemente alterada pelos testes e que não estava 100%. Para coletar estatísticas novamente desta tabela, seria mais complicado e demorado, pois a tabela tem 667.000.000 de linhas, claro, o teste tem que ser agora!!!!

Lembramos então que tinhamos uma cópia fresquinha da base de produção, que tinha sido recém migrada para 11g, ou seja, estava em 11g, mas tinha as estatísticas certinhas de produção, onde a query estava rápida.

A solução encontrada foi: Exportar as estatísticas desta tabela.

Então, vamos lá…

Passo 1: Criar uma tabela de estatísticas na base origem, para receber as estatísticas atuais da tabela:


SQL> exec SYS.DBMS_STATS.CREATE_STAT_TABLE(ownname => 'DBAGABOS', stattab => 'TLISTENER_STATS');
Procedimento PL/SQL concluÝdo com sucesso.
SQL>


Passo 2: Exportar as estatísticas atuais da tabela na base de origem, para a tabela de esatísticas que você criou:


SQL> exec DBMS_STATS.EXPORT_TABLE_STATS(ownname => 'DBAGABOS', tabname => 'TLISTENER', stattab => 'TLISTENER_STATS', cascade => true);
Procedimento PL/SQL concluÝdo com sucesso.
SQL>


Passo 3: Exportar esta tabela gerada…


C:\Users\GersonJr>exp dbagabos@orcl tables=TLISTENER_STATS file=dump_stats.dmp
Export: Release 10.2.0.3.0 - Production on Seg Ago 1 19:23:58 2011
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Senha:
Conectado a: Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Production
With the Partitioning, OLAP and Data Mining options
ExportaþÒo executada no conjunto de caracteres de WE8MSWIN1252 e no conjunto de caracteres de AL16UTF16 NCHAR
Sobre exportar tabelas especificadas ... via Caminho Convencional ...
. . exportando tabela TLISTENER_STATS 113 linhas exportadas
ExportaþÒo encerrada com sucesso, sem advertÛncias.
C:\Users\GersonJr>


Passo 4: Importar a tabela de estatísticas que você exportou, no banco de destino…


C:\Users\GersonJr>imp dbagabos@orcl_destino tables=TLISTENER_STATS file=dump_stats.dmp
Import: Release 10.2.0.3.0 - Production on Seg Ago 1 19:24:58 2011
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Senha:
Conectado a: Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Production
With the Partitioning, OLAP and Data Mining options
Arquivo de exportaþÒo criado por EXPORT:V10.02.01 via caminho convencional
AdvertÛncia: os objetos foram exportados por DBAGABOS; nÒo por vocÛ
importaþÒo realizada nos conjuntos de caracteres WE8MSWIN1252 e NCHAR AL16UTF16
. importando objetos de DBAGABOS para DBAGABOS
. importando objetos de DBAGABOS para DBAGABOS
. . importando table "TLISTENER_STATS" 113 linhas importadas
ImportaþÒo encerrada com sucesso, sem advertÛncias.
C:\Users\GersonJr>


Passo 5: Importar as estatísticas para a tabela, lendo da tabela de estatísticas que você importou.

exec DBMS_STATS.IMPORT_TABLE_STATS(ownname => 'DBAGABOS', tabname => ‘TLISTENER’, stattab => ‘TLISTENER_STATS’, cascade => true, no_invalidate => true);


E agora é só você testar seu plano de execução e verificar se na base nova a query está se comportando da mesma forma que na base antiga.

Algumas considerações:
1 – O problema ocorreu na base 11g, porém para criar o post refiz os comandos na base instalada no meu PC, que é 10.2.0.3, como podem ver nos comandos acima.

2 – Estes passos não querem dizer que há uma garantia 100% da sua query ficar igual a sua base de origem, lembre-se que em performance existem inúmeros outros pontos que são verificados para o banco montar um plano de execução.

3 – A idéia deste post é mostrar este recurso de export/import de estatísticas, que é simples e rápido de fazer, e pode ajudar-nos em vários casos.

Qualquer coisa, estou à disposição para dúvidas e/ou sugestões!

Grande abraço.

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

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 vamos falar de Construção de SQL.

As vezes precisamos fazer umas coisas mais avançadas num comando SQL e aí precisamos utilizar alguns recursos mais interessantes que o Oracle nos proporciona.

Quem nunca pensou: “Ai como seria bom se tivesse um IF no select”. Tem sim!

O primeiro recurso que podemos utilizar é o DECODE, essa função é bem interessante e quebra um bocado de galhos, vamos ver um exemplo pra “clarear” as idéias.

Suponha que você tem uma tabela que contém o sexo das pessoas, mas na tabela só armazena F ou M e você quer que seja mostrado “Masculino” e “Feminino” no retorno do seu select, como fazemos isso no select? Com DECODE!

Assim:


select nome,
dt_nascimento,
decode(sexo,
'M', 'Masculino',
'F', 'Feminino',
'Indefinido') sexo
from pessoas;


Como funciona isso… o DECODE testa o valor que você passa no primeiro parâmetro e vai comparando com o que você especifica e retorna o que você deseja. Complexo não? NÃO!! Vamos explicar o nosso exemplo:

No exemplo acima é passado o campo sexo, em seguida passamos o primeiro valor de teste e o que vai retornar caso encontre este valor, que neste caso é: Se encontrar 'M' retorne 'Masculino', sempre aos pares. Ou seja, valor encontrado e logo depois o valor que vai retornar. Como podemos ver, depois vem mais um par… 'F' e 'Feminino' o que nos diz que se encontrar um 'F', traga 'Feminino' na coluna.

Tá, mas e esse último valor que tem 'Indefinido'? Ele não tem par!! Vai dar erro? Não, esse é uma espécie de ELSE do DECODE… se ele não encontrar nenhuma das alternativas passadas para retornar um valor especificado, ele retorna esse último valor. No nosso exemplo, podemos ver que caso não encontre 'M' nem 'F' no campo, ele irá retornar o valor 'Indefinido' para a coluna… agora ficou claro!

O DECODE não tem um limite mínimo nem máximo de “pares de teste e retorno”, você pode ir especificando os valores e os retornos de acordo com sua necessidade.

Bom, esse é um recurso do Oracle que pode ser bem útil para pessoas que fazem SQL, que elaboram relatórios, que vivem fazendo query entre outros casos.

Como podemos verificar, para usar o DECODE nós temos que saber os valores que estão na coluna para que possamos informar qual o retorno caso determinado valor seja encontrado, mas… e se eu quiser utilizar uma faixa de valores por exemplo? Tipo… se coluna nota estiver entre 0 e 3 retorno 'Péssimo', entre 4 e 5 retorne 'Ruim', entre 6 e 8 retorne 'Bom' e acima de 8 retorne 'Ótimo'? Não dá pra fazer isso com DECODE né? Mas, tenha calma… no próximo post falaremos sobre uma outra função do Oracle que é uma espécie de DECODE avançado, que permite esse tipo de teste e muito mais.

Espero que gostem e que seja útil. Até a próxima.

Não exitem em comentar e/ou mandar e-mails.

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

Vamos nós novamente.
A pedido do amigo Marcos Castro dessa vez estaremos falando sobre SQL Dinâmicos, um recurso muito interessante no PL/SQL que em diversas vezes não é utilizado por nossos excelentíssimos desenvolvedores, fazendo com que nossos códigos sejam bem maiores, bem mais complexos e bem mais chatos de dar manutenção. Mas… o lado B dessa história é: Se você complicar muito no uso de SQL Dinâmico, não tenha dúvida de que seu código vai ficar muito complexo e todo mundo que for dar manutenção vai te xingar um bocado! Rsrs.

Vamos lá, ao exemplo prático e simples, que é o que interessa.

Suponha que você tem uma função para ser feita, que deve retornar o nome de uma determinada pessoa… essa pesquisa pode ser pelo seu RG, CPF ou Habilitação. Como podemos fazer isso?

Exemplo 1 (sem SQL Dinâmico):

create or replace function pesquisa_pessoa(pcodigo number, pfiltro varchar2) return varchar2 is
v_nome_pessoa pessoas.nome%type;
begin
if(pfiltro = ‘RG’) then
select nome
into v_nome_pessoa
from pessoas
where rg = pcodigo;
elsif(pfiltro = ‘CPF’) then
select nome
into v_nome_pessoa
from pessoas
where cpf = pcodigo;
elsif(pfiltro = ‘CNH’) then
select nome
into v_nome_pessoa
from pessoas
where cnh = pcodigo;
end if;

return v_nome_pessoa;
end;

Notemos que o SQL é o mesmo sempre (select nome into v_nome_pessoa from pessoas where … = pcodigo ), o que muda é apenas o nome do campo que será utilizado para filtrar a pessoa, portanto, podemos utilizar o recurso de SQL Dinâmico para otimizar este código, e como ele ficaria? Assim:

create or replace function pesquisa_pessoa(pcodigo number, pfiltro varchar2) return varchar2 is
v_nome_pessoa pessoas.nome%type;
v_where varchar2(50);
begin
if(pfiltro = ‘RG’) then
v_where := ‘rg’;
elsif(pfiltro = ‘CPF’) then
v_where := ‘cpf’;
elsif(pfiltro = ‘CNH’) then
v_where := ‘cnh’;
end if;

dbms_output.put_line(‘select nome into v_nome_pessoa from pessoas where ‘||v_where||’ = ‘||pcodigo||’;');

execute immediate ‘select nome from pessoas where ‘||v_where||’ = ‘||pcodigo
into v_nome_pessoa;

return v_nome_pessoa;
end;

Bem mais simples, e não precisamos ficar repetindo o mesmo comando várias vezes.

Bom, isso é só um exemplo bem simples, mas… o Execute Immediate pode ser usado de diversas outras maneiras.

Achei um site bem interessante, que mostra as diversas usabilidades deste recurso com exemplos que podem ser utilizados para um melhor entendimento. O site é o DBA Support.

É isso aí, espero que este recurso seja útil e bem utilizado nas suas aplicações.

Atc.

Gerson Júnior

(gerson.vasconcelos@gmail.com)

Vamos com mais uma dica interessante sobre Oracle.
Vamos analisar desta vez, os comandos UNION e UNION ALL. Estes comandos servem para que possamos unir mais de uma query (select) em um mesmo comando, trazendo os resultados de ambas as query’s. Que? Entendeu nada!? Vamos lá:

Existe no Oracle a possibilidade de unirmos mais de um comando select de forma que possamos obter o resultados de todos eles unidos (claro!) em um único resultado, como se fosse um comando só, como assim?

Suponha que você possui uma tabela de clientes e uma tabela de funcionários, e você quer trazer todos os códigos e nomes de clientes e funcionários para exibir em um relatório? Como fazer isso? Assim:


Select codcli,
nom_cli,
'C' tipo
from clientes
union
Select cod_func,
nom_func,
'F'
from funcionarios;


Se vocês executarem este comando, teremos todos os clientes e todos os funcionários listados em um mesmo resultado, mas… temos algumas coisas a considerar.

1 – Vocês devem ter notado que os nomes das colunas das tabelas são diferentes, quando eu rodar que nome minha coluna vai ter? O nome das colunas da primeira query da lista de comandos, a primeira query vai mandar em tudo e as colunas do resultado vão receber o nome das colunas da primeira query.

2 – Quando usamos o comando UNION, temos obrigatóriamente que ter a mesma quantidade de colunas e o mesmo tipo de dados das colunas em todas as query’s. Como assim? Suponha que na tabela clientes a coluna cod_cli tenha tipo de dados number e na tabela funcionarios a coluna cod_func tenha tipo de dados varchar2, não pode! Ao executar este comando o banco vai retornar um erro dizendo que as colunas das query’s não estão corretamente relacionadas. Como em ambos os comandos elas são a primeira coluna da query e estarão relacionadas, ambas tem que ter o mesmo tipo.

3 – Não podemos utilizar ORDER BY nas query’s envolvidas, apenas na última query, que ordernará os registros de todas as query’s. Neste caso acima, por exemplo, se na ultima query colocássemos um ORDER BY 1 por exemplo, ele ordenaria o resultado das duas query’s juntas, como se fosse um comando só. Se tiver códigos iguais nas duas query’s, serão trazidos juntos, pois os resultados serão considerados juntos na hora de ordenar.

Outra coisa que comentei no início foi o UNION ALL, qual a diferença dele pro UNION? O UNION utilizado sozinho faz um distinct no resultado da query, ou seja, se tiverem resultados repitidos eles não serão exibidos, será exibida apenas uma ocorrência. Suponha que por coincidência tenhamos um cliente com código 1 e nome CICERO e tenhamos um funcionario com código 1 e nome CICERO também, caso não tivéssemos essa coluna tipo para diferenciar os registros de clientes e funcionários teríamos a ocorrência 1 CICERO apenas uma vez em nosso resultado. Já usando o UNION ALL, independente da quantidade de registros repetidos que sejam retornados, todos serão exibidos.

Como usa? Assim:


Select codcli,
nom_cli,
'C' tipo
from clientes
union all
Select cod_func,
nom_func,
'F'
from funcionarios;


Qual a diferença? Só o all depois do union, depois disso o resto o Oracle resolve. Espero esse tal de Oracle!!

Momento DBA: Para o banco, por não precisar se preocupar em verificar se existem resultados iguais para que exiba apenas um deles, o UNION ALL tem bem menos custo para ser executado, portanto, se você tiver query’s em que você tem certeza que não serão retornados valores repetidos (como essa do exemplo, em que temos uma coluna tipo para diferenciar) use sempre UNION ALL, seu DBA e seu Banco de Dados agradecem!

É isso pessoal, espero que tenham entendido e que gostem.
Qualquer dúvida, sugestão, reclamação etc não deixem de entrar em contato.

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