RE: [oracle_br] RAC x ERP
Marcos boa tarde!! O primeiro problema detectado foi na camada de transporte, entre o listener e o tcp/ip. Segundo documento encontrado esse problema é aleatório, mas mesmo assim vi que alguns parâmetros de tcp/ip não estavam de acordo com as melhores práticas, o que estou alterando para reiniciar o ambiente e testar. Outro problema que estou encontrando é com o enterprise manager. Não estou conseguindo subi-lo, ja reconfigurei com o emca, mas na hora de acessar via browser não entra. Saberia me dizer o pq de não estar conseguindo acessar o banco via enterprise manager. abraço. To: oracle_br@yahoogrupos.com.br From: braga.mar...@gmail.com Date: Mon, 10 May 2010 10:32:07 -0300 Subject: Re: [oracle_br] RAC x ERP Olá Orfeu, Tempos atrás trabalhei com um ERP que era genérico, tipo..., para qualquer banco de dados..., isso é um tiro-no-pé. O principal problema desse ERP específico e genérico era, para toda e qualquer consulta que ele fazia, ocorria um FULL TABLE SCAN, criando uma tabela TEMPORÁRIA e depois são criados índices e aplicados os filtros (muitas vezes no terminal do próprio cliente da consulta) e por último (e não menos importante), um DROP nessa tabela TEMPORÁRIA. O pior é que para o caso da tal tabela TEMPORÁRIA, ela não estava em uma TEMPORARY TABLESPACE, estava em uma tablespace física, pois o ERP não saberia trabalhar com uma TEMPORARY TABLESPACE, porque é genérico. Observou o processo Cara..., quem idealizou o ERP se preocupou em deixá-lo genérico fazendo essa cáca genérica..., em ambientes corporativos, onde há redundância e segurança para não perder dados, isso é a morte. A vantagem é que funciona com a maioria dos bancos efetuando-se poucas alterações. Esse foi um caso específico de um ERP específico..., depois de muita análise descobrimos como o ERP trabalhava, gerando esse número enorme de DML no banco; nesse período haviam muitos problemas de performance no banco. Uma das soluções aplicadas na época foi: criar uma tablespace em nologging (uma tentativa de evitar gerar redo de tabelas temporárias, para o ERP). Depois aumentamos o cache para DML, o que melhorou um pouco também esse trabalho. Um segundo procedimento foi buscar os departamentos que faziam as consultas mais pesadas e disponibilizar computadores melhores, porque parte do processamento da consulta estava no cliente e não no servidor. Como pode observar, estes foram alguns aspectos que buscamos para solucionar o problema para este ERP genérico. Isso é só uma experiência para ajudar a buscar soluções. []s Braga Em 10 de maio de 2010 09:48, orfeu lima orfe...@hotmail.com escreveu: Bom dia a todos!! Tenho um oracle rac com dois nós, sistema operacional Linux Red Hat 5, oracle 10Gr2. Esse ambiente é acessado por um erp que está com sérios problemas de performance. Nesse ambiente tem-se 5 instâncias. Gostaria de saber quais os principais problemas do erp com rac e o que poderia estar modificando de cara nesse ambiente para poder melhorá-lo. Obrigado [As partes desta mensagem que não continham texto foram removidas] _ DEIXE SUAS CONVERSAS MAIS DIVERTIDAS. TRANSFORME AQUI SUAS FOTOS EM EMOTICONS, É GRÁTIS. http://ilm.windowslive.com.br/?ocid=ILM:ILM:Hotmail:Tagline:1x1:Tagline [As partes desta mensagem que não continham texto foram removidas] -- 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-archive.com/oracle_br@yahoogrupos.com.br/ -- Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » Procedure » Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE: http://www.oraclebr.com.br/ Links do Yahoo! Grupos * Para visitar o site do seu grupo na web, acesse: http://br.groups.yahoo.com/group/oracle_br/ * Para sair deste grupo, envie um e-mail para: oracle_br-unsubscr...@yahoogrupos.com.br * O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
Re: [oracle_br] RAC x ERP
Oi Orfeu, Na versão 10, quando reinstalava o EM, geralmente, ele não subia de primeira e acabava dando algum erro que não encontrava solução. Mas, milagrosamente, após uns 5 minutos ele estava ON; e só Deus sabe como isso ocorria. Eu só descobria utilizando o seguinte comando: # netstat -ltn GOTCHA! tava lá a porkera da porta 1158 aberta, aguardando conexões. Bom..., alternativamente, sempre consultava os logs para saber o que estava ocorrendo, alguns problemas descobri consultando os logs; é um bom começo. Primeiramente aconselho verificar se a porta abre após uns 5 minutos que tentou subir o serviço; Segundamente (r), aconselho verificar o log do EM. []s Braga Em 13 de maio de 2010 14:48, orfeu lima orfe...@hotmail.com escreveu: Marcos boa tarde!! O primeiro problema detectado foi na camada de transporte, entre o listener e o tcp/ip. Segundo documento encontrado esse problema é aleatório, mas mesmo assim vi que alguns parâmetros de tcp/ip não estavam de acordo com as melhores práticas, o que estou alterando para reiniciar o ambiente e testar. Outro problema que estou encontrando é com o enterprise manager. Não estou conseguindo subi-lo, ja reconfigurei com o emca, mas na hora de acessar via browser não entra. Saberia me dizer o pq de não estar conseguindo acessar o banco via enterprise manager. abraço. To: oracle_br@yahoogrupos.com.br From: braga.mar...@gmail.com Date: Mon, 10 May 2010 10:32:07 -0300 Subject: Re: [oracle_br] RAC x ERP Olá Orfeu, Tempos atrás trabalhei com um ERP que era genérico, tipo..., para qualquer banco de dados..., isso é um tiro-no-pé. O principal problema desse ERP específico e genérico era, para toda e qualquer consulta que ele fazia, ocorria um FULL TABLE SCAN, criando uma tabela TEMPORÁRIA e depois são criados índices e aplicados os filtros (muitas vezes no terminal do próprio cliente da consulta) e por último (e não menos importante), um DROP nessa tabela TEMPORÁRIA. O pior é que para o caso da tal tabela TEMPORÁRIA, ela não estava em uma TEMPORARY TABLESPACE, estava em uma tablespace física, pois o ERP não saberia trabalhar com uma TEMPORARY TABLESPACE, porque é genérico. Observou o processo Cara..., quem idealizou o ERP se preocupou em deixá-lo genérico fazendo essa cáca genérica..., em ambientes corporativos, onde há redundância e segurança para não perder dados, isso é a morte. A vantagem é que funciona com a maioria dos bancos efetuando-se poucas alterações. Esse foi um caso específico de um ERP específico..., depois de muita análise descobrimos como o ERP trabalhava, gerando esse número enorme de DML no banco; nesse período haviam muitos problemas de performance no banco. Uma das soluções aplicadas na época foi: criar uma tablespace em nologging (uma tentativa de evitar gerar redo de tabelas temporárias, para o ERP). Depois aumentamos o cache para DML, o que melhorou um pouco também esse trabalho. Um segundo procedimento foi buscar os departamentos que faziam as consultas mais pesadas e disponibilizar computadores melhores, porque parte do processamento da consulta estava no cliente e não no servidor. Como pode observar, estes foram alguns aspectos que buscamos para solucionar o problema para este ERP genérico. Isso é só uma experiência para ajudar a buscar soluções. []s Braga Em 10 de maio de 2010 09:48, orfeu lima orfe...@hotmail.com escreveu: Bom dia a todos!! Tenho um oracle rac com dois nós, sistema operacional Linux Red Hat 5, oracle 10Gr2. Esse ambiente é acessado por um erp que está com sérios problemas de performance. Nesse ambiente tem-se 5 instâncias. Gostaria de saber quais os principais problemas do erp com rac e o que poderia estar modificando de cara nesse ambiente para poder melhorá-lo. Obrigado [As partes desta mensagem que não continham texto foram removidas]
RE: [oracle_br] RAC x ERP
Marcos, as conexões estao la tcp0 0 192.168.248.200:15210.0.0.0:* OUÃA tcp0 0 192.168.248.210:15210.0.0.0:* OUÃA mas mesmo assim nao consigo acessar. olha so. To: oracle_br@yahoogrupos.com.br From: braga.mar...@gmail.com Date: Thu, 13 May 2010 15:46:33 -0300 Subject: Re: [oracle_br] RAC x ERP Oi Orfeu, Na versão 10, quando reinstalava o EM, geralmente, ele não subia de primeira e acabava dando algum erro que não encontrava solução. Mas, milagrosamente, após uns 5 minutos ele estava ON; e só Deus sabe como isso ocorria. Eu só descobria utilizando o seguinte comando: # netstat -ltn GOTCHA! tava lá a porkera da porta 1158 aberta, aguardando conexões. Bom..., alternativamente, sempre consultava os logs para saber o que estava ocorrendo, alguns problemas descobri consultando os logs; é um bom começo. Primeiramente aconselho verificar se a porta abre após uns 5 minutos que tentou subir o serviço; Segundamente (r), aconselho verificar o log do EM. []s Braga Em 13 de maio de 2010 14:48, orfeu lima orfe...@hotmail.com escreveu: Marcos boa tarde!! O primeiro problema detectado foi na camada de transporte, entre o listener e o tcp/ip. Segundo documento encontrado esse problema é aleatório, mas mesmo assim vi que alguns parâmetros de tcp/ip não estavam de acordo com as melhores práticas, o que estou alterando para reiniciar o ambiente e testar. Outro problema que estou encontrando é com o enterprise manager. Não estou conseguindo subi-lo, ja reconfigurei com o emca, mas na hora de acessar via browser não entra. Saberia me dizer o pq de não estar conseguindo acessar o banco via enterprise manager. abraço. To: oracle_br@yahoogrupos.com.br From: braga.mar...@gmail.com Date: Mon, 10 May 2010 10:32:07 -0300 Subject: Re: [oracle_br] RAC x ERP Olá Orfeu, Tempos atrás trabalhei com um ERP que era genérico, tipo..., para qualquer banco de dados..., isso é um tiro-no-pé. O principal problema desse ERP específico e genérico era, para toda e qualquer consulta que ele fazia, ocorria um FULL TABLE SCAN, criando uma tabela TEMPORÁRIA e depois são criados índices e aplicados os filtros (muitas vezes no terminal do próprio cliente da consulta) e por último (e não menos importante), um DROP nessa tabela TEMPORÁRIA. O pior é que para o caso da tal tabela TEMPORÁRIA, ela não estava em uma TEMPORARY TABLESPACE, estava em uma tablespace física, pois o ERP não saberia trabalhar com uma TEMPORARY TABLESPACE, porque é genérico. Observou o processo Cara..., quem idealizou o ERP se preocupou em deixá-lo genérico fazendo essa cáca genérica..., em ambientes corporativos, onde há redundância e segurança para não perder dados, isso é a morte. A vantagem é que funciona com a maioria dos bancos efetuando-se poucas alterações. Esse foi um caso específico de um ERP específico..., depois de muita análise descobrimos como o ERP trabalhava, gerando esse número enorme de DML no banco; nesse período haviam muitos problemas de performance no banco. Uma das soluções aplicadas na época foi: criar uma tablespace em nologging (uma tentativa de evitar gerar redo de tabelas temporárias, para o ERP). Depois aumentamos o cache para DML, o que melhorou um pouco também esse trabalho. Um segundo procedimento foi buscar os departamentos que faziam as consultas mais pesadas e disponibilizar computadores melhores, porque parte do processamento da consulta estava no cliente e não no servidor. Como pode observar, estes foram alguns aspectos que buscamos para solucionar o problema para este ERP genérico. Isso é só uma experiência para ajudar a buscar soluções. []s Braga Em 10 de maio de 2010 09:48, orfeu lima orfe...@hotmail.com escreveu: Bom dia a todos!! Tenho um oracle rac com dois nós, sistema operacional Linux Red Hat 5, oracle 10Gr2. Esse ambiente é acessado por um erp que está com sérios problemas de performance. Nesse ambiente tem-se 5 instâncias. Gostaria de saber quais os principais problemas do erp com rac e o que poderia estar modificando de cara nesse ambiente para poder melhorá-lo. Obrigado [As partes desta mensagem que não continham texto foram removidas] _ DEIXE SUAS CONVERSAS MAIS DIVERTIDAS. TRANSFORME AQUI SUAS FOTOS EM EMOTICONS, É GRÁTIS. http://ilm.windowslive.com.br/?ocid=ILM:ILM:Hotmail:Tagline:1x1:Tagline [As partes desta mensagem que não continham texto foram removidas] -- 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-archive.com/oracle_br@yahoogrupos.com.br
Re: [oracle_br] RAC x ERP
Esse resultado mostra que só o listener está ativo, não o EM. A porta padrão do listener é 1521 (porta reportada), se o EM estivesse ativo, provavelmente apareceria a 1158 nessa lista. É bom partir para o log mesmo. []s Braga Em 13 de maio de 2010 15:50, orfeu lima orfe...@hotmail.com escreveu: Marcos, as conexões estao la tcp0 0 192.168.248.200:15210.0.0.0:* OUÃA tcp0 0 192.168.248.210:15210.0.0.0:* OUÃA mas mesmo assim nao consigo acessar. olha so. To: oracle_br@yahoogrupos.com.br From: braga.mar...@gmail.com Date: Thu, 13 May 2010 15:46:33 -0300 Subject: Re: [oracle_br] RAC x ERP Oi Orfeu, Na versão 10, quando reinstalava o EM, geralmente, ele não subia de primeira e acabava dando algum erro que não encontrava solução. Mas, milagrosamente, após uns 5 minutos ele estava ON; e só Deus sabe como isso ocorria. Eu só descobria utilizando o seguinte comando: # netstat -ltn GOTCHA! tava lá a porkera da porta 1158 aberta, aguardando conexões. Bom..., alternativamente, sempre consultava os logs para saber o que estava ocorrendo, alguns problemas descobri consultando os logs; é um bom começo. Primeiramente aconselho verificar se a porta abre após uns 5 minutos que tentou subir o serviço; Segundamente (r), aconselho verificar o log do EM. []s Braga Em 13 de maio de 2010 14:48, orfeu lima orfe...@hotmail.com escreveu: Marcos boa tarde!! O primeiro problema detectado foi na camada de transporte, entre o listener e o tcp/ip. Segundo documento encontrado esse problema é aleatório, mas mesmo assim vi que alguns parâmetros de tcp/ip não estavam de acordo com as melhores práticas, o que estou alterando para reiniciar o ambiente e testar. Outro problema que estou encontrando é com o enterprise manager. Não estou conseguindo subi-lo, ja reconfigurei com o emca, mas na hora de acessar via browser não entra. Saberia me dizer o pq de não estar conseguindo acessar o banco via enterprise manager. abraço. To: oracle_br@yahoogrupos.com.br From: braga.mar...@gmail.com Date: Mon, 10 May 2010 10:32:07 -0300 Subject: Re: [oracle_br] RAC x ERP Olá Orfeu, Tempos atrás trabalhei com um ERP que era genérico, tipo..., para qualquer banco de dados..., isso é um tiro-no-pé. O principal problema desse ERP específico e genérico era, para toda e qualquer consulta que ele fazia, ocorria um FULL TABLE SCAN, criando uma tabela TEMPORÁRIA e depois são criados índices e aplicados os filtros (muitas vezes no terminal do próprio cliente da consulta) e por último (e não menos importante), um DROP nessa tabela TEMPORÁRIA. O pior é que para o caso da tal tabela TEMPORÁRIA, ela não estava em uma TEMPORARY TABLESPACE, estava em uma tablespace física, pois o ERP não saberia trabalhar com uma TEMPORARY TABLESPACE, porque é genérico. Observou o processo Cara..., quem idealizou o ERP se preocupou em deixá-lo genérico fazendo essa cáca genérica..., em ambientes corporativos, onde há redundância e segurança para não perder dados, isso é a morte. A vantagem é que funciona com a maioria dos bancos efetuando-se poucas alterações. Esse foi um caso específico de um ERP específico..., depois de muita análise descobrimos como o ERP trabalhava, gerando esse número enorme de DML no banco; nesse período haviam muitos problemas de performance no banco. Uma das soluções aplicadas na época foi: criar uma tablespace em nologging (uma tentativa de evitar gerar redo de tabelas temporárias, para o ERP). Depois aumentamos o cache para DML, o que melhorou um pouco também esse trabalho. Um segundo procedimento foi buscar os departamentos que faziam as consultas mais pesadas e disponibilizar computadores melhores, porque parte do processamento da consulta estava no cliente e não no servidor. Como pode observar, estes foram alguns aspectos que buscamos para solucionar o problema para este ERP genérico. Isso é só uma experiência para ajudar a buscar soluções. []s Braga Em 10 de maio de 2010 09:48, orfeu lima orfe...@hotmail.com escreveu: Bom dia a todos!! Tenho um oracle rac com dois nós, sistema operacional Linux Red Hat 5, oracle 10Gr2. Esse ambiente é acessado por um erp que está com sérios problemas de performance. Nesse ambiente tem-se 5 instâncias. Gostaria de saber quais os principais problemas do erp com rac e o que poderia estar modificando de cara nesse ambiente para poder melhorá-lo. Obrigado [As partes desta mensagem que não continham texto foram removidas]
[oracle_br] RAC x ERP
Bom dia a todos!! Tenho um oracle rac com dois nós, sistema operacional Linux Red Hat 5, oracle 10Gr2. Esse ambiente é acessado por um erp que está com sérios problemas de performance. Nesse ambiente tem-se 5 instâncias. Gostaria de saber quais os principais problemas do erp com rac e o que poderia estar modificando de cara nesse ambiente para poder melhorá-lo. Obrigado _ DIVIRTA SEUS AMIGOS NO MESSENGER. TRANSFORME AQUI SUAS FOTOS EM EMOTICONS, É GRÁTIS. http://ilm.windowslive.com.br/?ocid=ILM:ILM:Hotmail:Tagline:1x1:Tagline [As partes desta mensagem que não continham texto foram removidas]
Re: [oracle_br] RAC x ERP
Olá Orfeu, Tempos atrás trabalhei com um ERP que era genérico, tipo..., para qualquer banco de dados..., isso é um tiro-no-pé. O principal problema desse ERP específico e genérico era, para toda e qualquer consulta que ele fazia, ocorria um FULL TABLE SCAN, criando uma tabela TEMPORÁRIA e depois são criados índices e aplicados os filtros (muitas vezes no terminal do próprio cliente da consulta) e por último (e não menos importante), um DROP nessa tabela TEMPORÁRIA. O pior é que para o caso da tal tabela TEMPORÁRIA, ela não estava em uma TEMPORARY TABLESPACE, estava em uma tablespace física, pois o ERP não saberia trabalhar com uma TEMPORARY TABLESPACE, porque é genérico. Observou o processo Cara..., quem idealizou o ERP se preocupou em deixá-lo genérico fazendo essa cáca genérica..., em ambientes corporativos, onde há redundância e segurança para não perder dados, isso é a morte. A vantagem é que funciona com a maioria dos bancos efetuando-se poucas alterações. Esse foi um caso específico de um ERP específico..., depois de muita análise descobrimos como o ERP trabalhava, gerando esse número enorme de DML no banco; nesse período haviam muitos problemas de performance no banco. Uma das soluções aplicadas na época foi: criar uma tablespace em nologging (uma tentativa de evitar gerar redo de tabelas temporárias, para o ERP). Depois aumentamos o cache para DML, o que melhorou um pouco também esse trabalho. Um segundo procedimento foi buscar os departamentos que faziam as consultas mais pesadas e disponibilizar computadores melhores, porque parte do processamento da consulta estava no cliente e não no servidor. Como pode observar, estes foram alguns aspectos que buscamos para solucionar o problema para este ERP genérico. Isso é só uma experiência para ajudar a buscar soluções. []s Braga Em 10 de maio de 2010 09:48, orfeu lima orfe...@hotmail.com escreveu: Bom dia a todos!! Tenho um oracle rac com dois nós, sistema operacional Linux Red Hat 5, oracle 10Gr2. Esse ambiente é acessado por um erp que está com sérios problemas de performance. Nesse ambiente tem-se 5 instâncias. Gostaria de saber quais os principais problemas do erp com rac e o que poderia estar modificando de cara nesse ambiente para poder melhorá-lo. Obrigado [As partes desta mensagem que não continham texto foram removidas]
