mvmpedro 0 Denunciar post Postado Janeiro 24, 2006 E aí pessoal, tudo bom?! Estou tendo problemas com o Shared Server, segue o cenário:Máquina:HP RISC RP4440 - 4 CPU's 800Mhz - 8GB RAMSistema Operacional: HP-UX 11.11Quantidade de memória livre antes de iniciar o banco: 6133336K freeQuantidade de memória após iniciado o banco: 3284656K freeBanco sendo utilizado: Connected to:Oracle9i Enterprise Edition Release 9.2.0.6.0 - 64bit ProductionWith the Partitioning, OLAP and Oracle Data Mining optionsJServer Release 9.2.0.6.0 - ProductionAlguns parâmetros:sga_max_size = 3222765832 byteslarge_pool_size = 369098752 bytesshared_pool_size = 419430400shared_servers = 10max_shared_servers = 150shared_server_sessions = 165dispatchers = (protocol=TCP)(disp=1)(con=700)max_dispatchers = 4circuits = 170Nesse primeiro momento, terei no máximo 500 usuários conectados, a aplicação é PL/Web...não tem nada de Java. A string para conexão da aplicação está como shared, a conexão é feita através de um middle tier (Oracle Application Server), mas, isso indifere no resultado final. Pois via SQL*Plus o resultado é o mesmo.Quando executo uma procedure específica, conectado como shared o tempo para execução é de 45 segundos. Como dedicated vai para 10 segundos. Fiz o mesmo teste num servidor de aplicações de desenvolvimento que aponta para o banco, mudei a string de conexão e o resultado foi o mesmo:Dedicated = 10 segsShared = 45 segs.O Explain Plain é praticamente igual, não tem nada de diferente...Já fiz o teste alternando o número de shared_servers e dispatchers, mas o resultado foi o mesmo. Inclusive rodei scripts para monitorar o tempo de espera e performance dos shared_servers e dispatchers, o tempo de espera está mínimo...Todo o banco está perfeito, todas as procedures estão com ganho de desempenho em relação à máquina do projeto piloto (que é bem inferior à esta citada acima e que está com o banco em dedicated), exceto esta procedure...a única coisa que estou intrigado é em relação às global temporary tables em conjunto com o shared server, já que essa procedure acessa 3 tabelas temporárias...Do resto, não enxerguei algo que possa estar prejudicando tanto...AbraçosVinicius Compartilhar este post Link para o post Compartilhar em outros sites
alphamek 2 Denunciar post Postado Janeiro 24, 2006 Olá Marcus, O problema está somente nessa procedure mencionada, ou você percebeu lentidão na base inteira? O recurso de mémoria é normal, quando você inicia a instância, seu volume de mémoria irá diminuir mesmo, por causa do seu SGA alocado para o banco de dados. Porém, seu banco de dados está em RAC? Ou você configurou mesmo como shared na criação do banco! Isso é um "problema" legal, pois muitas pessoas dizem que quando se tem muitos usuários na rede, o idéal é projetar um banco SHARED, pois compartilha o SQL CACHE LIBRARY do SGA com os usuários, e percebeu que como DEDICATED é mais rápido, 3x mais. Mais vamos lá, alguns pontos que você pode levantar: Na procedure, veja : * As tabelas que estão acessando, e veja suas estatísticas. Caso seu optimizador esteja em CHOOSE ou CUSTO. * Veja se existe cursor, e veja como está sendo aberto. * Veja se existe índices nas tabelas com faça refinação dos dados. * Veja se está utilizando SQL dinâmico. Isso é um tuning em objeto, que talvez possa ajudar o andamento da procedure. Caso contrário, poste mais informações e tentamos fazer um tuning no banco. Abraços, http://forum.imasters.com.br/public/style_emoticons/default/joia.gif Compartilhar este post Link para o post Compartilhar em outros sites
mvmpedro 0 Denunciar post Postado Janeiro 24, 2006 Olá Rodrigo, sim, em relação à SGA eu sei, apenas expressei como exemplo para ver que os recursos estão disponíveis "em abundância". O problema está somente nessa procedure... O banco não está em RAC, quando ele foi criado, já foi criado como shared... Em relação ao objeto, veja, fiz duas experiências nessa base: 1) SQL*Plus, string=dedicated, tempo de execução: 10 segs; 2) SQL*Plus, string=shared, tempo de execução: 45 segs. O Explain Plan tanto no shared como no dedicated está igual! Vou explicar um pouco mais sobre o cenário... Atualmente o banco está como um piloto, com 50 clientes conectados, mas não nessa máquina, e sim numa outra máquina com configuração inferior, porém, o banco em dedicado. Essa máquina que passei a configuração no email anterior é a máquina que entrará em produção, com aproximadamente 300 usuários conectados... Fizemos testes em toda a base, comparando os resultados da base "piloto" que está em produção (que está como dedicated), com a base que está em homologação e logo entrará em produção (essa que está como shared), e, em todos os testes executados, a nova base (shared) foi mais performática do que a base atual (piloto)...exceto essa procedure. Por isso pergutnei se não pode ser algo com as 3 tabelas temporárias que ela acessa. Existe algum bug de tabelas temporárias com shared server?? Consegui ser claro? E antes de me despedir...eu sou o "mala" que te enche o saco de vez em quando no email, fiz aula no IBTA...lembra? Abraços Vinicius Olá Marcus, O problema está somente nessa procedure mencionada, ou você percebeu lentidão na base inteira? O recurso de mémoria é normal, quando você inicia a instância, seu volume de mémoria irá diminuir mesmo, por causa do seu SGA alocado para o banco de dados. Porém, seu banco de dados está em RAC? Ou você configurou mesmo como shared na criação do banco! Isso é um "problema" legal, pois muitas pessoas dizem que quando se tem muitos usuários na rede, o idéal é projetar um banco SHARED, pois compartilha o SQL CACHE LIBRARY do SGA com os usuários, e percebeu que como DEDICATED é mais rápido, 3x mais. Mais vamos lá, alguns pontos que você pode levantar: Na procedure, veja : * As tabelas que estão acessando, e veja suas estatísticas. Caso seu optimizador esteja em CHOOSE ou CUSTO. * Veja se existe cursor, e veja como está sendo aberto. * Veja se existe índices nas tabelas com faça refinação dos dados. * Veja se está utilizando SQL dinâmico. Isso é um tuning em objeto, que talvez possa ajudar o andamento da procedure. Caso contrário, poste mais informações e tentamos fazer um tuning no banco. Abraços, http://forum.imasters.com.br/public/style_emoticons/default/joia.gif Compartilhar este post Link para o post Compartilhar em outros sites
alphamek 2 Denunciar post Postado Janeiro 24, 2006 E ae Rapaz, Procurei pelo seu nome e ví os e-mails que trocamos, gostou dos cursos do IBTA? hehehehe.... Seguinte, vamos a suas dúvidas. O problema que talvez possa estar ocorrendo é em relação aos parametros de configuração do PGA e SGA, pois quando estamos trabalhando em SHARED SERVER, temos poucas processos do servidor, diferente do dedicado, e isso pode estar ocorrendo contigo. E como tu disse que está "pendendo" nas tabelas temporárias, possa estar com problemas de SORT_AREA_SIZE, SHARED_POOL_SIZE e LARGE_POOL_SIZE, como não uma aplicação JAVA, então não precisa mexer nos parametros dele. Aumente esses paramêtros e execute novamente a procedure, e veja os resultados. Antes, se utilizar o SQL*PLUS, grave o timing da cada execução para comparar posteriomente. Você verificou o tuning nos objectos e está tudo certinho!!! Abraços, http://forum.imasters.com.br/public/style_emoticons/default/joia.gif Compartilhar este post Link para o post Compartilhar em outros sites
mvmpedro 0 Denunciar post Postado Janeiro 24, 2006 E ae Rodrigo!Gostei dos cursos sim, o retorno foi rápido, 11 dias após terminar o "módulo" de Tuning já estava empregado...Bom:SHARED_POOL_SIZE = 400MLARGE_POOL_SIZE = 350M.O meu SORT_AREA_SIZE não está sendo usado. Já que estou usando os parâmetros PGA_AGGREGATE_TARGET com 100M e o parâmetro WORKAREA_SIZE_POLICY como AUTO.Os valores estavam anteriormente estavam em:SHARED_POOL_SIZE = 350M.LARGE_POOL_SIZE = 300M.PGA_AGGREGATE_TARGET = 70MLembrando que o problema de performance é apenas no SHARED_SERVER, e detalhe: por enquanto, só tem 1 usuário conectado! Mas como falei anteriormente, apenas essa procedure apresenta problema de performance...Já fizemos um stress teste na máquina com 100 usuários pendurados executando a mesma procedure (cada qual com seu valor é claro), e o tempo de execução foi o mesmo para todos: 45 segs.O resultado foi o mesmo! :o Abraços!Vinicius Compartilhar este post Link para o post Compartilhar em outros sites
mvmpedro 0 Denunciar post Postado Janeiro 25, 2006 Rodrigo, ontem você matou a charada! Bom, de acordo com o material oficial da Oracle, é dito que ao se usar o parâmetro PGA_AGGREGATE_TARGET com valor definido, junto com o WORKAREA_SIZE_POLICY como AUTO, os valores dos parâmetros *_AREA_SIZE são ignorados. Até aí tudo bem, nada de segredo, no entanto, no documento 223299.1 Subject: Top Oracle 9i init.ora Parameters Affecting Performance do Metalink, olha o que fala: "If PGA_AGGREGATE_TARGET is set in the init.ora and Dedicated Server connection is used, then SORT_AREA_SIZE, HASH_AREA_SIZE, BITMAP_MERGE_AREA_SIZE and CREATE_bitmap_AREA_SIZE are ignored. If Shared server connection is used then PGA_AGGREGATE_TARGET will be ignored and the *_AREA_SIZE parameter will take precedence. " Essa informação eu não havia encontrado em nenhum lugar da documentação (posso ter procurado mal...), mas pelo menos no material do curso não referencia nada... Bom, executei a procedure no shared server...o que demorava 45 segundos agora leva: Elapsed: 00:00:06.85 Bom, é isso, problema resolvido! http://forum.imasters.com.br/public/style_emoticons/default/clap.gif Obrigado! Abraços! Vinicius Compartilhar este post Link para o post Compartilhar em outros sites
alphamek 2 Denunciar post Postado Janeiro 25, 2006 Fala ae Rapaz.... Que bom que resolvemos o problema, quando trabalhamos em SHARED SERVER e temos aplicações envolvidas no ambiente, sempre devemos lembrar do PGA e quando for mais embaixo o problema, vericar o UGA. Agora sua base ficou um foguetinho.... depois tu me paga uma cerveja!!! hehehehehehe... Abraços, http://forum.imasters.com.br/public/style_emoticons/default/joia.gif Compartilhar este post Link para o post Compartilhar em outros sites
