Blog do David R

Olá como vão vocÊs?..espero que bem!

Lancei um novo Post em meu BLOG, quem quiser dar uma olhadinha clique no link abaixo:

http://databaseguard.blogspot.com/2009/10/parametros-nao-documentados-corruption.html

Abraço á todos!!!!

Olá pessoal como vão vocês?

Sei que estõu devendo um POST aqui, mais em breve estarei trazendo algum assunto interessante á vocês.

Aquels que quiserem dar uma passada no meu outro Blog eu postei algumas coisinhas novas por lá, segue o endereço para quem se interessar :

http://databaseguard.blogspot.com

Abraço á todos!!!

Olá pessoal, tudo bem?

Venho aqui para lhes trazer mais uma novdade em meu BLOG.

Espero que gostem.

http://databaseguard.blogspot.com/2009/09/gerando-traces-para-listener.html

Abraço á todos e obrigado. 

Olá, como estão vocês?

Venho aqui pra lhes trazer um link do meu novo Post no meu outro BLOG, aqueles que se sentirem á vontade de prestigiar, faço muito gosto.

Segue o link para apreciação: http://databaseguard.blogspot.com/2009/08/rman-bmr-block-media-recover.html

E não esqueçam de comentar, dar idéias e sugestões, serão todas muito bem vindas.

Abraço á todos!!!!

Olá pessoal.

Fiz um post sobre Rman no meu novo BLOG, se alguem tiver interesse dê uma olhadinha e deixem seus comentários.

http://databaseguard.blogspot.com/2009/08/duplicate-database-via-rman.html

Abraço á todos..Sucesso!!!!

Olá pessoal,como vão?

Bem, hoje me deparei com um assunto bem interessante enquanto lia um de meus livros que comprei a alguns anos, e uma página me chamou a atenção.

Via de regra todos nós nos preocupamos diariamente com a questão do Banco de Dados estar ou não atendendo as suas requisições, em tempos e performances aceitavéis, tanto para nós como para os demais usuários que praticam suas atividades negociais diariamente.

Ha uma maneira muito eficaz de se identificar os SQL’s ( Statement’s) mais intesivos do Banco, e que consequentemente por suas caracteristicas, poderiam e podem ser fortes candidatos a um pequeno TUNNING  básico, uma reescrita, uma mudada na clausula WHERE, ou talvez até uma sugestão de indice, enfim, podemos localizar essas pequenas pulgas, que poderiam vir a se tornar verdadeira pragas em nosso Banco de dados, neste intuito vou postar uma query aqui que mostrará como localizar e verificar de que maneira andam se comportanto as instruções em seu banco de dados.

QUERY :

Descrição: Esta query ira mostrar a vocês as 20 sessões top em termos de intesidade, levando em consideração leituras á disco por execução, a partir da Release 9i com a implementação das colunas CPU_TIME e ELAPSED_TIME, ficou melhor e mais eficaz a visualização em termos de tempos de execução.

select
sql_text,
username,
disk_reads_per_exec,
buffer_gets,
disk_reads,
parse_calls,
sorts,
executions,
rows_processed,
hit_ratio,
first_load_time,
sharable_mem,
persistent_mem,
runtime_mem,
cpu_time,
elapsed_time,
address,
hash_value
from
(select sql_text,
username,
round((a.disk_reads/decode(a.executions,0,1,a.executions)),2)disk_reads_per_exec,
a.disk_reads,
a.buffer_gets,
a.parse_calls,
a.sorts,
a.executions,
a.rows_processed,
100 - round(100*a.disk_reads/greatest(a.buffer_gets,1),2) hit_ratio,
a.first_load_time,
sharable_mem,
persistent_mem,
runtime_mem,
cpu_time,
elapsed_time,
address,
hash_value
from
v$sqlarea a,
all_users b
where
a.parsing_user_id=b.user_id
and
b.username not in ('SYS','SYSTEM')
order by 3 desc)
where rownum < 21;                  

