Menu de navegação

[vieriParticipante]

Galera ,

seguinte:

Essas são as taxas de acerto do meu banco.
a taxa de acerto em memoria do cache de buffer está em 80%.
Lendo em algum livros eles falam pra só alterar caso seja
<60%. Porem meu feeling diz que ele está mal utilizado.

LIBRARYCACHE;

ROUND(SUM(PINHITS)/SUM(PINS)*1
------------------------------
99.8

SORT
----------
99.67

DB_BUFFER
----------
80.42

DICT
----------
99.8

O meu parâmetro db_block_buffers está setado como 0. Os livros recomendam que se aumente esse valor no tipo de caso que citei acima
Alguem sabe o porque desse valor está zerado é oque ele implica no banco.

NAME TYPE
------------------------------------ --------------------------------
VALUE
------------------------------
db_block_buffers integer
0

log_buffer integer
1048576

aceito sugestões..

[]s.

[IshiiParticipante]

Ola,

o db_block_buffer eh um parametro que determina a quantidade de bloco (db_block_size) que vao ficar no Buffer, isso esta zerado e indica que 0 blocos ficarao no Buffer Cache, a melhora de performance somente será notada se a mesma query for muito utilizada e se compensaria ter ela em buffer sem alteracao de dados.

Qual eh a query que esta com problemas? Ou quais as queries com problemas? A config do Server (HW) SO etc o que puder informar mais…

[vieriParticipante]

Ishii ,

Vc acha que seria uma boa estratégia adicionar algum valor
a esse parâmetro DB_BLOCK_BUFFERS ? Existe alguma formula para se calcula-lo. visto que o default do oracle é 0 .
Não existe uma query principal que “atole” o banco,
Mais estou achando que essas taxas do database buffer pode estar degradando a performance de uma maneira geral.

algumas informações :

SQL> show parameters pool

NAME TYPE

---

VALUE

buffer_pool_keep string

buffer_pool_recycle string

global_context_pool_size string

java_pool_size string
33554432
large_pool_size string

NAME TYPE

---

VALUE

419430400
shared_pool_reserved_size big integer
15938355
shared_pool_size big integer
318767104

ct/9.0.1/rdbms/admin>uname -a1:/soft/app/oracle/produc
Linux uxrjo063 2.4.9-e.49custom #2 SMP Tue Sep 21 15:45:10 BRST 2004 i686 unknown

principais eventos :

Top 5 Wait Events
~~~~~~~~~~~~~~~~~ Wait % Total
Event Waits Time (s) Wt Time

---

SQL*Net message from dblink 80,007 2,119 33.75
db file sequential read 244,090 936 14.90
log file parallel write 22,545 841 13.40
db file scattered read 191,380 736 11.72
log file sync 13,597 490 7.80
————————————————————-

abraços

[vieriParticipante]

vc diz : “a melhora de performance somente será notada se a mesma query for muito utilizada e se compensaria ter ela em buffer sem alteracao de dados.”

Isso significa que adicionar um valor a o db_block_buffers irá determinar a quantidade de blocos em cache que naum sofrem alterações… ?
qual regra é utilizada para mante-los em cache ?

[IshiiParticipante]

Vieri,
O DB_BLOCK_BUFFERS teria mais utilidade quando a mesma query com os mesmo dados são acionados várias vezes com isso se teria um menor I/O na execução e extração dos dados uma vez que já está em Buffer este valor multiplicado pelo DB_BLOCK_SIZE daria o qto de Mem estaria alocada somente para o Buffer com o valor Zero o buffer fica sempre limpo para novas consultas.

Depende mais da sua aplicação ou do problema específico que pode estar ocorrendo. O db file sequential read parece normal mas isso depende da aplicação rodando pois pode significar que esta ocorrendo um grande número de consultas ou atualizações do BD (controladas pelo DBWR). O consumo do Processamento (top) no Linux é muito alto e por muito tempo? Ou seja o consumo de Hardware é pesado? Há muita fragmentação dos Dados? Essas são apenas observações do ponto de vista do Server mas às vezes precisa ser analisado a Aplicação que está sendo executada… por exemplo, A performance degrada em Queries ou em Procedures? Há alguma query dentro de uma procedure que possa estar sendo a vilã do problema? Se for uma app Java, podemos ter outras variáveis…

O tunning é uma arte (às vezes misto de Conhecimento , Magia Negra e Bom Senso) e nos pequenos detalhes é que pode estar o problema. Já vi casos onde apenas aumentando o tamanho do Control File o tempo de execução caiu de 2 horas para 2 minutos…

Sei que às vezes é difícil mas se puder enviar o máximo de informações (mesmo que pareçam não ser relevantes) se houver confidencialidade mande um e-mail ishii.fabio@gmail.com

[]s Ishii

[vieriParticipante]

Realmente é uma arte…
É o trabalho mais interessante e istigante de um DBA,
estou alguns meses venho fazendo alguns trabalho de tunning…
Como vc mesmo disse é dificil saber aonde está o problema!!
e para minha e sua surpresa, o problema estava no servidor de
aplicação que alteraram uma configuração fazendo com que abrisse
1300 conexões, quando o normal dessa base era em torno de 300.
Gerando umá má tilização de memoria, sem nescessidade, visto que a maioria desses usuarios estão inativos no banco.
Após alterarem o servidor de aplicação para o valor normal
em torno de 300 conexões abertas, a performance do banco voltou ao normal.

Veja como o buffer hit melhorou… 😀
quase 10 %

Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 99.96 Redo NoWait %: 100.00
Buffer Hit %: 94.47 In-memory Sort %: 99.79
Library Hit %: 99.94 Soft Parse %: 99.78
Execute to Parse %: 5.66 Latch Hit %: 99.87
Parse CPU to Parse Elapsd %: 22.46 % Non-Parse CPU: 99.53

Outro detalhe…
O parÂmetro db_block_buffer é depreciado nas versões
<9.0 certo ? entao DB_CACHE_BUFFER incluido na versão 9i dever ter a mesma funções de alocar em memoria os dados + acessados para eviar o I/O certo?

Oque achou do veredito?minha teoria está correta?

abraçoss amigo !!

[IshiiParticipante]

vieri,

Ótimo ter descoberto o problema. Como eu já disse é uma arte (às vezes depreciada por outros) e por isso defendo a tese que nestas situações FAÇAM UM MARKETING sobre os resultados do tipo: O tempo de 2 horas caiu para 2 minutos, o servidor estava com 99,999% de Utilização de Memória e agora está com 80%, o relatório/processo/consulta estava demorando 20 minutos e agora leva 0,2 segundos senão ninguém valoriza…

O DB_CACHE_SIZE (acho que era isso que vc queria dizer) tem essa função mesmo mas no 9i e superiores já vem com um valor default reservado no buffer para isso mas como sempre requer um estudo adequado sobre a sua utilização correta de acordo com a Aplicação em uso.

Att

Ishii

[vieriParticipante]

Valeu shi,

Até a próximo Tunning!!
Que va para o Limbo que desconhece essa arte, que salva aplicações!!!

Gostei da parte do marketing! 😉

abraço

[armandovelosoParticipante]

Caro Ishii,

estou lendo hoje os posts desse topico…
entao vi um seu que diz assm:

“Já vi casos onde apenas aumentando o tamanho do Control File o tempo de execução caiu de 2 horas para 2 minutos… ”

Estou passando por problemas tambem de performance, tenho analisado relatorios de performance e etc, e queria confirmar uma coisa a respeito do que vc escreveu:
voce quis dizer aumentar o tamanho dos “log files” e nao dos “control files”, certo?

[IshiiParticipante]

Vieri,

Sim na verdade foram duas alterações, separando os Control Files para devices separados e aumentando os Redo Files de 5 MB para 50Mb…

Os grupos de REDO também foram separados para devices diferentes…

[]s Ishii

[armandovelosoParticipante]

Beleza!

[Autor]

Posts