lkey 0 Denunciar post Postado Julho 22, 2008 Bom dia Pessoal, Sempre acompanhei esse forum e acho que é um dos melhores da Web, mais só agora resolvi me cadastrar! Tenho um Oracle 10g rodando em cima de windows 2003 server 32 bits, o Oracle esta rodando em modo compartilhado, mais mesmo assim, quando rodo algumas queryes que movimentam grande volume de informação, depois de um certo tempo, a instacia acusa erro ORA-04030 e entra em modo de shutdown!!!! Como poderia resolver isso? :unsure: Agradeço a ajuda desde já!! lkey Compartilhar este post Link para o post Compartilhar em outros sites
Motta 645 Denunciar post Postado Julho 22, 2008 Do manual : ORA-04030 out of process memory when trying to allocate string bytes (string,string) Cause: Operating system process private memory has been exhausted. Action: See the database administrator or operating system administrator to increase process memory quota. There may be a bug in the application that causes excessive allocations of process memory space. Fonte http://download-east.oracle.com/docs/cd/B10501_01/index.htm Compartilhar este post Link para o post Compartilhar em outros sites
lkey 0 Denunciar post Postado Julho 22, 2008 Do manual : ORA-04030 out of process memory when trying to allocate string bytes (string,string) Cause: Operating system process private memory has been exhausted. Action: See the database administrator or operating system administrator to increase process memory quota. There may be a bug in the application that causes excessive allocations of process memory space. Fonte http://download-east.oracle.com/docs/cd/B10501_01/index.htm Obrigado Motta, eu ja tinha lido o manual, mais nao sei se fiz tudo certo, eu ja redimensionei a memoria de varias maneiras, o pior é que se o oracle estiver como Dedicado esse erro nao ocorre :blink: Minha configuração esta assim: 1500 SGA 450 PGA 400 Large_pool_size Obrigado! Compartilhar este post Link para o post Compartilhar em outros sites
Motta 645 Denunciar post Postado Julho 22, 2008 Não sei Ikey , aqui a gente tem um DBA part-time para ver estes tipos de coisas, até queria mas não tenho tempo de acompanhar isto, nesta parte de configuração saco muito pouco. Compartilhar este post Link para o post Compartilhar em outros sites
lkey 0 Denunciar post Postado Julho 22, 2008 Não sei Ikey , aqui a gente tem um DBA part-time para ver estes tipos de coisas, até queria mas não tenho tempo de acompanhar isto, nesta parte de configuração saco muito pouco. Ok, fico no aguardo de alguem me ajudar! Obrigado! Compartilhar este post Link para o post Compartilhar em outros sites
alphamek 2 Denunciar post Postado Julho 23, 2008 Olá Ikey, Seguinte, seu banco de dados está em MTS e mesmo assim está com problemas de conexão. Se estiver em modo dedicado tu não tem esse problema, porém, acho que não chega a atender o volume total de usuários. Primeiramente, quantos DISPATCHERS estão sendo utilizados e a quantidade de sessões cada dispacthers está "segurando", isso poderá ver usando a ferramenta LSNRCTL (Listener em CMDLINE). Seu SGA está com 1.8GB, sua máquina é 32-Bits ou 64-Bits, e qual SO? O grande problema aí é a requisição de mais memória para os processos do Oracle (Tenho em mente que seu SO deva ser Windows), então, se tiver mais que 3GB em harware, poderá configurar o Windows para usar AWE e ter seu SGA superior a 2GB, OU, no boot.ini do windows colocar na inicialização /3G para assumir mais 1GB para os aplicativos e diminuir o recurso de memória para o kernel. Depois, existem outras maneiras que é utilizar o orastack para diminuir o recurso de memória que os binários utilizam e começar a customizar o SO desabilitam recursos desnecessários. Abraços, :lol: Compartilhar este post Link para o post Compartilhar em outros sites
lkey 0 Denunciar post Postado Julho 24, 2008 Olá Ikey, Seguinte, seu banco de dados está em MTS e mesmo assim está com problemas de conexão. Se estiver em modo dedicado tu não tem esse problema, porém, acho que não chega a atender o volume total de usuários. Primeiramente, quantos DISPATCHERS estão sendo utilizados e a quantidade de sessões cada dispacthers está "segurando", isso poderá ver usando a ferramenta LSNRCTL (Listener em CMDLINE). Seu SGA está com 1.8GB, sua máquina é 32-Bits ou 64-Bits, e qual SO? O grande problema aí é a requisição de mais memória para os processos do Oracle (Tenho em mente que seu SO deva ser Windows), então, se tiver mais que 3GB em harware, poderá configurar o Windows para usar AWE e ter seu SGA superior a 2GB, OU, no boot.ini do windows colocar na inicialização /3G para assumir mais 1GB para os aplicativos e diminuir o recurso de memória para o kernel. Depois, existem outras maneiras que é utilizar o orastack para diminuir o recurso de memória que os binários utilizam e começar a customizar o SO desabilitam recursos desnecessários. Abraços, :lol: ~ Ola Alphamek, Sim, meu SO é Windows 2003 32 bits!! Tenho 5 dispatchers diponiveis, porém, nao consegui ver quantas sessoes cada um esta segurando conforme você indicou, usei o lsnrctl e achei mil opções, menos essa que você disse.. você pode me ajudar a achar essa opção?? Com relação a memória tbem acho que precisa subir, porém, quando consulto a v$pgastat, ele nao esta estourando o uso da PGA e quando consulto as views v$statname e v$sesstat para consultar quanto as sessoes estao consumindo de PGA, ele mostra um valor muito alto, tipo por essa consulta, o que entendo é que a PGa esta muito estourada, porém a UGA quase nao esta sendo utilizada.... Nao entendo isso, se tenho uma large_pool_size razoavel para ele alocar a UGA, como ele pode usar tanto a PGA assim?? Esse é o select que monto para verificar isso que falei: select sum(value)/1024/1024 from v$statname a, v$sesstat b where a.statistic# = b.statistic# and name like '%session%pga%memory%'; o que fazer?? Obrigado pela ajuda!!! abs Compartilhar este post Link para o post Compartilhar em outros sites
lkey 0 Denunciar post Postado Agosto 11, 2008 Olá Ikey, Seguinte, seu banco de dados está em MTS e mesmo assim está com problemas de conexão. Se estiver em modo dedicado tu não tem esse problema, porém, acho que não chega a atender o volume total de usuários. Primeiramente, quantos DISPATCHERS estão sendo utilizados e a quantidade de sessões cada dispacthers está "segurando", isso poderá ver usando a ferramenta LSNRCTL (Listener em CMDLINE). Seu SGA está com 1.8GB, sua máquina é 32-Bits ou 64-Bits, e qual SO? O grande problema aí é a requisição de mais memória para os processos do Oracle (Tenho em mente que seu SO deva ser Windows), então, se tiver mais que 3GB em harware, poderá configurar o Windows para usar AWE e ter seu SGA superior a 2GB, OU, no boot.ini do windows colocar na inicialização /3G para assumir mais 1GB para os aplicativos e diminuir o recurso de memória para o kernel. Depois, existem outras maneiras que é utilizar o orastack para diminuir o recurso de memória que os binários utilizam e começar a customizar o SO desabilitam recursos desnecessários. Abraços, :lol: ~ Ola Alphamek, Sim, meu SO é Windows 2003 32 bits!! Tenho 5 dispatchers diponiveis, porém, nao consegui ver quantas sessoes cada um esta segurando conforme você indicou, usei o lsnrctl e achei mil opções, menos essa que você disse.. você pode me ajudar a achar essa opção?? Com relação a memória tbem acho que precisa subir, porém, quando consulto a v$pgastat, ele nao esta estourando o uso da PGA e quando consulto as views v$statname e v$sesstat para consultar quanto as sessoes estao consumindo de PGA, ele mostra um valor muito alto, tipo por essa consulta, o que entendo é que a PGa esta muito estourada, porém a UGA quase nao esta sendo utilizada.... Nao entendo isso, se tenho uma large_pool_size razoavel para ele alocar a UGA, como ele pode usar tanto a PGA assim?? Esse é o select que monto para verificar isso que falei: select sum(value)/1024/1024 from v$statname a, v$sesstat b where a.statistic# = b.statistic# and name like '%session%pga%memory%'; o que fazer?? Obrigado pela ajuda!!! abs Ola Alphamek, você ainda pode me ajudar com esse problema? Obrigado http://forum.imasters.com.br/public/style_emoticons/default/grin.gif abs Compartilhar este post Link para o post Compartilhar em outros sites