Vale salientar que essa query por questões mencionadas acima, não podem ser utilizadas em 8i, para que possam ser utilizadas , devemos ignorar as colunas que citamos acima.

Todos poderiam perguntar o seguinte : - Ah! Isso é passado já temos o AWR que pode nos mostrar isso, e temos também o Grid Control que pode nos dar um relatório em segundos, não preciso disso, vou usar onde isso?

Veja bem, em alguns locais de trabalho , tudo que se tem é uma Workstation, o SQL*Plus instalado e no máximo lhes deixariam plugar o seu PEN DRIVE nessa estação de trabalho ( risos) , é engraçado mais é a realidade, poranto quando mais armas você tiver e menos depender de interfaces WIZARD, melhor será seu aprendizado e suas capaciadades irão muito mais além, lhe destacando e diferenciando sempre dos demais profissionais.

Obrigado á todos pela atenção, espero que apreciem e que comentem.

Abraço!

P.S.: essa dica e muitas outras são de facil localização para aqueles que gostam de Livros Técnicos, sugiro visitarem a editora Rampant, tem excelentes titulos.

Olá como estão vocês?

Bem estou aqui para entregar-lhes como prometi, o ultimo e derradeiro post sobre TKPROF, por favor aqueles que demonstraram interesse no assunto e prestigiaram meu BLOG deixando comentários e criticas ( construtivas) por gentileza visualizem este ultimo post e continuem a mandar suas opiniões, são e serão sempre muitissimo bem vindas. Um abraço a todos e acessem o link abaixo para ver mais este Post :

http://databaseguard.blogspot.com/2009/07/tkprof-utilizar-ou-nao-e-porque-parte.html

Obrigado á todos!

Olá pessoal, como vão todos?

Bem gostaria que aqueles que acompanham este BLOG também possam conhecer meu novo BLOG, essa semana postei algo que acho interessante por lá, quem quiser de uma passadinha e veja se gosta.

Segue o Link :

http://databaseguard.blogspot.com/2009/07/utilizando-o-pacote-dbmsrepair.html

Abraço a todos!!!
David

Olá pessoal, hoje resolvi falar sobre um assunto que desde que ingressei na carreira de DBA sempre foi tido como uma pratica bastante massante e porque não dizer chata, estou me referindo ao TKPROF.

Neste post vou tentar abordar conceitos e práticas de uso, bem como onde e quando devem ser empregados e qual a melhor maneira de gera-los e analisa-los.

Espero que apreciem.

TKPROF

Conceito: é uma das inumeras ferramentas que a Oracle dispõe para auxiliar no trabalho do DBA no seu dia - a - dia, muito usada para diagnosticar possiveis problemas com performancem seja de querys em particular ou até mesmo de processos fechados ( packages e procedures). Através desta ferramenta o DBA pode inclusive encontrar problemas causados por instruções SQL mau parametrizadas ou mau construidas e também analisar problemas de Wait Events.

TKPROF , dificil ou apenas mau interpretado?

Notavelmente , muitos de nós DBA’s, já devemos ter esbarrado com alguém que ache essa ferramenta muito complicada, não só pelo fato de sua saida em forma de arquivo texto , conter inumeras informações que para muitos é de nenhuma relevancia, mais que para alguns DBA’s são de suma importância. Eu mesmo no inicio de minha carreira achei que esse tal de TKPROF era uma verdadeira enrrolação, um programa que gerava inumeras linhas das quais eu não fazia idéia do que se passava.
O que ocorre na verdade é que muitos não analisam com cautela suas linhas de arquivo de saida, deixando muitas vezes passar detalhes preciosos despercebidos, como por exemplo um valor da coluna de PARSES muito alto, um resultado de FETCH muito maior que o de EXECUTE, e por ai vai. São detalhes que podem até não responder aos nossos questionamentos, mais que com certeza nos traram “clarevidência” com relação a que atitude tomar, por onde começar a olhar em nossos ambientes.

