SE essas tablespaces forem criadas nos mesmos discos de hoje, atendidos pelo mesmo exato hardware que não está dando conta e fazendo os mesmos exatos I/Os na mesma quantidade, É Claro que não dar diferença alguma de performance, isso é Acadêmico... As tablespaces são um instrumento muito mais de Administração, com elas vc consegue agrupar datafiles a recuperar, fazer transportes de dados, coisas assim, mas para performance são basicamente indiferentes...
[]s Chiappa --- Em oracle_br@yahoogrupos.com.br, "julianomartinez" <juliano@...> escreveu > > > Obrigado pela resposta, Chiappa. > Vou ler a nota do Metalink e aumentar meu conhecimento nessa questão de Waits > devido I/O. > > Foi possível monitorar, que essa queda na performance e registro dos Warnings > no arquivo de trace, tem ocorrido somente quando dois processos do ERP são > executados de forma paralela (quase nunca ocorrem em paralelo, porém nessas > últimas duas semanas fez-se necessário). > > Ambos os processos realizam INSERT/UPDATE em tabelas que estão na mesma > TABLESPACE (tabelas com aproximadamente 5 milhões de registros cada). > > Minha dúvida, caso eu venha a separar essas tabelas em tablespaces > diferentes, posso ganhar em performance ao executar esses dois processos de > forma simultânea?? > > Agradeço as Respostas, > Juliano > > > --- Em oracle_br@yahoogrupos.com.br, "J. Laurindo Chiappa" <jlchiappa@> > escreveu > > > > Bem, essa feature de avisar se um I/O de tamanho determinado demora mais > > de 500 ms foi introduzida iirc no 10.2.0.4 , e não me lembro de > > bug/correção para alguma issue com ela no 10.2.0.5 : dá um look no README > > do 10.2.0.5 para confirmar, E considere muito cuidadosamente a > > possibilidade de aplicar pelo menos o 10.2.0.5 (mais por causa de outros > > bugs, que INDIRETAMENTE poderiam interferir na performance do I/O de modo > > geral e TALVEZ se relacionar com a sua issue)... > > Porém, não dá pra negar que MUITO PROVAVELMENTE vc está enfrentando > > baixa disponibilidade do I/O , seja por overhead de I/O , seja por hardware > > não sendo capaz de atender a demanda, seja por má > > performance/má-configuração : a nota metalink "Troubleshooting I/O-related > > waits" (Doc ID 223117.1) será a tua referência.... > > > > []s > > > > Chiappa > > > > --- Em oracle_br@yahoogrupos.com.br, "julianomartinez" <juliano@> escreveu > > > > > > Pessoal, > > > > > > Minha base de dados de produção tem apresentado desde o último dia > > > 14/10/2013 as seguintes mensagens de trace no arquivo > > > producao_lgwr_708.TRC. Com uma média de 3 mensagens por hora. > > > > > > Maximum redo generation record size = 156160 bytes > > > Maximum redo generation change vector size = 150676 bytes > > > *** 2013-10-23 08:02:01.100 > > > Warning: log write time 580ms, size 1KB > > > *** 2013-10-23 08:13:03.385 > > > Warning: log write time 2730ms, size 10KB > > > *** 2013-10-23 08:28:24.849 > > > Warning: log write time 600ms, size 4KB > > > > > > Nesse mesmo tempo, alguns usuários do sistema que executam rotinas que > > > envolve bastante escrita no BD, reclamaram que os processos estão muito > > > mais demorados do que o normal. > > > > > > Gerei um relatório do STATSPACK no mesmo período dos Warnings relatados > > > acima. > > > > > > Top 5 Timed Events > > > ~~~~~~~~~~~~~~~~~~ > > > Event Waits Time (s) > > > -------------------------- -------- -------- > > > db file scattered read 215,607 1,452 > > > CPU time 583 22.0 > > > db file sequential read 43,747 492 > > > log file parallel write 7,144 31 > > > log file sync 6,174 23 > > > > > > Sistema Operacional: Windows Server 2008 Standard - 64 bits > > > Oracle: Oracle 10g - 10.2.0.4 - 64 bits > > > > > > Gostaria da ajuda do pessoal do fórum, pois não tem nenhuma mensagem > > > anormal no alert.log e não sei o que poderia fazer. > > > > > > Agradeço qualquer informação. > > > > > > Atenciosamente, > > > Juliano > > > > > >
