- Este tópico contém 8 respostas, 3 vozes e foi atualizado pela última vez 14 anos, 1 mês atrás por vieri.
-
AutorPosts
-
16 de julho de 2010 às 6:41 pm #95085brunopbParticipante
Caros amigos,
Possuo uma tabela pequena de 50.000 linhas e 40M de espaço, porém 80% das funcionalidades do sistema acessam essa tabela…
estou tendo varios problemas de waits de concorrencia e I/O… ja diagnostiquei varios hot blocks…. a tabela já está em ASSM…
daí pensei… como a table é pequena porque não colocar ela fulltime em memória? isso evitaria esses I/O constantes…
ja aumentei a shared pool para armazenar mais sql em memoria… mas nao funcionou… e minha shared pool está com 50% cheia só
usei o comando alter table XXX CACHE para ver se funciona… mas nao mudou nada…
o que posso fazer?
16 de julho de 2010 às 8:25 pm #95087vieriParticipanteColocar a tabela no modo cache não garante que seus dados fiquem no buffer_cache(não entendi pq vc mecheu na shared_pool),
pois o oracle apenas marca as linhas como recentes e se houver novas requisições elas irão saindo da fila do cache.Coloque está tabela em uma tablespace só pra ela em uma outra área do disco , faça o rebuild dos indices dela, e com relação a concurrency qual wait vc observou.. dependendo de qual for vc deverá aumentar o buffer_cache.
este link tem um bom conteúdo.
http://download.oracle.com/docs/cd/B141 … memory.htm16 de julho de 2010 às 11:33 pm #95089brunopbParticipantemexi na shared pool pq confundi achando que a buffer_cache pertencia a shared_pool… fiz besteira, tanto que nao alterou em nada o resultado. vc ta
certoja criei outra tbs pra essa table… mas esse servidor nao possui outros hds.. nao rodei o rebuil mas rodei um DBMS_STATS.GATHER_SCHEMA_STATS que atualiza todos os indices… ainda preciso de um rebuild?
os waits q vi foram muitos i/o de disco e latch free
vou ler o material e obrigado pela ajuda
17 de julho de 2010 às 12:28 am #95091vieriParticipanteIO de disco mas latch free….
🙄isso está tendendo a SGA pequena.
Cara coloca a SGA no automático (SG_TARGET) deixa que o oracle configura pra vc ,
e coloque o máximo de SGA que o servidor aguentar se for 64bits
se for 32bits complica.O gather schema eu nem comentei pq isso deve ser padrão,
agendado no S.O e rodar toda noite.O rebuild é uma maneira de tentar melhorar seu I.O.
17 de julho de 2010 às 12:32 am #95092vieriParticipanteoutra coisa importantíssima… chegou a olhar a query/processo
que está recebendo estes wait’s !”?17 de julho de 2010 às 1:08 am #95097David SiqueiraParticipanteBruno, dá uma olhadinha aqui nessas considerações que um colega colocou aqui mesmo no GPO :
[url]https://profissionaloracle.com.br/blogs/antoniodba/2009/10/01/ajustes-de-memoria-shared-pool/[url]
Se ainda persistirem dúvidas manda pra gente.
Abração[/url]
17 de julho de 2010 às 1:10 am #95098brunopbParticipanteoi, olhei sim a query… é uma consulta WITH com varias subquerys na mesma tabela… re-escrever a query nesse momento não é uma opção mas quando as coisas acalmarem é uma boa
vc ta certo, minha SGA estava em 250M aumentei para 400M e melhorou bastante… infelizmente nao posso colocá-la no talo porque essa maquina eh compartilhada com 1000000 de outras coisas…
servidor de email, 2 instancias oracle, 4 bases postgresql, apache, php e pra piorar é uma maquina virtualizada!!!
o HW da maquina é xeon biprocessado 64bits, com 3G ram e 1 HD só de 150G
enfim… acho uma maquina horriiivel
nao coloco o sga_target = auto pq tenho medo do oracle puxar a memoria toda !! rsrs
17 de julho de 2010 às 3:45 pm #95102David SiqueiraParticipanteThats a beautifull problem…rsrs se precisar vamos falando brother. Abraço
19 de julho de 2010 às 9:13 pm #95118vieriParticipanteO Oracle não irá “puxar” sua memória toda
para isso existe o parâmetro SGA_MAX_SIZE
coleque para o mesmo valor do SGA_TARGET.
😉Mas já que com o aumenta da SGA melhorou, acho que seu problema
é falta de recurso computacional mesmo. -
AutorPosts
- Você deve fazer login para responder a este tópico.