Quando devemos usa-lo? (TKPROF)

Bom, podemos avaliar que, o uso desta ferramenta deve ser feito sempre que houverem problemas relacionados a performance de processos em particular, processos esses muitas vezes apontados por usuários finais, ou até mesmo developers experientes. Na maioria das vezes o que chama atenção e nos leva a querer usar essa ferramenta, é quando visivelmente , seja pelo feeling, pela experiencia ou até mesmo por puro chute, não conseguimos identificar onde esta a ponta o iceberg. Iceberg esse que vem na forma de POOR PERFORMANCE, onde um processo em determinada semana rodava em instantes e agora passou a ser em horas, sem que tenha mudado nada em termos de Ambiente ( infra ), e a única maneira de tirarmos a “prova dos 9″, é de fato usando algo que nos dê subsidios para discutirmos seja com o Adm. de Redes, de S.O ou até mesmo o próprio reclamante que em muitos casos é o desenvolvedor do processo.

Analisando o Resultado do TKPROF.

Bem, o que deveriamos analisar primeiro em um arquivo de saido do processo de geração de arquivos de TRACE? ( os arquivos de traces são em geral armazenados nos diretórios UDUMP, BDUMP e CDUMP), vou mostrar uma pequena lista do que merece mais atenção nesse sentido :

1.) Comparar o numero de PARSES com o numero de EXECUTIONS
Neste caso um bom tunning tera um Parse apenas para “n” execuções, o que evitará que seja feito vários re-parsing, o que poderia com certeza degradar a performance.

2.) Procurar por Instruções SQL que não usam variaveis BIND (:Variavel)
É sabido hoje em dia, que quanto mais BIND variables suas instruções SQL conseguirem usar, maiores as chances de haver reaproveitamentos de querys evitando assim todo o processo de parse, execute e fetch, com isso ganhase performance e melhores resultados. Portanto uma vez detectado instruções que não usem variaveis bind , devemos trabalhar no sentido de muda-las.

3.) Identificar os processos que contém altos indices de FULLTABLE SCANS, consumo de CPU excessivo e multiplas leituras á DISCO.
Não se pode levar essas recomendações a ferro e fogo, devemos antes analisar o tipo de Base de Dados que temos, e de acordo com o tipo tolerar algumas caracteristicas e traços encontrados unica e exclusivamente por essas bases, como por exemplo as diferenciações entre um banco OLTP e um DATA WAREHOUSE.

Agora vamos entender algumas particularidades que devem ser preenchidas antes mesmo de gerarmos o nosso tão sonhado TRACE, para futura analise.

a) Verificar o Ambiente
- devemos habilitar o parametro TIMED_STATISTICS, com isso poderemos ter informações preciosas de consumo de CPU, WAITs e tempos decorridos das execuções.
- a instrução apra colocar este paramtro em funcionamento é:

ALTER SYSTEM SET TIMED_STATISTICS = TRUE;

b) Verificar o diretório destino dos arquivos de trace ( rastreamento), representados pelo parametro USER_DUMP_DEST encontrado no arquivo de inicialização (init.ora)
- estes arquivos podem ser gerados indiscriminadamente, ou até que se esgote o espaço em disco disponvel para este diretório, pois constantemente o oracle gera pequenos arquivos de trace relatando algum problema em sua Base de dados, seja de pequena ou de grande magnitude.
- vejamos como podemos identificar um exemplo do caminho onde são gerados os trace’s:

select value
from v$parameter
where name = 'user_dump_dest';

VALUE
----------------------------------------------------------------------------------------------------
E:\ORACLE\PRODUCT\10.2.0\ADMIN\\UDUMP

Testedb.System>

O Nosso próximo passo é saber como “ligar”, ou dar o start no processo de geração dos arquivos Traces.
Os tarces podem ser definidos até a nivel de sessão.

ALTER SESSION SET SQL_TRACE = TRUE;
DBMS_SESSION.SET_SQL_TRACE(TRUE);

