Chiappa,
Muito obrigado pela resposta, que na verdade foi de super alto nível. O meu grande problema está referente ao DB Link citado por você, dá maneira que construíram a arquitetura da aplicação. Sendo que tenho dois Database A e B, onde acesso os mesmos através de DB Link, a única coisa é que os dois estão instalados no mesmo banco de dados Oracle 10g, o que me intriga o porque não fizeram dois tablespace , desta forma não precisaríamos ter o dblink é a consulta seria sem dúvidas muito mais rápido. O problema foi causado talvez por falta de conhecimento da equipe anterior, pois como estamos falando do mesmo Database, poderiamos estar criado apenas tablespace e usuários diferentes para cada banco. De qualquer forma obrigado pelas dicas anteriores. Abraços, Vitor Hugo Brito de Oliveira Decimal Tecnologia Em Informatica LTDA. BLOG: http://emdia.wordpress.com/ MSN: hugov1...@hotmail.com ________________________________ De: José Laurindo <jlchia...@yahoo.com.br> Para: oracle_br@yahoogrupos.com.br Enviadas: Quinta-feira, 18 de Agosto de 2011 21:32 Assunto: [oracle_br] Re: Medir desempenho de banco Oracle A guia geral é vc verificar a Eficiência dos seus SQLs : quando eu disse "SQL mal escrito", não quis dizer SQL que não segue um "padrão", nem SQL que segue ou não segue uma determinado sintaxe, eu queis me referir a SQLs ineficientes... Pra vc verificar a eficiência dos seus SQLs, há basicamente 3 coisas a se fazer : a) conferir quantos LIOs (Logical I/Os. ie, quantos blocos Oracle) são acessados pra se produzir as linhas-destino : em caso de acesso sequencial via índice o ideal é se ter uma proporção por volta de 6 LIos por linha (digamos, um LIO pra se ler o root block do índice, um pra se ler o branch, outro pra se ler o leaf, mais um pra se obter o bloco de dados, com uma adiçãozinha de margem chegamos nos 6 LIOs), enquanto no caso de fast full index scan/table scan aí (claro) não dá pra saber onde os dados vão estar (pode ser que vc tenha ler a tabela inteira pra achar um dado), então não se pode estabelecer uma escala , mas o fato é , vc TEM que reduzir ao máximo os LIOs , portanto em caso de scan vc TEM que se assegurar que não há white-space sem dados sendo lido, que o high-water mark não esteja absurdamente alto, que as opções de Redução de LIOs em scans (como Particionamento, por exemplo) estão presentes e sendo usadas... Em caso de scan ainda há a questão de se assegurar I/O otimizado, o que implica em tamanho de extent aproipriado, db_file_multiblock_read_count (se viável) bem ajustado, etc... b) WAITs : todo SQL, óbvio, tem algum tipo de WAIT, o objetivo nesta verificação é não ter nada absolutamente desbalanceado , nenhum wait que sozinho responda por uma percentagem significativa do total, SE houver isso deve ser corrigido / melhorado... c) consumo de recursos : todo SQL consome alguma CPU, algum I/O, implica em algum nível de tráfego de rede, pode sofrer/participar de concorrência outras sessões querendo acessar os exatos mesmos blocos que o seu SQL tá usando/querendo usar) ... Aqui novamente não há um número ideal, o objetivo é ter o menos possível de consumo, E evitar o desperdício... Exemplos típicos de desperdício são SQLs sendo reparseados frequentemente (o que gasta cliclos e ciclos de CPU à toa), montes de SQLs semelhantes sendo gerados por não-uso de BIND VARIABLEs, a mesma informação sendo lidas várias vezes (por exemplo, em sub-queries), coisas assim... Tools : para a) e b) a tool é o TKPROF em cima de um trace de SQL. Para c) pode-se usar a V$SQL e as V$ de eventos de performance da sessão, mas não há um método único pra isso, a idéia é que um DBA ** experiente ** consulte as V$ necessárias (principalmente a V$SQL, ela tem colunas aonde se registram consumo de CPU, concorrência, LIOs, linhas processadas, etc) e também revise os planos (planos reais, extraídos da V$SQL_PLAN e similares, não estimadas com EXPLAIN) - uma pessoa experiente, E que conheça o negócio/saiba o que o SQL deveria produzir, só de olhar um plano já pode avaliar algo da eficiência dele : por exemplo, SQL usando nested loops num JOIN aonde se sabe que as tabelas envolvidas são "grandes" provavelmente pode ser substituído com vantagem por um HASH, coisa do tipo... Referência : eu DESCONHEÇO um documento apropriado pra isso, o que vc poderá usar são : - manuais Oracle Concepts e Tuning - livro "Oracle SQL High-Performance Tuning (2nd Edition)", Guy Harrison : fala bastante sobre análise de TKPROF e algoritmos de JOIN - livro "Cost-Based Oracle Fundamentals (Expert's Voice in Oracle)", de Jonathan Lewis : nos releases modernos, já há vários anos o Oracle usa otimização por Custo (baseada em coleta de estatísticas e Histogramas) para otimização de SQLs, este livro é o melhor para referência nesse assunto - livro "Oracle Wait Interface: A Practical Guide to Performance Diagnostics & Tuning", de Richmond Shee, Kirtikumar Deshpande and K Gopalakrishnan : ref para item c) - livro "Expert Oracle Database Architecture: Oracle Database 9i, 10g, and 11g Programming Techniques and Solutions", de Thomas Kyte : este é para re-escrita dos SQLs , mostra diversos recursos/features do banco de dados Oracle que vc pode usar nos seus SQLs / no seu database para reduzir LIOs []s Chiappa OBS : um ponto adicional Importante, o DBA experiente que for rever os SQLs vai ser capaz também de identificar as "besteiras" lógicas e/ou de implementação : por exemplo, trazer dados via dblink, é ululantemente óbvio, implica em montes de tráfego de rede, com absoluta certeza seria MUITO mais econônimo para o servidor se os dados viessem todos de uma vez do banco remoto e fosse armazenados localmente, aí quando mais tarde o relatório precisar é só leitura local, sem grandes tráfegos.... Outra inhaca típica, imagine um relatório aonde seja preciso fazer contagem , ou soma, ou agrupação de uma enorme quantidade de registros (típico de relatórios gerenciais) : é asnino se forçar o coitado do usuário a esperar o SUm ou o COUNT ou o GROUP serem executados a cada vez : MUITO melhor seria vc já ter o valor da soma/contagem o que for já feito ANTES, aí o relatório só o lê.... Cisas assim... --- Em oracle_br@yahoogrupos.com.br, Vitor Hugo <hugov_br@...> escreveu > > Chiappa, > > > Tenho certeza que os SQL estão bem escritos, mais acredito que então tenha um > documento que possa me auxiliar a conferir os meus SQLs novamente. > > Será que você teria algum documento que poderia me auxiliar nesta questão. > > Abraços, > > Vitor Hugo Brito de Oliveira > Decimal Tecnologia Em Informatica LTDA. > BLOG: http://emdia.wordpress.com/ > MSN: hugov1983@... > > > ________________________________ > De: José Laurindo <jlchiappa@...> > Para: oracle_br@yahoogrupos.com.br > Enviadas: Quinta-feira, 18 de Agosto de 2011 14:07 > Assunto: [oracle_br] Re: Medir desempenho de banco Oracle > > > > Colega, seguinte : primeiro de tudo, existem sim diversas tools e referências > pra vc fazer verificação do cluster (no metalink, o site de Suporte da > Oracle, indico as notas "Introducing Cluster Health Monitor (IPD/OS)" (Doc ID > 736752.1) , "RAC Assurance Support Team: RAC and Oracle Clusterware Starter > Kit and Best Practices (Generic)" (Doc ID 810394.1) e a "RAC: Frequently > Asked Questions" (Doc ID 220970.1) , bem como os links citados nelas, mas > tenha Claro em mente que NENHUMA dessas tools/técnicas é point-and-click e > cabou, vai ser sim TOTALMENTE EXIGIDO um DBA Oracle ** experiente ** para as > aplicar, okdoc ?? > > Quanto à outra pergunta : a adição de um outro nó implica em um pouco mais > de poder de CPU e em mais RAM pro cluster (no RAC cada cache de cada nó se > junta para formar um só cache, logicamente falando, através do cache fusion > ), além de vc poder aliviar um pouco a carga dos outros nós com o load > balance tendo mais um destino a balancear - então é claro que só vai ser > benéfica a adição de um novo nó SE, e APENAS SE, o problema com os teus > relatórios é consumo de CPU ou máquina muito acessada ou coisa do tipo : SE o > problema nos seus relatórios for SQL malfeito/porcamente escrito, fazendo > I/Os em excesso ou coisa do tipo, não vai ajudar EM NADA um nó a mais, muito > provavelmente.... > > ==> Então a minha Recomendação é lapidar : faça o healthcheck do seu cluster, > ok, e do banco também (não é de forma alguma tempo perdido), MAS > NECESSARIAMENTE um DBA experiente vai ter que além disso analisar os SQLs / > sessões dos tais relatórios e ver qual é o gargalo, qual é o problema, blz ?? > > > []s > > Chiappa > > --- Em oracle_br@yahoogrupos.com.br, Vitor Hugo <hugov_br@> escreveu > > > > Bom dia a todos, > > > > Estou tendo alguns problemas de performance no meu banco de dados produtivo. > > > > O meu banco de dados tem 2 nós , eu gostaria de saber como descobrir seu meu > > Oracle RAC está configurado corretamente, e quais seriam os processos ou > > documento > > disponiveis na Oracle que poderiam me ajudar, com o diagnostico de > > problemas. > > > > Se eu acrescentar mais um nó ao meu Oracle RAC, quais seriam os beneficios > > que eu > > poderia obter no tempo de resposta dos meus relatórios. > > > > Abraços, > > > > Vitor Hugo Brito de Oliveira > > Decimal Tecnologia Em Informatica LTDA. > > BLOG: http://emdia.wordpress.com/ > > MSN: hugov1983@ > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > [As partes desta mensagem que não continham texto foram removidas]
