Re: [oracle_br] Re: Problema com cursor em procedure demorada
Anderson É, pode ser... Ao invés de simplesmente debugar (já que demora várias horas), seria interessante "instrumentar" a procedure para registrar os passos de execução, em algum tipo de log. Mas, infelizmente, não vou poder atuar nisso. Só posso repassar as dicas aqui do fórum para o meu amigo... Estou com outro trabalho (para variar, com prazo para ontem! rsss) Obrigado! [ ] André Em 15/06/08, Anderson Santiago <[EMAIL PROTECTED]> escreveu: > > Amigo, > reveja o codigo da procedure e tente rodar alguma vez debugando, sou capaz > de apostar que em algum lugar ela > entra em looping. > Att. > Anderson > > - Mensagem original > De: Andre Santos <[EMAIL PROTECTED] > > > Para: oracle_br@yahoogrupos.com.br > Enviadas: Sexta-feira, 13 de Junho de 2008 17:53:50 > Assunto: Re: [oracle_br] Re: Problema com cursor em procedure demorada > > Oi Welvis > > Obrigado pela resposta... mas não são 200 "milhões", não! São **somente** > 200 mesmo! (2 centenas). > É bem pouco mesmo. > > Na hora também estranhei: mas como? 200 linhas demorar 16 horas??? > Mas depois vi que o problema é o "algoritmo matemático", cheio de iterações > (loops) e condições, com números fracionários na condição dos loops... > (coisa tipo "cálculo numérico", da faculdade). > > Claro que pode haver maneira de otimizar isso... mas o problema é a > aparente > perda referência... com sintoma de "reexecução" da procedure e respectivo > cursor, devido à duplicidade do ROWCOUNT na tabela de "log". > > Vamos ver se alguém tem notícia de algum bug... > > De qualquer forma, muito obrigado! > > [ ] > > André > > Em 13/06/08, Welvis Douglas <[EMAIL PROTECTED] com.br> escreveu: > > > > poxa vida em amigo, processar 200 milhoes de linhas é meio enviavel, > > divida isso, faça algo para reduzir esse processamento, aqui tbm temos > > muitos processos pesados... estamos revendo eles, agora nada que seja de > 200 > > milhoes... > > > > nossa base tem mais de 260 milhoes de Item NF, porem acessamos apenas o > que > > tem que ser acessado, agora isso que vc está fizendo, demorando 16 horas, > > como que fica o acesso dos outros usuarios na base, pois aqui quando está > > rodando os processos fica um locura... > > > > ... > > > > de mais detalher do seu amdiente .. > > > > quem sabe podemos ajuda vc.. > > > > abraço.! > > > > - Original Message - > > From: Andre Santos > > To: [EMAIL PROTECTED] os.com.br > > Sent: Friday, June 13, 2008 5:27 PM > > Subject: [oracle_br] Re: Problema com cursor em procedure demorada > > > > Ah, em tempo: > > > > Já sugeri que ativassem um trace da sessão e executassem novamente a > > procedure. > > Também perguntei se há algo que roda nesse BD (um "job", por exemplo). > > E falei para meu amigo conversar com o DBA, para ver se há algo no > > alert.log. > > > > Já ativaram o trace... mas agora só na segunda (pois a SP só vai > > terminar no sábado) para saber como ficou. > > > > Obrigado! > > [ ]'s > > > > André > > > > Em 13/06/08, Andre Santos > com ti%40gmail. com>> > > escreveu: > > > Pessoal > > > > > > Versão do servidor de "desenvolvimento" : > > > - - - - - - > > > SELECT * FROM v$version; > > > . Oracle9i Enterprise Edition Release 9.2.0.8.0 - Production > > > . PL/SQL Release 9.2.0.8.0 - Production > > > . CORE 9.2.0.8.0 Production > > > . TNS for 32-bit Windows: Version 9.2.0.8.0 - Production > > > . NLSRTL Version 9.2.0.8.0 - Production > > > - - - - - - > > > > > > Um colega aqui está com uma manutenção de sistema. Pegou uma procedure > > > problemática. .. e pediu uma ajuda. > > > Para ter uma idéia, a procedure está demorando 16 horas para completar > > > a execução... processando pouco mais de 200 linhas. > > > > > > Mas a demora não é devida à consulta dessas linhas. > > > Essa SP realiza uma série de cálculos tipo "científicos" , com vários > > > loops, etc., etc., etc... > > > > > > O cenário é o seguinte: > > > - É gravada uma tabela de "log" com os cálculos realizados (um > > > registro para cada linha do cursor, ou seja, no final deveria ter as > > > 200 e poucas linhas). > > > - Nesse "log", é gravado o valor do atributo ROWCOUNT do cursor, o > > > valor de uma sequence (essa sequence é só para a tabela de log), e o > > > SYSDATE. > > > - Garantiram que a procedure não é disparada mais de uma vez (no > > > ambiente de desenvolvimento) , nem há um job que faça isso. > > > > > > O problema é: "aparentemente" chega uma hora em que a procedure se > > perde... > > > Na tabela de "log", há ***repetição do ROWCOUNT*** (algumas > > > ocorrências), como se tivesse tentado reexecutar a procedure/cursor. .. > > > o que diferencia é apenas a sequence e o SYSDATE. > > > > > > Ainda não tive tempo de ver a SP detalhadamente, para ajudar meu > > > colega, mas uma hipótese seria algum bug do Oracle... necessidade de > > > "patch"... > > > OBS.: Não tenho acesso ao Metalink. =^( > > > > > > Alg
Res: Res: RES: [oracle_br] standby database
Só hoje fui ver isso, eu lembro que antigamente antes essas infos eram bem definidas, mas parece que hoje em dia não faz diferença pra eles principalmente na hora de vender. Mais uma coisa que a gente tem que ficar atento, porque na hora de vender é tudo maravilha. Acho que eles evitam deixar claro esse tipo de coisa, porque o enterprise é que sempre vem com as features mais importantes e melhoradas na versão. Att. Anderson Santiago - Mensagem original De: jlchiappa <[EMAIL PROTECTED]> Para: oracle_br@yahoogrupos.com.br Enviadas: Segunda-feira, 9 de Junho de 2008 22:20:50 Assunto: Re: Res: RES: [oracle_br] standby database Colega, se te falaram isso te tapearam direitinho, http://www.oracle. com/technology/ products/ database/ oracle10g/ pdf/twp_general_ 10gdb_product_ family.pdf é a lista pública de features não permitidas no Standard, ** longe ** de ser só processador no Standard vc perde o Virtual private Database (para dar privilégios 'dinâmicos', de acordo com uma condição), perde o Advanced Security, perde PARTICIONAMENTO (só isso pra mim já invalida em muitos casos, principalmente em DW/batch, Particionamento é quase sempre CRUCIAL prum ambiente desses), vc perde o OLAP, o data Minig, a compressão nativa 10g Enfim, em resumo, é um ** MUNDO ** de coisas que vc perde, o Standard é BEM "capadinho", não é só "processador" mesmo, de jeito nenhum []s Chiappa --- Em [EMAIL PROTECTED] os.com.br, Anderson Santiago escreveu > > Vamos conversando, até onde dá né...afinal de contas não sabemos tudo e tem coisa que a gente vê e não lembra depois. > Eu comprei umas licenças de standard esse ano, e me garantiram que a unica limitação era processador. .. > indice bitmap eu nunca ia imaginar, se não pode esse tipo de indice, com certeza deve ter limitações de features de Datwarehouse, > como cubo e etc... > Vou pedir meu dinheiro de volta..rsrsrsr, ainda bem que ainda não estou usando essa base, nem instalei ainda, por se > tratar de um sistema de pouca importancia. > > > - Mensagem original > De: Augusto Cesar R. Costa > Para: [EMAIL PROTECTED] os.com.br > Enviadas: Segunda-feira, 9 de Junho de 2008 1:40:38 > Assunto: RES: [oracle_br] standby database > > > Anderson, obrigado por dar prosseguimento à nossa conversa. > > Não acho que estas discussões sejam perda de tempo, servem para o > crescimento do grupo. > > Voltando ao tema, se não estou enganado, algumas features são realmente > exclusivas de um banco versão Enterprise. > > Um exemplo... > > A criação de índice online assim como a criação de índices do tipo Bitmap > são features exclusivas de um banco de dados Enterprise Edition. > > Fiz um pequeno teste para ver, tentando criar índices online e índices do > tipo Bitmap num banco de dados Standart Edition: > > SQL> conn / as sysdba > > Connected. > > SQL> create user oraclebr identified by oraclebr; > > User created. > > SQL> grant dba to oraclebr; > > Grant succeeded. > > SQL> conn oraclebr/oraclebr > > Connected. > > SQL> create table t1 as select * from all_objects; > > Table created. > > SQL> create index t1_idx on t1(object_name) online; > > create index t1_idx on t1(object_name) online > > * > > ERROR at line 1: > > ORA-00439: feature not enabled: Online Index Build > > SQL> select * from v$version; > > BANNER > > - - - - - - > > Oracle Database 10g Release 10.2.0.4.0 - 64bit Production > > PL/SQL Release 10.2.0.4.0 - Production > > CORE 10.2.0.4.0 Production > > TNS for Linux: Version 10.2.0.4.0 - Production > > NLSRTL Version 10.2.0.4.0 - Production > > SQL> create bitmap index t1_bidx on t1(owner); > > create bitmap index t1_bidx on t1(owner) > > * > > ERROR at line 1: > > ORA-00439: feature not enabled: Bit-mapped indexes > > Portanto, não é perda de tempo fazer testes para ver as diferenças entre as > versões. > > Estas questões de "vai por mim", não são confiáveis, pois, por melhor que > seja um profissional, poderá também se equivocar. > > Sugiro que de uma olhada no blog do Marcio Portes, participante do nosso > grupo. > > Ele montou um dataguard e para isto, precisou utilizar a versão Enterprise. > > Segue o link: > > http://mportes. blogspot. com/2007/ 06/montar- dataguard- no-10g-com- broker.html > > Solicito ainda que o Márcio, se possível, se manifeste em relação a > possibilidade ou não de se fazer isto utilizando um banco versão Standart. > Até onde sei, isto só é realmente possível na versão Enterprise. > > Quanto ao teste da atualização automática do banco de dados standby da forma > que sugeriu, farei um teste em breve num banco de dados Oracle versão > Standart e logo posto o resultado. > > Abraços e até mais. > > Augusto Cesar R. Costa > > _ > > De: [EMAIL PROTECTED] os.com.br [mailto:oracle_ [EMAIL PROTECTED] os.com.br] Em > nome de Anderson Santiago > Enviada em: domingo, 8 de junho de 2008 01:00 > Para: [EMAIL PROTECTED] os.com.br > A
Res: [oracle_br] SQL Dinâmico
Não sei se te adianta, mas quando coleta estatistica você tem uma quantidade de linhas aproximadas em um dos campos da DBA_TABLES. Te digo isso, porque apesar de que esse select seu funcione, se a tabela for muito grande vai demorar muito e no caso, da DBA_TABLES vai ter o numero aproximado de linhas depois de rodar uma estatistica. att. Anderson Santiago DBA Sênior. www.ruevers.webs.com - Mensagem original De: francisco porfirio <[EMAIL PROTECTED]> Para: oracle_br@yahoogrupos.com.br Enviadas: Sexta-feira, 13 de Junho de 2008 11:52:40 Assunto: [oracle_br] SQL Dinâmico Pessoal... Eu estava querendo montar um relatório com a quantidade de registro de cada tabela, para isso eu iria preciar de um sql dinâmico, algo mais ou menos assim var_nometabela := varre.tname; var_query := '''select count(*) from '||var_nometabela ||''' into var_quantidadereg' ; dbms_output. put_line( var_query) ; execute immediate var_query; Não estou conseguindo fazer com que a consulta montada na string seja executada pelo executa immediate, alguem pode ajudar ? -- Atenciosamente Francisco Porfirio Ribeiro Neto [As partes desta mensagem que não continham texto foram removidas] Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento! http://br.mail.yahoo.com/ [As partes desta mensagem que não continham texto foram removidas]
Res: [oracle_br] Re: Carga de dados
Ow, se contar porque não pode usar os recursos do oracle eu conto a solução...ok?rsrsrsr []´s Anderson Santiago DBA Sênior www.ruevers.webs.com ps. realmente fiquei curioso...porque nao pode usar nada disso. - Mensagem original De: anderson.castro_16 <[EMAIL PROTECTED]> Para: oracle_br@yahoogrupos.com.br Enviadas: Sexta-feira, 13 de Junho de 2008 16:04:29 Assunto: [oracle_br] Re: Carga de dados Wesley, Embora a oracle ofereça inumeros recursos para isto eu não posso usá- los. --- Em [EMAIL PROTECTED] os.com.br, "Welvis Douglas" <[EMAIL PROTECTED]> escreveu > > Amigo aqui eu uso o expdp, > > drop o ambiente de desenv e importo denovo, mas vc pode usar o copy table no oracle... mas recomendo fazer via expdp e impdp > > att, > > Welvis Douglas > > - Original Message - > From: anderson.castro_ 16 > To: [EMAIL PROTECTED] os.com.br > Sent: Friday, June 13, 2008 3:52 PM > Subject: [oracle_br] Carga de dados > > > Senhores, > > Eu estou precisando fazer uma carga de dados de produção para > desenvolvimento, as tabelas já existem em desenvolvimento, preciso > apenas fazer a carga de dados de um ambiente para o outro, porém não > posso usar o (rman / import /export). Alguém conhece algum software ou > outra maneira que eu consiga fazer esta carga de dados. > > Fico no aguardo. > > > > > > [As partes desta mensagem que não continham texto foram removidas] > Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento! http://br.mail.yahoo.com/ [As partes desta mensagem que não continham texto foram removidas]
Res: [oracle_br] Re: Problema com cursor em procedure demorada
Amigo, reveja o codigo da procedure e tente rodar alguma vez debugando, sou capaz de apostar que em algum lugar ela entra em looping. Att. Anderson - Mensagem original De: Andre Santos <[EMAIL PROTECTED]> Para: oracle_br@yahoogrupos.com.br Enviadas: Sexta-feira, 13 de Junho de 2008 17:53:50 Assunto: Re: [oracle_br] Re: Problema com cursor em procedure demorada Oi Welvis Obrigado pela resposta... mas não são 200 "milhões", não! São **somente** 200 mesmo! (2 centenas). É bem pouco mesmo. Na hora também estranhei: mas como? 200 linhas demorar 16 horas??? Mas depois vi que o problema é o "algoritmo matemático", cheio de iterações (loops) e condições, com números fracionários na condição dos loops... (coisa tipo "cálculo numérico", da faculdade). Claro que pode haver maneira de otimizar isso... mas o problema é a aparente perda referência... com sintoma de "reexecução" da procedure e respectivo cursor, devido à duplicidade do ROWCOUNT na tabela de "log". Vamos ver se alguém tem notícia de algum bug... De qualquer forma, muito obrigado! [ ] André Em 13/06/08, Welvis Douglas <[EMAIL PROTECTED] com.br> escreveu: > > poxa vida em amigo, processar 200 milhoes de linhas é meio enviavel, > divida isso, faça algo para reduzir esse processamento, aqui tbm temos > muitos processos pesados... estamos revendo eles, agora nada que seja de 200 > milhoes... > > nossa base tem mais de 260 milhoes de Item NF, porem acessamos apenas o que > tem que ser acessado, agora isso que vc está fizendo, demorando 16 horas, > como que fica o acesso dos outros usuarios na base, pois aqui quando está > rodando os processos fica um locura... > > ... > > de mais detalher do seu amdiente .. > > quem sabe podemos ajuda vc.. > > abraço.! > > - Original Message - > From: Andre Santos > To: [EMAIL PROTECTED] os.com.br > Sent: Friday, June 13, 2008 5:27 PM > Subject: [oracle_br] Re: Problema com cursor em procedure demorada > > Ah, em tempo: > > Já sugeri que ativassem um trace da sessão e executassem novamente a > procedure. > Também perguntei se há algo que roda nesse BD (um "job", por exemplo). > E falei para meu amigo conversar com o DBA, para ver se há algo no > alert.log. > > Já ativaram o trace... mas agora só na segunda (pois a SP só vai > terminar no sábado) para saber como ficou. > > Obrigado! > [ ]'s > > André > > Em 13/06/08, Andre Santos ti%40gmail. com>> > escreveu: > > Pessoal > > > > Versão do servidor de "desenvolvimento" : > > - - - - - - > > SELECT * FROM v$version; > > . Oracle9i Enterprise Edition Release 9.2.0.8.0 - Production > > . PL/SQL Release 9.2.0.8.0 - Production > > . CORE 9.2.0.8.0 Production > > . TNS for 32-bit Windows: Version 9.2.0.8.0 - Production > > . NLSRTL Version 9.2.0.8.0 - Production > > - - - - - - > > > > Um colega aqui está com uma manutenção de sistema. Pegou uma procedure > > problemática. .. e pediu uma ajuda. > > Para ter uma idéia, a procedure está demorando 16 horas para completar > > a execução... processando pouco mais de 200 linhas. > > > > Mas a demora não é devida à consulta dessas linhas. > > Essa SP realiza uma série de cálculos tipo "científicos" , com vários > > loops, etc., etc., etc... > > > > O cenário é o seguinte: > > - É gravada uma tabela de "log" com os cálculos realizados (um > > registro para cada linha do cursor, ou seja, no final deveria ter as > > 200 e poucas linhas). > > - Nesse "log", é gravado o valor do atributo ROWCOUNT do cursor, o > > valor de uma sequence (essa sequence é só para a tabela de log), e o > > SYSDATE. > > - Garantiram que a procedure não é disparada mais de uma vez (no > > ambiente de desenvolvimento) , nem há um job que faça isso. > > > > O problema é: "aparentemente" chega uma hora em que a procedure se > perde... > > Na tabela de "log", há ***repetição do ROWCOUNT*** (algumas > > ocorrências), como se tivesse tentado reexecutar a procedure/cursor. .. > > o que diferencia é apenas a sequence e o SYSDATE. > > > > Ainda não tive tempo de ver a SP detalhadamente, para ajudar meu > > colega, mas uma hipótese seria algum bug do Oracle... necessidade de > > "patch"... > > OBS.: Não tenho acesso ao Metalink. =^( > > > > Alguém já passou por isso, ou já ouviu falar de um problema semelhante? > > > > Obrigado! > > > > [ ]'s > > > > André Santos > > > > [As partes desta mensagem que não continham texto foram removidas] > > > [As partes desta mensagem que não continham texto foram removidas] Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento! http://br.mail.yahoo.com/ [As partes desta mensagem que não continham texto foram removidas]
Res: [oracle_br] Re: Problema com cursor em procedure demorada
Amigo, reveja o codigo da procedure e tente rodar alguma vez debugando, sou capaz de apostar que em algum lugar ela entra em looping. Att. Anderson - Mensagem original De: Andre Santos <[EMAIL PROTECTED]> Para: oracle_br@yahoogrupos.com.br Enviadas: Sexta-feira, 13 de Junho de 2008 17:53:50 Assunto: Re: [oracle_br] Re: Problema com cursor em procedure demorada Oi Welvis Obrigado pela resposta... mas não são 200 "milhões", não! São **somente** 200 mesmo! (2 centenas). É bem pouco mesmo. Na hora também estranhei: mas como? 200 linhas demorar 16 horas??? Mas depois vi que o problema é o "algoritmo matemático", cheio de iterações (loops) e condições, com números fracionários na condição dos loops... (coisa tipo "cálculo numérico", da faculdade). Claro que pode haver maneira de otimizar isso... mas o problema é a aparente perda referência... com sintoma de "reexecução" da procedure e respectivo cursor, devido à duplicidade do ROWCOUNT na tabela de "log". Vamos ver se alguém tem notícia de algum bug... De qualquer forma, muito obrigado! [ ] André Em 13/06/08, Welvis Douglas <[EMAIL PROTECTED] com.br> escreveu: > > poxa vida em amigo, processar 200 milhoes de linhas é meio enviavel, > divida isso, faça algo para reduzir esse processamento, aqui tbm temos > muitos processos pesados... estamos revendo eles, agora nada que seja de 200 > milhoes... > > nossa base tem mais de 260 milhoes de Item NF, porem acessamos apenas o que > tem que ser acessado, agora isso que vc está fizendo, demorando 16 horas, > como que fica o acesso dos outros usuarios na base, pois aqui quando está > rodando os processos fica um locura... > > ... > > de mais detalher do seu amdiente .. > > quem sabe podemos ajuda vc.. > > abraço.! > > - Original Message - > From: Andre Santos > To: [EMAIL PROTECTED] os.com.br > Sent: Friday, June 13, 2008 5:27 PM > Subject: [oracle_br] Re: Problema com cursor em procedure demorada > > Ah, em tempo: > > Já sugeri que ativassem um trace da sessão e executassem novamente a > procedure. > Também perguntei se há algo que roda nesse BD (um "job", por exemplo). > E falei para meu amigo conversar com o DBA, para ver se há algo no > alert.log. > > Já ativaram o trace... mas agora só na segunda (pois a SP só vai > terminar no sábado) para saber como ficou. > > Obrigado! > [ ]'s > > André > > Em 13/06/08, Andre Santos ti%40gmail. com>> > escreveu: > > Pessoal > > > > Versão do servidor de "desenvolvimento" : > > - - - - - - > > SELECT * FROM v$version; > > . Oracle9i Enterprise Edition Release 9.2.0.8.0 - Production > > . PL/SQL Release 9.2.0.8.0 - Production > > . CORE 9.2.0.8.0 Production > > . TNS for 32-bit Windows: Version 9.2.0.8.0 - Production > > . NLSRTL Version 9.2.0.8.0 - Production > > - - - - - - > > > > Um colega aqui está com uma manutenção de sistema. Pegou uma procedure > > problemática. .. e pediu uma ajuda. > > Para ter uma idéia, a procedure está demorando 16 horas para completar > > a execução... processando pouco mais de 200 linhas. > > > > Mas a demora não é devida à consulta dessas linhas. > > Essa SP realiza uma série de cálculos tipo "científicos" , com vários > > loops, etc., etc., etc... > > > > O cenário é o seguinte: > > - É gravada uma tabela de "log" com os cálculos realizados (um > > registro para cada linha do cursor, ou seja, no final deveria ter as > > 200 e poucas linhas). > > - Nesse "log", é gravado o valor do atributo ROWCOUNT do cursor, o > > valor de uma sequence (essa sequence é só para a tabela de log), e o > > SYSDATE. > > - Garantiram que a procedure não é disparada mais de uma vez (no > > ambiente de desenvolvimento) , nem há um job que faça isso. > > > > O problema é: "aparentemente" chega uma hora em que a procedure se > perde... > > Na tabela de "log", há ***repetição do ROWCOUNT*** (algumas > > ocorrências), como se tivesse tentado reexecutar a procedure/cursor. .. > > o que diferencia é apenas a sequence e o SYSDATE. > > > > Ainda não tive tempo de ver a SP detalhadamente, para ajudar meu > > colega, mas uma hipótese seria algum bug do Oracle... necessidade de > > "patch"... > > OBS.: Não tenho acesso ao Metalink. =^( > > > > Alguém já passou por isso, ou já ouviu falar de um problema semelhante? > > > > Obrigado! > > > > [ ]'s > > > > André Santos > > > > [As partes desta mensagem que não continham texto foram removidas] > > > [As partes desta mensagem que não continham texto foram removidas] Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento! http://br.mail.yahoo.com/ [As partes desta mensagem que não continham texto foram removidas]
Res: [oracle_br] Re: Problema com cursor em procedure demorada
Amigo, reveja o codigo da procedure e tente rodar alguma vez debugando, sou capaz de apostar que em algum lugar ela entra em looping. Att. Anderson - Mensagem original De: Andre Santos <[EMAIL PROTECTED]> Para: oracle_br@yahoogrupos.com.br Enviadas: Sexta-feira, 13 de Junho de 2008 17:53:50 Assunto: Re: [oracle_br] Re: Problema com cursor em procedure demorada Oi Welvis Obrigado pela resposta... mas não são 200 "milhões", não! São **somente** 200 mesmo! (2 centenas). É bem pouco mesmo. Na hora também estranhei: mas como? 200 linhas demorar 16 horas??? Mas depois vi que o problema é o "algoritmo matemático", cheio de iterações (loops) e condições, com números fracionários na condição dos loops... (coisa tipo "cálculo numérico", da faculdade). Claro que pode haver maneira de otimizar isso... mas o problema é a aparente perda referência... com sintoma de "reexecução" da procedure e respectivo cursor, devido à duplicidade do ROWCOUNT na tabela de "log". Vamos ver se alguém tem notícia de algum bug... De qualquer forma, muito obrigado! [ ] André Em 13/06/08, Welvis Douglas <[EMAIL PROTECTED] com.br> escreveu: > > poxa vida em amigo, processar 200 milhoes de linhas é meio enviavel, > divida isso, faça algo para reduzir esse processamento, aqui tbm temos > muitos processos pesados... estamos revendo eles, agora nada que seja de 200 > milhoes... > > nossa base tem mais de 260 milhoes de Item NF, porem acessamos apenas o que > tem que ser acessado, agora isso que vc está fizendo, demorando 16 horas, > como que fica o acesso dos outros usuarios na base, pois aqui quando está > rodando os processos fica um locura... > > ... > > de mais detalher do seu amdiente .. > > quem sabe podemos ajuda vc.. > > abraço.! > > - Original Message - > From: Andre Santos > To: [EMAIL PROTECTED] os.com.br > Sent: Friday, June 13, 2008 5:27 PM > Subject: [oracle_br] Re: Problema com cursor em procedure demorada > > Ah, em tempo: > > Já sugeri que ativassem um trace da sessão e executassem novamente a > procedure. > Também perguntei se há algo que roda nesse BD (um "job", por exemplo). > E falei para meu amigo conversar com o DBA, para ver se há algo no > alert.log. > > Já ativaram o trace... mas agora só na segunda (pois a SP só vai > terminar no sábado) para saber como ficou. > > Obrigado! > [ ]'s > > André > > Em 13/06/08, Andre Santos ti%40gmail. com>> > escreveu: > > Pessoal > > > > Versão do servidor de "desenvolvimento" : > > - - - - - - > > SELECT * FROM v$version; > > . Oracle9i Enterprise Edition Release 9.2.0.8.0 - Production > > . PL/SQL Release 9.2.0.8.0 - Production > > . CORE 9.2.0.8.0 Production > > . TNS for 32-bit Windows: Version 9.2.0.8.0 - Production > > . NLSRTL Version 9.2.0.8.0 - Production > > - - - - - - > > > > Um colega aqui está com uma manutenção de sistema. Pegou uma procedure > > problemática. .. e pediu uma ajuda. > > Para ter uma idéia, a procedure está demorando 16 horas para completar > > a execução... processando pouco mais de 200 linhas. > > > > Mas a demora não é devida à consulta dessas linhas. > > Essa SP realiza uma série de cálculos tipo "científicos" , com vários > > loops, etc., etc., etc... > > > > O cenário é o seguinte: > > - É gravada uma tabela de "log" com os cálculos realizados (um > > registro para cada linha do cursor, ou seja, no final deveria ter as > > 200 e poucas linhas). > > - Nesse "log", é gravado o valor do atributo ROWCOUNT do cursor, o > > valor de uma sequence (essa sequence é só para a tabela de log), e o > > SYSDATE. > > - Garantiram que a procedure não é disparada mais de uma vez (no > > ambiente de desenvolvimento) , nem há um job que faça isso. > > > > O problema é: "aparentemente" chega uma hora em que a procedure se > perde... > > Na tabela de "log", há ***repetição do ROWCOUNT*** (algumas > > ocorrências), como se tivesse tentado reexecutar a procedure/cursor. .. > > o que diferencia é apenas a sequence e o SYSDATE. > > > > Ainda não tive tempo de ver a SP detalhadamente, para ajudar meu > > colega, mas uma hipótese seria algum bug do Oracle... necessidade de > > "patch"... > > OBS.: Não tenho acesso ao Metalink. =^( > > > > Alguém já passou por isso, ou já ouviu falar de um problema semelhante? > > > > Obrigado! > > > > [ ]'s > > > > André Santos > > > > [As partes desta mensagem que não continham texto foram removidas] > > > [As partes desta mensagem que não continham texto foram removidas] Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento! http://br.mail.yahoo.com/ [As partes desta mensagem que não continham texto foram removidas]
Res: [oracle_br] Re: Performance COBOL x ORACLE 10G
Tá usando OCI certo, já tentou fazer algum tunning específico sobre esse tipo de conexão? Outra coisa...tudo fica lento ou selects?? insert , update é normal? Já tentou fazer um trace dessa sessão que demora muito? Qual o comportamento do servidor quando fica lento?? muito IO ou muito processamento? Att. Anderson - Mensagem original De: Osmar Junqueira <[EMAIL PROTECTED]> Para: oracle_br@yahoogrupos.com.br Enviadas: Sexta-feira, 13 de Junho de 2008 21:05:06 Assunto: [oracle_br] Re: Performance COBOL x ORACLE 10G Oi Marcos, obrigado por ter atendido, então é o seguinte o COBOL é microfocus rodando em um servidor unix solaris e estamos rodando estes programas cobol no proprio servidor, eles sao precompilados com os drives do oracle em um outro servidor de desenvolvimento com a mesma caracteristicas de ORACLE, apenas não é ambiente RAC. Segundo o pessoal aqui disseram que estes programas estão realmente lentos por conta da fragmentação de memoria, causada pelos aplicativos externos (on-line), o fato é que quando aplicamos um flush no oracle, ele até roda mais rapido e vai caindo o processamento a medida que executamos os programas em sequencia, mas não acredito que este pode ser a causa raiz destes problemas de lentidão, te digo isto porque a mesma query que rodamos no cobol rodamos ela manualmente no SQLPLUS, ela roda muito rapido retornando os resultados. Você acha que isto pode ser um problema de fragmentação de memoria? ou alguma parametrização especifica para utilização do COBOL com o ORACLE10G. Grato, --- Em [EMAIL PROTECTED] os.com.br, Marco Souza <[EMAIL PROTECTED] .> escreveu > > Osmar, > > Segundo informações deles, estes programas executavam rapidamente usando oracle ? > Qual tipo de conexão que o cobol usa pra acessar o oracle ? Ele roda no servidor ou no cliente ? > Pela sua mensagem, suponho que a conexão com o banco não é feita pelo oracle client, certo ? > > Grande abraço. > > > --- Em ter, 10/6/08, Osmar Junqueira [EMAIL PROTECTED] escreveu: > De: Osmar Junqueira [EMAIL PROTECTED] > Assunto: [oracle_br] Performance COBOL x ORACLE 10G > Para: [EMAIL PROTECTED] os.com.br > Data: Terça-feira, 10 de Junho de 2008, 20:36 > > > > > > > > > > > > Pessoal, > > > > Estou com serios problemas performance de execução de programas em > > COBOL com o ORACLE10G RAC, estes programas são de terceiros e segundo > > informações deles os mesmos programas são executados rapidos em outro > > ambiente UNIX. Gostaria de saber se alguem tem problemas com programas > > cobol utilizando banco de dados em UNIX solaris, e se existem > > configurações especificas para este tipo de software > > > > Grato, > > > > > > > > > > > > > > > > > > > > > > > > > > > > Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento! > http://br.mail. yahoo.com/ > > [As partes desta mensagem que não continham texto foram removidas] > Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento! http://br.mail.yahoo.com/ [As partes desta mensagem que não continham texto foram removidas]
Res: [oracle_br] Oracle Applications
Mano, acho que tem rodar o oraconfig, se não o apache não aponta pro novo servidor. att. Anderson - Mensagem original De: Marcelo Hirayama <[EMAIL PROTECTED]> Para: oracle_br@yahoogrupos.com.br Enviadas: Quinta-feira, 12 de Junho de 2008 15:34:39 Assunto: [oracle_br] Oracle Applications Boa tarde! Clonei o banco de dados utilizado pelo Oracle Applications 11i de servidor. O novo banco manteve o mesmo nome, só mudou de servidor mesmo. Alterei o tnsnames.ora indicado nas váriáveis TNS_ADMIN e IAS_ORACLE_HOME apontando para o novo servidor. Porém o 11i continua conectando no servidor antigo. Alguém sabe se esta configuração está correta? Ou o que está faltando para o 11i "enxergar" o novo banco? Grato, Marcelo Hirayama. _ _ _ _ __ Fale com seus amigos de graça com o novo Yahoo! Messenger http://br.messenger .yahoo.com/ [As partes desta mensagem que não continham texto foram removidas] Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento! http://br.mail.yahoo.com/ [As partes desta mensagem que não continham texto foram removidas]
Res: [oracle_br] Hypirion Urgente...
Amigo, acho que Hyperion...não é? se for no site da Oracle tem bastante coisa, provavelmente vamos fazer uns testes com ele na empresa. Att. Anderson Santiago DBA Sênior www.ruevers.webs.com - Mensagem original De: Rogério Falconi <[EMAIL PROTECTED]> Para: oracle_br@yahoogrupos.com.br Enviadas: Sexta-feira, 13 de Junho de 2008 9:22:22 Assunto: [oracle_br] Hypirion Urgente... Pessoas, Estou precisando de material sobre Hypirion. Alguém tem pdf ou alguma coisa sobre este produto? Tipo instalação, e conceitos.. Aguardo com urgência... Obrigado Rogério [As partes desta mensagem que não continham texto foram removidas] Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento! http://br.mail.yahoo.com/ [As partes desta mensagem que não continham texto foram removidas]
