Tuesday, May 24, 2005
Statspack - Interpretação
Retomando depois de encontrar algum tempo, vamos analisar o report propriamente.
Bom, estamos com quase 20 páginas de relatório e agora? As próximas linhas serão minha opinião de como trato o relatório e isso é completamente empírico, é a o método que eu encontrei para a interpretação de Statspack.
Caminhando pelas seções:
Aqui estou interessado no tempo, algo que passe de 30 minutos ou seja menos de 15, deveria ser desprezado. Nesta seção também encontramos os caches, log buffer e tamanho do bloco. Como podem notar, trabalho em um notebook de 256m de memória, portanto tive que customizar meu Oracle 10g para executar de maneira satisfatória neste ambiente. O Oracle 10g roda sim em computador com menos de 512m de memória - vale lembrar que não é para fim comercial e sim educativo. Tenho essa instância instalada para explorar e estudar o Oracle.
Load Profile
Aqui temos noção do load através da análise da quantidade de Executes, Transactions, Logical e Physical reads por segundo e transação. Estou interessado também no Hard Parses que deve estar bem próximo de zero. Se não estiver, na grande maioria dos sistemas, eu deveria seguir para o top de sql e encontrar queries sem bind variable.
Instance Efficiency Percentage
Nesta seção procuro saber a utilização da Shared Pool, através dos Library Hit %, Execute to Parse % e Soft Parse %. Se a Library Hit % está com valor baixo, isso indica que sua shared pool pode estar subdimensionada ou sua aplicação não está fazendo uso correto das bind variables.
Soft Parse % tem grande importância, na maioria dos sistemas ela deveria estar próxima de 100. Existem algumas exceções como sistemas baseados em web e DW.
Execute to Parse % assim como Soft Parse, deveria estar proximo de 100 na maioria dos sistemas, porém segue a mesma regra de exceção que o item anterior.
Top 5 Timed Events
Quando estou analisando um statspack report venho até aqui. A partir daqui, vou especificamente para algumas seções mais abaixo para buscar mais informação, mas em resumo, venho até aqui. O Top % Timed Events mostra os 5 maiores eventos de espera, a Oracle mudou o nome de espera para tempo gasto - para mim é a mesma coisa - a novidade foi incluir o tempo da CPU junto, o tempo de CPU não poderá ser um grande problema, faça um balanço entre o tempo do snap e o tempo da CPU (n Minutos x 60 segundos x m CPUs) se o valor estiver alto, provavelmente o sistema está usando índice onde deveria usar full table scan (Já discutimos anteriormente).
Fiz um exemplo onde tinha minha PGA_AGGREGATE_TARGET = 10m. Nesse exemplo, fiz sort forçando o estouro de memória e gravação na TEMP. Veja o resultado.
Após essa execução, aumentei a pga_aggregate_target para 50m. Como cheguei a esse valor veremos em uma próxima oportunidade. Rodei outro snap e encontrei isso:
Por que tão pouco, porque para efeito de demonstração fiz:
Portanto o tempo do snap, foi o tempo da execução da procedure. Como eu não tenho um sistema em minha instância, armei um exemplo simples para demonstrar o tuning com o pga_aggregate_target.
Se voce tem alguma dúvida no seu statspack, envie aqui e lhe ajudarei a interpretá-lo na medida do possível.
Bom, estamos com quase 20 páginas de relatório e agora? As próximas linhas serão minha opinião de como trato o relatório e isso é completamente empírico, é a o método que eu encontrei para a interpretação de Statspack.
Caminhando pelas seções:
STATSPACK report for
DB Name DB Id Instance Inst Num Release RAC Host
------------ ----------- ------------ -------- ----------- --- ----------------
ORA10G 3848249943 ora10g 1 10.1.0.2.0 NO MARCIO807955
Snap Id Snap Time Sessions Curs/Sess Comment
--------- ------------------ -------- --------- -------------------
Begin Snap: 51 23-May-05 23:02:45 17 6.2
End Snap: 52 23-May-05 23:32:50 17 6.4
Elapsed: 30.08 (mins)
Cache Sizes (end)
~~~~~~~~~~~~~~~~~
Buffer Cache: 24M Std Block Size: 8K
Shared Pool Size: 40M Log Buffer: 256
Aqui estou interessado no tempo, algo que passe de 30 minutos ou seja menos de 15, deveria ser desprezado. Nesta seção também encontramos os caches, log buffer e tamanho do bloco. Como podem notar, trabalho em um notebook de 256m de memória, portanto tive que customizar meu Oracle 10g para executar de maneira satisfatória neste ambiente. O Oracle 10g roda sim em computador com menos de 512m de memória - vale lembrar que não é para fim comercial e sim educativo. Tenho essa instância instalada para explorar e estudar o Oracle.
Load Profile
Aqui temos noção do load através da análise da quantidade de Executes, Transactions, Logical e Physical reads por segundo e transação. Estou interessado também no Hard Parses que deve estar bem próximo de zero. Se não estiver, na grande maioria dos sistemas, eu deveria seguir para o top de sql e encontrar queries sem bind variable.
Instance Efficiency Percentage
Nesta seção procuro saber a utilização da Shared Pool, através dos Library Hit %, Execute to Parse % e Soft Parse %. Se a Library Hit % está com valor baixo, isso indica que sua shared pool pode estar subdimensionada ou sua aplicação não está fazendo uso correto das bind variables.
Soft Parse % tem grande importância, na maioria dos sistemas ela deveria estar próxima de 100. Existem algumas exceções como sistemas baseados em web e DW.
Execute to Parse % assim como Soft Parse, deveria estar proximo de 100 na maioria dos sistemas, porém segue a mesma regra de exceção que o item anterior.
Top 5 Timed Events
Quando estou analisando um statspack report venho até aqui. A partir daqui, vou especificamente para algumas seções mais abaixo para buscar mais informação, mas em resumo, venho até aqui. O Top % Timed Events mostra os 5 maiores eventos de espera, a Oracle mudou o nome de espera para tempo gasto - para mim é a mesma coisa - a novidade foi incluir o tempo da CPU junto, o tempo de CPU não poderá ser um grande problema, faça um balanço entre o tempo do snap e o tempo da CPU (n Minutos x 60 segundos x m CPUs) se o valor estiver alto, provavelmente o sistema está usando índice onde deveria usar full table scan (Já discutimos anteriormente).
Fiz um exemplo onde tinha minha PGA_AGGREGATE_TARGET = 10m. Nesse exemplo, fiz sort forçando o estouro de memória e gravação na TEMP. Veja o resultado.
Top 5 Timed Events
~~~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) Call Time
-------------------------------------------- ------------ ----------- ---------
direct path read temp 10,488 77 84.79
direct path write temp 7,464 5 5.92
db file sequential read 251 4 4.18
control file sequential read 585 2 1.79
db file parallel write 83 1 .99
Após essa execução, aumentei a pga_aggregate_target para 50m. Como cheguei a esse valor veremos em uma próxima oportunidade. Rodei outro snap e encontrei isso:
Top 5 Timed Events
~~~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) Call Time
-------------------------------------------- ------------ ----------- ---------
db file sequential read 35 1 31.72
control file parallel write 15 1 29.34
control file sequential read 587 0 22.94
db file scattered read 34 0 7.69
latch free 6 0 6.96
Por que tão pouco, porque para efeito de demonstração fiz:
create or replace procedure p
as
begin
for i in 1 .. 100
loop
for x in ( select big.owner, big.object_name, big.created
from big, small
where big.id = small.id
order by 1, 2, 3 )
loop
null;
end loop;
end loop;
end;
/
show error
pause
begin
statspack.snap;
p;
statspack.snap;
end;
/
Portanto o tempo do snap, foi o tempo da execução da procedure. Como eu não tenho um sistema em minha instância, armei um exemplo simples para demonstrar o tuning com o pga_aggregate_target.
Se voce tem alguma dúvida no seu statspack, envie aqui e lhe ajudarei a interpretá-lo na medida do possível.