Ainda contamos com a possibilidade d ehabilitar umtrace em uma determinada sessão do Banco de Dados, afim de monitorar um processo de maneira mais eficaz, veja :

DBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION( sid,serial#,TRUE);
Obs.:Acima o comando deve ser passado informando o SID e o SERIAL# da sessão a ser analisada.

Ao longo dos anos e dos tempos, e de acordo com as diversas releases que o Oracle já teve e tem, as nomenclaturas dos arquivos de trace foram variando, como pode ser visto abaixo :

Version :7.3.4
Naming Convention: snnn_pid.trc
Example:s000_4714.trc

Version :8.0.5
Naming Convention:ora_pid_trc
Example:ora_2345.trc

Version :8.1.7
Naming Convention: ora_pid_instance.trc
Example:ora_1373_dbtest.trc

Version :9.x
Naming Convention:instance_ora_pid.trc
Example:dbtest_ora_12345.trc

Com essas informações o DBA pode montar uma query que retornara o nome especifico do arquivo de traces gerado para uma determinada sessão ou para todas. Veja como ficaria :

column username format a10
column trace_file format a70

select b.username,c.value||'\' ||lower(d.value)||'_ora_'||
to_char(a.spid,'fm00000')||'.trc' "Trace_file"
from v$process a,v$session b, v$parameter c,v$parameter d
where a.addr = b.paddr
and c.name='user_dump_dest'
and d.name='db_name'
and b.username is not null;

Saida:

USERNAME Trace_file

DISTCUR e:\oracle\admin\cdpe\udump\cdpe_ora_02760.trc
DISTARA e:\oracle\admin\cdpe\udump\cdpe_ora_01484.trc
DISTSJR e:\oracle\admin\cdpe\udump\cdpe_ora_02476.trc
SYSTEM e:\oracle\admin\cdpe\udump\cdpe_ora_03888.trc
DIST e:\oracle\admin\cdpe\udump\cdpe_ora_02136.trc
DIST e:\oracle\admin\cdpe\udump\cdpe_ora_03752.trc
DISTBEL e:\oracle\admin\cdpe\udump\cdpe_ora_03280.trc
DISTCUI e:\oracle\admin\cdpe\udump\cdpe_ora_02356.trc
DISTPA e:\oracle\admin\cdpe\udump\cdpe_ora_03624.trc
DIST e:\oracle\admin\cdpe\udump\cdpe_ora_03556.trc
DISTCUI e:\oracle\admin\cdpe\udump\cdpe_ora_03508.trc

Como desligar a opção de TRACE.

Já mostramos como utlizar, os pontos importantes e também algumas manhas, agora é hora de sabermos como fazer para desabilitar caso não precisemos mais usar essa feature, ai vai os passos :

ALTER SESSION SET SQL_TRACE = FALSE;
DBMS_SESSION.SET_SQL_TRACE(FALSE);

Caso você queira desabilitar um trace ligado especificamente para uma sessão em particular, execute o seguinte comando :

dbms_system.set_sql_trace_in_session(sid,serial#,false);

Então, como já passamos por diversas caracteristicas do TKPROF e a geração de arquivos Traces, porque não tentarmos automitizar este processo? Uma vez que depedendo de seu ambiente podemos ter várias e várias necessidades de gerações de arquivos de trace, então criaremos uma procedure para que nos auxilie nesse trabalho diário :

Criando Procedure de Geração de Trace

create or replace procedure start_trace
(v_sid in number,
v_serial# in number,
seconds in number)

end strat_trace;

Esta procedure mostrará como saida o nome do usuário que deu o start na geração de Trace, o horario de inicio e fim da coleta e geração do trace o diretório onde foi gerado o trace file e também o nome do trace file.

Bem por enquanto é isso, ainda mostrarei como Analisar este arquivo gerado,o significado das colunas existentes no arquivo de Trace File e as opções de comandos do TKPROF.

Até logo, e espero que gostem deste Post.
Abraços á todos.