Perfeito chiappa... Obrigadão pela ajuda...
O que fiz recentemente foi reduzir o tamanho da shared_pool pois, segundo recomendação de um Doc que estava lendo da Oracle, um oversize da shared_pool poderia piorar a situação (conforme vc havia dito). Tive uma melhora senssível, apesar de ainda sofrer com latchs...rs Vou continuar analisando... --- Em oracle_br@yahoogrupos.com.br, "jlchiappa" <jlchia...@...> escreveu > > Colega, vou aproveitar agora enquanto tou esperando um processamento, já que > ninguém te respondeu, vou tentar te dar algumas idéias, dicas e sugestões. > Primeiro, sobre a questão de se aumentar um recurso (SGA no seu caso, mas > seja qual for) e a performance piorar : isso é ** simples ** de entender e é > algo comum de se ver, ocorre basicamente quando a pessoa não entende que um > Sistema necessariamente é composto por VÁRIAS partes que interdependem, pra > vc melhorar a performance do sistema como um todo vc TEM QUE se assegurar que > ao aumentar a capacidade de um componente os OUTROS terão como provisionar os > recursos no mesmo nível. Deixe-me dar um exemplo mais simples,não é o seu > caso mas só para entender : digamos que num banco está sendo feito tanto I/O > que a capacidade do sub-sistema de I/O (ie, discos, controladoras, etc) tá no > limite. Aí, um gerentão qquer, um sem-noção técnica vem e fala : "ah, tá ruim > vamos enfiar mais memória RAM e CPUs aí dentro", o que acontece ? Esses > recursos a mais permitirão que MAIS programas rodem simultaneamente, esse > sistema faz muito I/O, aí serão MAIS programas pedindo pra ser servidor pelo > I/O , o I/O não consegue atender a todos, a ** FILA ** aumenta, mais caras > esperando por I/O numa fila maior significa que cada um vai ter q esperar > mais pra ser atendido, PRONTO, a performance capotou, aí (lógico) o sem-noção > vem e diz que a culpa foi do dba que não soube "configurar" o banco pra usar > a memória extra, afinal "todo mundo sabe que mais RAM significa mais > performance"... Já vi essa cena algumas vezes.... No seu caso > especificamenteao receber performance menor aumentando a SGA, duas coisas são > mais prováveis de ter acontecido : > > a) a SGA *** não é *** toda a memória que o banco oracle usa, em sendo > conexões dedicadas (o default) a cada vez que alguém conecta no banco ele VAI > criar uma área na memória VIVA, totalmente FORA DA SGA, a chamada PGA, além > do fato de criar também uma nova task no Sistema Operacional, que como qquer > programa vai exigir RAM para si - a suposição é que com 20 Gb de SGA ainda > sobrava RAM suficiente pra esses outros usos, com 24 usados na SGA começou a > faltar e o So começou a paginar mais intensamente, ou ainda pior, a usar swap > realmente > > ou > > b) necessariamente a SGA é usada para vários "caches" do sistema (ou > pools) : evidentemente, como o bd Oracle é MULTI-USUÀRIO de fábrica, ele sabe > que pode have alguém querendo gravar exatamente aquela posição em RAM que o > processo atual quer ler, então ** TODA ** a RAM compartilhável do bd Oracle é > protegida por latches. Devemos pensar nos latches como um bloqueio > temporário, uma "permissão de acesso", uma flag indicando "em uso" - assim, > se eu sou um processo no banco e quero ler a posição X da memória, eu NÂO > acesso diretamente x , E SIM uso uma API que consulta se X está marcado como > em uso, se não está eu "obtenho" o latch, marco que estou usando (isso é um > GET) , se não está eu tento de novo (isso é um MISSING), e se eu tentei > algumas vezes (esse processo de tentar várias vezes é o SPIN) e não consegui, > vou "dormir" por uns tempos (é o evento de SLEEP) e depois tento de novo, até > conseguir - isso é bem diferente do LOCK propriamente dito, aonde fico > PARALISADO até quem está usando o recurso (normalmente um registro) deixar de > usar : vc acha as estatísticas TODAS de gets/misses/sleeps nas views > v$latchqquercoisa do banco, yes ? > Muito bem, esse processo de controle de RAM é rápido MAS não é > desprezível, ele CONSOME CPU sim, aí vem a possibilidade : se vc já está > starvado em CPU (por causa de SQLs malfeitos/dinâmicos, talvez até sem bind), > ao aumentar a SGA vc aumentou a quantidade de latches necessários para a > usar, passou a tentar consumir mais CPU que já era escassa, BUM, a > performance vai pro chão... > > Então o resumo da ópera é : ANTES de sair aumentando recursos vc TEM QUE > descobrir aonde está o gargalo e o corrigir (seja aumentando a capacidade, > seja usando de modo mais inteligente o que vc já tem),ok ? > > Sobre os SQL dinâmicos e mau uso : isso é um BUG, é um mau comportamento do > sistema, não há como no banco vc querer corrigir algo que é externo, ok ? O > que fazer ? Veja, imagine que o bug fosse que ele faz um conta errada, um > determinado resultado fica negativo , o que vc faria é contatar fornecedor e > demandar um patch, certo ? Vc até poderia, como PALIATIVO enquanto não vem o > patch, digamos escrever um SQL que multiplicasse por -1 os resultados se > livrando do negativo, mas isso é um remendão, que PODE ter efetos nocivos, > tipo, o fornecedor ter uma rotina que também mexa nos resultados aí vem a sua > e mexe também, sabe-se lá... OK, o fornecedor (como a maioria deles) não dá > pelota pra tua Empresa depois da venda feita ? Tá, mas se vc não reclamar, aí > que o bug nunca é corrigido mesmo, concorda ? Como resonsável pelo banco, a > tua função é registrar isso ** E ** deixar clara, POR ESCRITO, a sua posição > pro teu chefe, até que ele mesmo pessoalmente se envolva na conversa com o > fornecedor, fazendo umas ameaças comerciais, não tem outro jeito.. Pra bugs > de SQL é a mesma coisa, até há alguns remendos que vc pode tentar (como > programaticamente esvaziar o cache de SQLs, e/ou tentar setar o autobind com > CURSOR_SHARING , e/ou tentar aumentar os parâmetros internos que controlam > quantidades e spins de latches, entre outros), mas TODOS esses são REMENDÕES > , coisas feias que a qquer momento podem cair/quebrar, há/podem haver efeitos > coletarais *** MUITO SÉRIOS *** não só de performance quanto de Estabilidade > com tais procedimentos, antes de usar qquer um deles vc TEM QUE ter o > respaldo de um Camado no Suporte Oracle e TEM que já ter demandado correções > do fornecedor... > Menos sérios (mas às vezes menos efetivos) são os acertos de plano de > execução de SQL malfeitos que vc pode fazer no banco, mesmo sem ter o código > fonte da aplicação, são eles : > > a) renomear a tabela original para xyz, e ter uma view (com HINTs e/ou > re-escrita de SQL), criada com o nome da tabela original e consultando a xyz > > b) criar um pool keep com algumas tabelas muito usadas mas não tão grandes > > c) SQL Outlines > > d) SQL Profiles > > e) triggers de conexão que façam via ALTER SESSION alterações de ambiente, > principalmente nos parâmetros de CBO > > f) alterações no modelo , como criação de índices mais especializados, > recriação (com compactação e/ou remoção de white space, ou mesmo > defragmentação) de tabels/índices, adição de views materializadas, etc > > Claro que nem sempre são possíveis/viáveis (principalmente o que implica > mexer no modelo lógico/físico original da Aplicação), E que certamente eles > serão perdidos (e terão que ser refeitos) no próximo patch/release que o > Fornecedor mandar, mas é isso. > > []s > > Chiappa > --- Em oracle_br@yahoogrupos.com.br, "candiurudba" <candiurudba@> escreveu > > > > Bom dia colegas, > > > > Algum tempo atras postei algumas dúvidas com relação aos latchs que estou > > tendo na Library Cache e sabemos que os mesmos tem haver com as querys > > dinamicas que estão sendo executadas. > > > > O meu grande problema em solucionar definitivamente este problema, é que as > > aplicações que são executadas são de terceiros. > > > > Minha dúvida é a seguinte, s eeu aumentasse o tamanho da Shared Pool, como > > consequencia, a da Library Cache, este problema não > > seria..digamos...solucionado paliativamente ? > > > > Pq, percebi que antigamente, trabalhando com 20G para a SGA, tinha uma > > performance muito melhor do que hoje em dia, trabalhando com 24G...esta > > relação de aumento da SGA X Performance me intriga um pouco.... > > > > alguem tem alguma ideia ? > > >
