Amigos,
Costumo utilizar a consulta abaixo:
SELECT to_char(begin_time, 'DD-MON-RR HH24:MI:SS') begin_time,
to_char(end_time, 'DD-MON-RR HH24:MI:SS') end_time,
metric_name,
value
FROM v$sysmetric
WHERE metric_name in ('CPU Usage Per Sec',
'Current OS Load',
'Host CPU Utilization (%)')
ORDER BY begin_time
A view V$SYSMETRIC coleta estatísticas de curta duração a cada 15s e
de longa duração 60s.
Existe um histórico em V$SYSMETRIC_HISTORY, que guarda as estatísticas
de longa duração por 1 hora.
Lembrando que a métrica "CPU Usage Per Sec" é em centésimo de segundo
por segundo. Assim como o amigo Chiappa falou anteriormente. Ou seja,
você vai ter o tempo consumido dentro da CPU, e não o percentual que o
"banco" está consumindo.
2009/10/13 jlchiappa <jlchia...@yahoo.com.br>:
> Opa, intão, deixem-me dar uns palpites aí : primeiro, a query em questão
> lista as sessões fazendo muito I/Os, muitas vezes elas também são grandes
> consumidoras de CPU (já que CADA bloco lido necessariamente tem que ser
> 'gerenciado' em cache, muitas vezes há que se fazer uma leitura consistente,
> etc, isso custa CPU) mas é meio arriscado dizer que necessariamente essas são
> as tpo consumidoras de CPU, há várias outras tarefas (tais como compilação de
> Pl/SQL, parse de SQLs, contas/cálculos, context switch entre SQL e PL/SQL,
> entre muitas outras) que podem consumir muita CPU sem necessariamente fazer
> montes de I/Os.... Segundo, a pergunta original é "quantos porcento de CPU
> uma sessão utilizou na sua atividade?", e isso ABSOLUTAMENTE NÃO É registrado
> nas views/tabelas internas : entre outras questões, o fato é que para se
> saber quanto um dado volume representa do total, vc TEM que conhecer o total,
> e por mais que nós DBAs não consideremos assim a verdade é que o bd Oracle
> num servidor é simplesmente um software a mais, ele ** NÃO ** necessariamente
> roda com privilégios administrativos diferenciados, ele é só um CONSUMIDOR
> dos recursos (ie, CPU, RAM, I/O, rede) , via de regra ele Não Tem Como saber
> o total de CPU da máquina como um todo pra poder extrapolar quantos % do 100%
> total cada sessão representa, isso em tese só um account Admin poderia
> fazer... Exatamente POR ISSO o pessoal do kernel do banco Oracle fez o
> seguinte : instrumentou cada chamada por recursos botando antes e depois dela
> um call ao clock do sistema, tipo :
>
> # quero fazer um I/O, portanto :
> getsystemclock1
> pedeporumI/O
> quando recebeu o I/O, getsystemclock2
> calcula a diferença de tempo entre as chamadas 1 e 2
>
> # quero fazer uma operação em RAM do bloco lido (e portanto consumir CPU) :
> getsystemclock1
> faz o processamento de mover o bloco
> quando recebeu o resultado de OK, getsystemclock2
> calcula a diferença de tempo entre as chamadas 1 e 2
>
> ... etc, etc, etc ....
>
> então a idéia por trás é : vc sabe sempre apenas o TEMPO que cada operação
> que consumiu CPU, I/O, rede ou o que for levou pra ser ATENDIDA, apenas e tão
> somente isso, assim praticamente TODAS as views/tabelas internas te dão **
> TEMPO ** gasto com CPU, ** TEMPO ** gasto com I/O, etc... É sempre o TEMPO, e
> não % do total, ok ?? E isso nos leva a um OUTRO ponto crucial para o
> entendimento desse tipo de monitoração, que é o efeito cascata: já que na
> prática o que o banco mede é o tempo de resposta, digamos que o servidor está
> folgado, aí um I/O demora 10 milisegundos (digamos), então digamos que uma
> rotina periódica que esteja rodando e que faça 100 I/Os vai gastar
> 10*100=1000 milisegundos... Agora suponha que uma ** outra ** rotina pesada
> (até de fora do banco, talvez) comece a rodar nesse servidor e fazer montes
> de I/Os e satorou o sub-sistema de I/O da máquina : OBVIAMENTE, cada I/O vai
> ser mais lento, pois o servidor está ao mesmo tempo sendo acessado e
> atendendo aquele outro monstrão, então para esses mesmos 100 I/Os vai se
> gastar muito mais tempo.... Esse é o ponto, as views/tabelas do banco te
> mostram quem está demorando mais em gasto de tempo de CPU de I/O, de tudo ***
> MAS *** a priori consultando só elas vc NÂO TEM COMO identificar em quais os
> números estão aumentando por causa de espera por recurso indisponível e quais
> exatamente estão realmente usando demais o recurso..... No banco 10g em
> diante vc pode ainda ativar o recurso das views V$OSSTAT e do histórico dela,
> ela ** também ** é por tempo mas é mais detalhada, listando o tempo que as
> CPUs do sistema ficaram IDLE, tempo de uso pelo kernel do banco, tempo de uso
> das CPUs pelo usuário,
> http://www.databasejournal.com/features/oracle/article.php/3799846/Looking-at-your-operating-system-with-the-help-of-Oracles-VOSSTAT-view.htm
> as relaciona.... Isso pode te ajudar, mas pra se identificar exatamente o
> consumo de CPU , com QUEM, QUANDO, AONDE e POR QUE, sorry mas não tem uma
> fonte só, uma vez consultadas as views tipo vc terá que :
>
> a) consultar repetidas vezes a V$SESSTAT/V$SESSION_WAIT e similares (ou as
> OSSTAT ou o que for) , a cada vez armazenando o valores, para poder comparar
> qual/quais sessões passaram a ter mais 'tempo' de CPU (ou seja qual for o
> recurso que vc quer monitorar) - lembro que a V$SQL na versão 10gR2 já é
> "on-line", ie, enquanto o SQL está rodando as estatísticas de consumo de CPU,
> I/O e etc vão sendo atualizadas, então ESSA seria uma fonte Preciosa para se
> localizar SQLs ruinzões consumindo muita CPU
>
> b) usar os comandos do Sistema Operacional como mostrado, eles sim possui
> instrumentação para identificar por % consumos
>
> c) para as sessões identificadas em a), usar as views de histórico (seja a
> V$ACTIVE_SESSION_HISTORY, V$SYS_TIME_MODEL , as de AWR, o que vc tiver
> direito e puder usar) para elas, consultando estat´siticas de SQLs
> executados, waits anteriores... O Objetivo aqui é identificar picos de uso
> por um recurso...
>
> d) traces são outro recurso que eventualmente vc pode lançar mão, nele ficam
> registradas as quantidades de vezes em que WAITs foram pedidos , além do
> tempo, pode te ajudar também...
>
> []s
>
> Chiappa
>
>
> --- Em oracle_br@yahoogrupos.com.br, Priscila Viana <priska....@...> escreveu
>>
>> escreve esse comando no unix, ele vai de mostrar os processo que estão
>> consumindo mais.
>>
>> #### /usr/ucb/ps -aux|more
>>
>> 2009/10/9 Willian Fernando Frasson <wfras...@...>
>>
>> >
>> >
>> > segue um select bem simples para pegar as 10 sessões que tem maior consumo
>> > de cpu:
>> >
>> > SELECT * FROM (
>> > SELECT
>> > UPPER(b.username) username
>> > , a.disk_reads disk_reads
>> > , a.executions executions
>> > , a.disk_reads / decode(a.executions, 0, 1, a.executions) reads_per_exec
>> > , sql_text || chr(10) || chr(10) sql
>> > FROM
>> > sys.v_$sqlarea a
>> > , dba_users b
>> > WHERE
>> > a.parsing_user_id = b.user_id
>> > AND a.disk_reads > 1000
>> > AND b.username NOT IN ('SYS','SYSTEM')
>> > ORDER BY
>> > disk_reads desc
>> > )
>> > WHERE ROWNUM <11
>> > ;
>> >
>> > Outra forma que você pode pegar de uma determinada sessão, pegue a mesma
>> > via PID de SO, ataves do PID, pegue o ISD e Serial# e faça um trace da
>> > mesma.
>> >
>> > abcs.
>> >
>> >
>> > ----- Original Message -----
>> > From: Márcio Ricardo Alves da Silva
>> > To: oracle_br@yahoogrupos.com.br <oracle_br%40yahoogrupos.com.br> ;
>> > gpora...@yahoogrupos.com.br <GPOracle%40yahoogrupos.com.br>
>> > Sent: Friday, October 09, 2009 10:04 AM
>> > Subject: [oracle_br] total de cpu(%)
>> >
>> > GeleiraBom dia!
>> >
>> > Tem alguma maneira de identificar quantos porcento de CPU uma sessão
>> > utilizou na sua atividade?
>> >
>> > RELEASE 10.2.0.1
>> > Márcio
>> >
>> > [As partes desta mensagem que não continham texto foram removidas]
>> >
>> > ----------------------------------------------------------
>> >
>> > O Banco de Dados de Vírus interno expirou.
>> > Verificado por AVG - http://www.avgbrasil.com.br
>> > Versão: 8.0.233 / Banco de dados de vírus: 270.10.16/1926 - Data de
>> > Lançamento: 30/1/2009 17:31
>> >
>> > [As partes desta mensagem que não continham texto foram removidas]
>> >
>> >
>> >
>>
>>
>> [As partes desta mensagem que não continham texto foram removidas]
>>
>
>
>
>
> ------------------------------------
>
> --------------------------------------------------------------------------------------------------------------------------
>>Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira
>>responsabilidade de seus remetentes.
> Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/
> --------------------------------------------------------------------------------------------------------------------------
>>Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » Procedure »
>>Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE:
>>http://www.oraclebr.com.br/
> ------------------------------------------------------------------------------------------------------------------------
> Links do Yahoo! Grupos
>
>
>
--
Rosivaldo Azevedo Ramalho
Consultor Oracle Database / Application Server
mail/msn: rosiva...@gmail.com
mobile: +55 83 8893 8281
Oracle Database 10g Certified Professional
Oracle Application Server 10g Certified Professional
