- Este tópico contém 16 respostas, 6 vozes e foi atualizado pela última vez 14 anos, 2 meses atrás por
Rodrigo Almeida.
-
AutorPosts
-
15 de setembro de 2011 às 8:00 pm #100823
mpvargas
ParticipanteCaros Amigos,
Verificando a utilização do Buffer Cache ao executar a query abaixo, observei que a taxa de acerto está muito baixa, algo em torno de 55%SELECT NAME, PHYSICAL_READS, DB_BLOCK_GETS, CONSISTENT_GETS,
1 – (PHYSICAL_READS / (DB_BLOCK_GETS + CONSISTENT_GETS)) “Hit Ratio” FROM V$BUFFER_POOL_STATISTICS;Resultado:
NAME PHYSICAL_READS DB_BLOCK_GETS CONSISTENT_GETS Hit Ratio
——————– ———————- ———————- ———————- ———————-
DEFAULT 2584399252 421057432 5402225949 0.5561955201369239358334431707094008585395Na base que eu tinha anteriormente, fiz o ajuste do parâmetro e consegui chegar entre 90 e 95%, mas não lembro exatamente em qual ou quais parâmetros fiz a alteração.
Alguém poderia me dar uma dica. Obrigado.
15 de setembro de 2011 às 9:29 pm #100825lordmaca
Participante[quote=”mpvargas”:58nvdch4]Caros Amigos,
Verificando a utilização do Buffer Cache ao executar a query abaixo, observei que a taxa de acerto está muito baixa, algo em torno de 55%SELECT NAME, PHYSICAL_READS, DB_BLOCK_GETS, CONSISTENT_GETS,
1 – (PHYSICAL_READS / (DB_BLOCK_GETS + CONSISTENT_GETS)) “Hit Ratio” FROM V$BUFFER_POOL_STATISTICS;Resultado:
NAME PHYSICAL_READS DB_BLOCK_GETS CONSISTENT_GETS Hit Ratio
DEFAULT 2584399252 421057432 5402225949 0.5561955201369239358334431707094008585395
Na base que eu tinha anteriormente, fiz o ajuste do parâmetro e consegui chegar entre 90 e 95%, mas não lembro exatamente em qual ou quais parâmetros fiz a alteração.
Alguém poderia me dar uma dica. Obrigado.[/quote]
@mpvargas,
qual valor do seu DB_BLOCK_BUFFERS ou voce esta usando db_cache_size?
Qual versao da base e OS?
Abraco
Att,
15 de setembro de 2011 às 9:57 pm #100827Victor Armbrust
Mestre[quote=”lordmaca”:12wm249u][quote=”mpvargas”:12wm249u]Caros Amigos,
Verificando a utilização do Buffer Cache ao executar a query abaixo, observei que a taxa de acerto está muito baixa, algo em torno de 55%SELECT NAME, PHYSICAL_READS, DB_BLOCK_GETS, CONSISTENT_GETS,
1 – (PHYSICAL_READS / (DB_BLOCK_GETS + CONSISTENT_GETS)) “Hit Ratio” FROM V$BUFFER_POOL_STATISTICS;Resultado:
NAME PHYSICAL_READS DB_BLOCK_GETS CONSISTENT_GETS Hit Ratio
DEFAULT 2584399252 421057432 5402225949 0.5561955201369239358334431707094008585395
Na base que eu tinha anteriormente, fiz o ajuste do parâmetro e consegui chegar entre 90 e 95%, mas não lembro exatamente em qual ou quais parâmetros fiz a alteração.
Alguém poderia me dar uma dica. Obrigado.[/quote]
@mpvargas,
qual valor do seu DB_BLOCK_BUFFERS ou voce esta usando db_cache_size?
Qual versao da base e OS?
Abraco
Att,[/quote]
Mais uma pergunta: Você está usando ASMM (sga_target) ?
16 de setembro de 2011 às 12:26 am #100836mpvargas
ParticipanteDB_BLOCK_BUFFERS = 0
Db_cache_size = 0
Versao da base = 10.2.0.1.0
OS = CentOS release 4.7
16 de setembro de 2011 às 9:35 am #100839lordmaca
Participante@mpvargas,
Voce esta utilizando ASMM entao seu buffer esta sendo gerenciado automaticamente, me informe o valor deste parametro:
db_file_multiblock_read_count
Abraco.
16 de setembro de 2011 às 5:39 pm #100841mpvargas
ParticipanteVinicius
Não uso ASM… tenho 8 discos, distribuidos em 4 grupos de 2
espelhados em RAID 1db_file_multiblock_read_count = 16
16 de setembro de 2011 às 7:03 pm #100842vpapa
Participante[quote=”mpvargas”:2a8qc8ox]Vinicius
Não uso ASM… tenho 8 discos, distribuidos em 4 grupos de 2
espelhados em RAID 1db_file_multiblock_read_count = 16[/quote]
@mpvargas,
Sim mas ASMM não é ASM.
ASMM(Automatic Share Memory Management) – Essa funcionalidade estara sempre ativada com seu SGA_TARGET estiver setado maior que 0.
Aumenta esse parametro para 32 e veja se melhora seu Hit Ratio.
Esse parametro é quantos blocos são lidos de uma vez pelo Oracle em Disco, assim aumentando o mesmo você ira diminuir I/O e seu disco e seu buffer cache terá mais blocos em buffer.
A respeito você não nos disse quanto esta setado em seu SGA_TARGET, aproveitando me fale se tem memoria disponivel na maquina ok?
Abraco.
Att,
16 de setembro de 2011 às 9:21 pm #100845felipeg
ParticipanteOpa,
Lembrando que ficar apenas aumentando o valor do DB_FILE_MULTIBLOCK_READ_COUNT não significa muita coisa, pelo contrário, se o Oracle achar que o valor ficou legal pra ficar fazendo full-table scan ele vai forçar pois quanto maior a quantidade de blocos lidos em uma única operação menor o custo da tarefa pro otimizador.
Outro ponto (How To Set DB_FILE_MULTIBLOCK_READ_COUNT in 10g (Doc ID 841444.1))
"Oracle Database 10g Release 2 automatically selects the appropriate value for this parameter depending on the operating system optimal I/O size and the size of the buffer cache. It is automatic in 10gR2"
O Hit radio é apenas uma análise de efetividade do buffer, quanto maior o hit mais o Oracle te informa que achou um bloco em memória ao invés de ter que ler em disco.
Sugiro consultar a view v$db_cache_advice, que mostra as taxas de 10% do tamanho do buffer até 200%, comparado cada tamanho com a melhoria de leituras que pode ser obtida.
Gerar um STATSPACKAWR também é uma boa ideia ara visualizar o uso dos blocos e quantidade de leituras a longo prazo (histórico).
Atenciosamente,
Felipe.16 de setembro de 2011 às 9:52 pm #100846mpvargas
ParticipantePerdão Vinicius, fiz confusão
Seguem mais algumas informações
Servidor = 14 GB de RAM
SGA_MAX_SIZE = 6 GB
SGA_TARGET = 5.728 MB
16 de setembro de 2011 às 9:57 pm #100847mpvargas
ParticipanteFala Felipe,
Segue resultado da view v$db_cache_advice
SELECT size_for_estimate, buffers_for_estimate, estd_physical_read_factor, estd_physical_reads FROM V$DB_CACHE_ADVICE WHERE name = ‘DEFAULT’ AND block_size = (SELECT value FROM V$PARAMETER WHERE name = ‘db_block_size’) AND advice_status = ‘ON’;
SIZE_FOR_ESTIMATE BUFFERS_FOR_ESTIMATE ESTD_PHYSICAL_READ_FACTOR ESTD_PHYSICAL_READS
480 59520 1.1375 3000966396
960 119040 1.0885 2871548951
1440 178560 1.0589 2793504264
1920 238080 1.0399 2743575655
2400 297600 1.0271 2709547398
2880 357120 1.0181 2685960932
3360 416640 1.0118 2669234232
3840 476160 1.0072 2657045133
4320 535680 1.0036 2647758078
4800 595200 1.0008 2640281099
4944 613056 1 2638181215
5280 654720 0.9984 2633835071
5760 714240 0.9961 2627824040
6240 773760 0.9938 2621825049
6720 833280 0.9914 2615510185
7200 892800 0.9888 2608570621
7680 952320 0.9858 2600708527
8160 1011840 0.9824 2591637079
8640 1071360 0.9784 2581103513
9120 1130880 0.9735 2568156769
9600 1190400 0.9674 255223597816 de setembro de 2011 às 10:20 pm #100848vpapa
Participante@felipeg
Muito bem observado.
Achei uma anotação minha de um tempo atras.
- PARAMETROS DE INSTANCE QUE, SE CONFIGURADOS ERRONEAMENTE CAUSAM FTS
- DB_FILE_MULTIBLOCK_READ_COUNT (HIGH)
- HASH_AREA_SIZE (SMALL)
- OPTIMIZER_INDEX_COST_ADJ (SMALL)
@mpvargas,
Faça uma analise com o AWR.
Uma pergunta, você verificou o Hit Ratio pois algumas querys estão mais lentas?
Att,
16 de setembro de 2011 às 10:31 pm #100849felipeg
ParticipanteAcho que esse é o ponto do post.
Você identificou o baixo hit devido a uma busca por baixa performance ou simplesmente por uma pesquisa aleatória.
Hit Radio as vezes pode ser muuito mentiroso, você pode obter em uma consulta em um ponto do tempo 90% e perceber que durante alguns minutos o hit foi de 40% e no resto 98%.
Nem sempre um baixo valor significa problema, lembre-se disso.
Sem contar que há uma série de fatores a serem considerados na sua estrutura e na finalidade do banco que impactam no retorno do nosso amigo Hit.
Sugiro dar uma lida, com calma, desse artigo em diante.
http://download.oracle.com/docs/cd/B141 … .htm#34133
Atenciosamente,
Felipe.16 de setembro de 2011 às 11:44 pm #100850mpvargas
ParticipanteVinicius e Felipe
Essa semana recebi algumas reclamações de usuários de que o sistema estava lento e observei que o I/O está muito alto e consequentemente o número de leituras físicas…
Recentemente precisei restaurar a base pelo import, e chequei alguns parametros mas não todos… lembro que tive um problema desse uma certa vez e a alteração desses parametros melhorou bastante a situação e lembro tb que o Hit sempre dava uma taxa de acerto maior que 90%
Para tentar minimizar esse I/O que estou tentando fazer esse ajuste do buffer_cache17 de setembro de 2011 às 11:03 am #100851vpapa
Participante[quote=”mpvargas”:1cfqarvq]Vinicius e Felipe
Essa semana recebi algumas reclamações de usuários de que o sistema estava lento e observei que o I/O está muito alto e consequentemente o número de leituras físicas…
Recentemente precisei restaurar a base pelo import, e chequei alguns parametros mas não todos… lembro que tive um problema desse uma certa vez e a alteração desses parametros melhorou bastante a situação e lembro tb que o Hit sempre dava uma taxa de acerto maior que 90%
Para tentar minimizar esse I/O que estou tentando fazer esse ajuste do buffer_cache[/quote]@mpvargas,
Voce chegou a verificar os planos que o Oracle esta fazendo para estes selects? se esta havendo muito FTS? os index?
Use o autotrace em alguns desses selects e veja o plano que o oracle esta tomando, verifique tambem as estatisticas das tabelas estao em dia.
Lembre-se, execute o AWR para verificar.
Att,
20 de setembro de 2011 às 5:22 pm #100865mpvargas
ParticipanteVinicius,
estou acostumado a utilizar o ADDM e o ASH, mas o AWR eu nunca executei… como devo fazer?
Obrigado - PARAMETROS DE INSTANCE QUE, SE CONFIGURADOS ERRONEAMENTE CAUSAM FTS
-
AutorPosts
- Você deve fazer login para responder a este tópico.