segunda-feira, 20 de julho de 2009

TKPROF - Utilizar ou não? E porque? - Parte III

Olá como vão todos? Bem chegamos ao final do nosso assunto que começou a algumas semanas atrás, um assunto que eu considero importante, não só pelo aspecto profissional, mais também como forma de conhecer uma das inúmeras técnicas que podem ser utilizadas no Oracle, tanto para identificação de problemas , como para solução dos mesmos.

Afim de relembrarmos um pouco o que foi dito até então, atentem para os dois ultimos post's sobre o assunto, que se encontram no seguinte endereço :


TKPROF - Utilizar ou não? E porque?


http://profissionaloracle.com.br/blogs/drbs/2009/06/30/tkprof-utilizar-ou-nao-e-porque/


TKPROF - Utilizar ou não?E porque? - Parte II


http://profissionaloracle.com.br/blogs/drbs/2009/07/02/tkprof-utilizar-ou-nao-e-porque-parte-ii/


Voltemos então ao nosso assunto, e agora chegou o momento de export quais as opções que encontramos ao utilizarmos a ferramenta TKPROF, quais as opções para gerarmos o "report" interpretado e o que significam essas respectivas informações. Mais uma vez agradeço á todos e espero que apreciem mais este Post.


OPÇÕES DE COMANDO DO TKPROF.

Bem, como já vimos nos demais posts, há várias informações que a nós são disponibilizadas por meio da ferramenta, vimos também como interpreta-las melhor e qual o significado de cada coluna mostrada nos arquivos interpretados, e por fim chegamos então a parte , senão a mais importante, umas das mais curiosas e interessantes, o momento em que determinamos como será a saida do arquivo de "output" do TKPROF, suas opções e para que servem cada uma delas, vamos lá?


Dentre as opções mais comuns encontramos as seguintes:

  • print : serve para informar quantas instruções SQL você que que seja mostrado no seu arquivo de saida, caso não seja informado nada, por padrão ele trará todas as intruções envolvidas no processo de coleta. Esta opção se tulizada em combinação com a opção sort, que veremos mais a frente , nos tras boas informações sobre CPU, ou leituras de Discos, Parses e etc.

  • aggregate: se for informado a opção "YES", as estatisticas são combinadas, pegando informações de multiplas instruções SQL em execução. Se passar a opção "NO" serão mostradas a cada execução uma listagem de estatisticas separadamente.

  • insert: esta opção criará um arquivo contento as estatisticas carregadas. Escolha esta opção sempre que quiser uma analise avançãda da performance no arquivo de saida do tkprof.

  • sys: aqui podemos informar se as intruções executadas pelo usuário SYS, sevem ser mostradas ou não. Por padrão esta opção fica sempre habilitada.

  • table: aqui podemos informar uma tabela Oracle que recebera o conteudo do arquivo de saida, essa tabela pode existir ou não, se por acaso existir seu dados serão sobrescritos pelos novos dados.

  • record:esta opção criará um arquivo apartado contendo todos SQL não recursivos do trace file. Para os DBAS essa opção é muito util, pois cria uma espécie de LOG.

  • explain: utilizamos esta opção para capturar cada instrução e msotras no output file, é pouco utilizada em conjunto com TKPROF, ela nos mostra as predicted execuções, e não as atuais como é o papel central do TKPROF.

  • sort: talvez a mais importante opção, pois nos mostra os consumos ocasionados pelas instruções SQL executadas no decorrer da coleta.
Abaixo vamos mostrar algumas das opções que podem ser usadas e combinadas com a opção SORT :

  • prscnt
  • prscpu
  • prsela
  • prsdsk
  • prsmis
  • prscu
  • execnt
  • execpu
  • exeela
  • exedsk
  • exeqry
  • execu
  • exerow
  • exemis
  • fnhcnt

E muitas outras, essas opções podem ser visualizadas através do comando TKPROF, que pode ser executado dentro de uma janela DOS ou de um terminal ( Linux), lá encontraremos todas as opções de SORT assim como as outras opções disponiveis na ferramente TKPROF.

Bem, notamos que até agora tudo foi direcionado ao TKPROF como uma forma próativa de buscar soluções nem sempre rápidas, porém muito mais eficazes no sentido de detectar o alvo do problema e porpor soluções precisas e coerentes com o problema que for encontrado em seu ambiente ou em suas instruções SQL.

Mas, ha também uma forma mais "amena" , de identificar possiveis SQL's que esteja causando problemas visiveis aos Developers e consequentemente aos DBA's de Plantão.

Por vezes identificamos através de uma combinação de instruções SQL (Join's), feitas por muitos DBA em forma de script de Administração de ambiente, e nos deparamos com inumeras instruções em execução no momento, porém sempre uma chama mais atenção que a outra, vezes por seu tempo demasiado demorado ou por que alguem nos trouxe a queixa de que determinado processo já deveria ter terminado, algumas visões de banco muito utilizadas para essa tarefa são : V$SQLAREA, V$SQLTEXT, V$SESSION, V$PROCESSES e V$LONGOPS

Essas visões combinadas formam armas poderosissimas na luta para buscar uma informação mais pertinente ao que esta impactando de verdade em nosso SGBD.


Uma vez identificado a "maçã-podre" do pomar, temos aopção de usar uma ferramente bem simples porém eficiente quando o assunto é apenas um beve tunning , ela se chama EXPLAIN PLAN , um comando muito utilizado para nos mostras via SQL*Plus os passos de uma determinada instrução , onde podemos visualizar sua trajetoria dentre as dependencias dos objetos envolvidos em seu corpo.


Como faze-lo? Simples , basta que tenha em mãos uma janela SQL*Plus aberta e antes de executar a instrução digite os seguintes comandos :





Como podem ver na imagem acima, as informações disponíves correspondem ao tempo , custo e caminho percorrido pela instrução SQL, bem como sua cardinalidade, bytes trafegados etc.

As opções que podem ser facilmente utilizadas por esse método de analise das instruções SQL são :


on - habilita todas opçõe
on explain - mostra o plano de execução de todas as linhas
on statistics - mostra todas as estatisticas
trace explain - mostra o plano de execução de um select sem estar executando o mesmo.
traceonly - mostra o plano d eexecução sem o retorno das linhas, deve ser usado quando o retorno de linhas é muito massivo.

Por fim após uma implementação na release 9i, pudemos contar com um pacote muito util nesse sentido a DBMS_XPLAN, onde em seu corpo há um Procedure de DISPLAY que pode ser facilmente utilizado da segunite maneira :



É isso pessoal, obrigado pela paciencia de esperar este ultimo Post sobre o assunto, e espero que apreciem , logo mais voltarei com algum assunto que ache interessante para todos. Meus agradecimentos aos meus amigos que me incentivam sempre ( Leonardo, Litz, Rodrigo (Alphamek), Raphael e João).

Um abraço á todos.