Aproveitando a viagem... tenho um cliente com sérios problemas de bind variables... alguém passou por isso já?? usou exact? similar? force?
----- Original Message ----- From: Marcelo To: oracle_br@yahoogrupos.com.br Sent: Thursday, September 11, 2008 1:21 PM Subject: RES: [oracle_br] Re: statspack - estatistica - Sistema Lento - HELP Caso seja Microsiga a sua aplicação de terceiros, já que é o TopConnect que faz o DML no banco, sugiro fazer um teste com o CURSOR_SHARING=FORCE. Existe uma diferença gritante entre usar FORCE e EXACT, pois a quantidade de SQL´s repetitivos é inexplicável. At; Marcelo Alberto Lauschner Desenvolvimento de Sistemas Auto Pratense Ltda * - Fone: (0XX54) 3242-3620 * - Fax: (0XX54) 3242-3648 * - E-mail: <mailto:[EMAIL PROTECTED]> [EMAIL PROTECTED] * - WWW: www.autopratense.com.br <http://www.autopratense.com.br/> _____ De: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em nome de jota_lvaz Enviada em: quinta-feira, 11 de setembro de 2008 13:01 Para: oracle_br@yahoogrupos.com.br Assunto: [oracle_br] Re: statspack - estatistica - Sistema Lento - HELP Alguém poderia me afirmar se cursor_sharing=similar é prejudicial ? Falo isto, pois percebi quando estava com a opção exact, tinha problemas sérios pela má utilização ou ausência de bind variables. O detalhe é que a aplicação é terceirizada. Abs --- Em [EMAIL PROTECTED] <mailto:oracle_br%40yahoogrupos.com.br> os.com.br, Anderson Haertel Rodrigues <[EMAIL PROTECTED]> escreveu > > Jota, > > Vou partir que o teu banco está Ok (bem dimensionado/Tunado) no que diz respeito a SGA/PGA. Certo? Caso contrário, reveja teus valores que eles podem estar ocassionando os waits mostrados abaixo. > > Agora, se eles estiverem ok, eu pensei num 1o momento da aplicação mal comportada, isto é, sem uso de bind variable. Neste caso, eu faria um teste modificando o parâmetro cursor_sharing. > > Sobre SQL*Net break/reset to client, segue um link legal: > http://blog. <http://blog.tanelpoder.com/2008/04/10/sqlnet-breakreset-to-> tanelpoder.com/2008/04/10/sqlnet-breakreset-to- client/#more-65 > > Saudações, > > Anderson Haertel Rodrigues > Administrador de Banco de Dados - DBA > Florianópolis/SC > > --- Em ter, 2/9/08, jota_lvaz <[EMAIL PROTECTED]> escreveu: > > > De: jota_lvaz <[EMAIL PROTECTED]> > > Assunto: [oracle_br] statspack - estatistica - Sistema Lento - HELP > > Para: [EMAIL PROTECTED] <mailto:oracle_br%40yahoogrupos.com.br> os.com.br > > Data: Terça-feira, 2 de Setembro de 2008, 14:29 > > Na empresa rodamos com aplicações terceirizadas e o meu > > relatório de > > Top 5 > > apresenta este formato > > > > Instance Efficiency Percentages (Target 100%) > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Buffer Nowait %: 100.00 Redo NoWait %: 100.00 > > Buffer Hit %: 99.26 In-memory Sort %: 100.00 > > Library Hit %: 99.15 Soft Parse %: 98.92 > > Execute to Parse %: 50.74 Latch Hit %: 99.95 > > Parse CPU to Parse Elapsd %: 51.40 % > > Non-Parse CPU: 90.85 > > > > Top 5 Timed Events > > ~~~~~~~~~~~~~~~~~~ > > % Total > > Event Waits Time (s) Ela > > Time > > CPU time 3,076 > > 46.67 > > SQL*Net break/reset to client 707,052 1,447 > > 21.96 > > library cache pin 746 454 > > 6.89 > > db file sequential read 383,000 240 > > 3.64 > > log file sync 8,804 230 > > 3.50 > > > > Na questão library cache pin, será que o aumento da > > Shared pool > > resolveria. O que me apresenta é um alto número de > > PARSES. Esse fato > > pode estar ocasionando um aumento de consumo de CPU (CPU > > time). > > > > O log file sync, não sei se é o caso de commits > > excessivos. Agora o > > SQL*Net break/reset to client, não sei como resolver. > > > > Gostaria de uma ajuda de vcs. O detalhe é que os softwares > > são > > terceirizados. Outro fato a ser colocado é que a > > ferramenta htop > > apresenta um consumo de memória baixo e alguns picos de > > CPU. > > > > Minha versão é Oracle 9.2.0.4 e o OS é o Red Hat > > Enterprise versão 4. > > > > Agradeço a atenção > > > > > > > > > > ------------------------------------ > > > > ---------------------------------------------------------- -------------------------------------------------------- > > >Atenção! As mensagens do grupo ORACLE_BR são de > > acesso público e de inteira responsabilidade de seus > > remetentes. > > Acesse: > > http://www.mail- <http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/> archive.com/oracle_br@yahoogrupos.com.br/ > > ---------------------------------------------------------- -------------------------------------------------------- > > >Funções, Procedures, propostas de emprego - O GRUPO > > ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE: > > http://www.oraclebr <http://www.oraclebr.com.br/> .com.br/ > > ---------------------------------------------------------- ------------------------------------------------------ > > Links do Yahoo! Grupos > > > > > Novos endereços, o Yahoo! que você conhece. Crie um email novo com a sua cara @ymail.com ou @rocketmail.com. > http://br.new. <http://br.new.mail.yahoo.com/addresses> mail.yahoo.com/addresses > [As partes desta mensagem que não continham texto foram removidas] __________ Informação do NOD32 IMON 3433 (20080910) __________ Esta mensagem foi verificada pelo NOD32 sistema antivírus http://www.eset.com.br [As partes desta mensagem que não continham texto foram removidas]
