Rodrigo, é 64-bit e o Peak chega em torno de 2,8GB.
Resolvi o problema aqui realizando uns ajustes na memória (o problema era o grande número de paralelismo).... o Chiappa também mandou uma documentação e irei me aprofundar no assunto. Essa parte de administração da memória achei bastante difícil e interessante ao mesmo tempo. Mesmo tendo resolvido o problema, se puder me mandar as instruções para 32-bit.... acho que conhecimento nunca é demais ;) Nunca se sabe o dia de amanhã rs. Grande abraço e obrigado pela atenção. Carlos Martello. De: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em nome de Rodrigo Moreno Enviada em: quarta-feira, 12 de novembro de 2008 17:20 Para: oracle_br@yahoogrupos.com.br Assunto: RES: [oracle_br] Re: RES: ORA-04030 Carlos, Está com cara de falta de memoria. Eu tive esse problema aqui semana passada. Aliás, eu tenho este problema sempre com maquinas windows 32Bit. Qual o seu ambiente? Windows 32 ou 64 bit? Qual o tamanho que ocupa o binario do oracle? Se tiver o tlist.exe vai te ajudar, veja o tamanho do PeakVirtualSize Se for 32Bit. Este tem limitacao de 1.7G, se for o caso e o seu oracle.exe estiver proximo a isso, me avise que lhe passo as instruções de como habilitar o workaround disponivel para isso. []'s Rodrigo DBA Oracle Senior. --- Em oracle_br@yahoogrupos.com.br <mailto:oracle_br%40yahoogrupos.com.br> , "Carlos martello" <[EMAIL PROTECTED]> escreveu > > Caro chiappa, muito obrigado pelas explicações. > > > > Vou ler todo o material que você referenciou e ver o melhor a ser feito de acordo com o padrão de programação do pessoal daqui. > > > > Infelizmente o banco é liberado pra qualquer um fazer o que bem entender, então, já viu né? Mas aos poucos to mudando isso.... > > > > Mais uma vez, muito obrigado. > > > > Grande abraço. > > > Carlos Martello. > > > > De: oracle_br@yahoogrupos.com.br <mailto:oracle_br%40yahoogrupos.com.br> [mailto:oracle_br@yahoogrupos.com.br <mailto:oracle_br%40yahoogrupos.com.br> ] Em nome de jlchiappa > Enviada em: quarta-feira, 12 de novembro de 2008 10:33 > Para: oracle_br@yahoogrupos.com.br <mailto:oracle_br%40yahoogrupos.com.br> > Assunto: [oracle_br] Re: RES: ORA-04030 > > > > Colega, pra mim o seu problema era (e é, ainda) o PARALLEL_MAX_SERVERS > muito alto (vc o setou para 10x o número de CPUs, > http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:39946845137685#1171130000346589088 > e o senso comum sugerem que uma CPU pode ter 2, 3, quatro tarefas > simultãneas, 10 me parece um exagero, inclusive) - aí, com o DOP na > tabela setado como DEFAULT e com um montão de servers permitidos o > banco devia estar abrindo muitas dezenas de parallel slaves, cada um > deles é uma nova sessão, esse monte de sessões devem estar consumindo > a RAM alocada - INCLUSIVE, apesar de (só pra variar) vc NÂO nos dar a > versão, vc diz que está usando PGA automática, é documentado que o > banco dá só 30% do param de PGA para os slaves (nota Subject: > Automatic PGA Memory Management in 9i and 10g, Doc ID: Note:223730.1 > ), com um monte de processos concorrendo pela memória, que é só uma > fração do que vc especificou, não é difícil dar erro de falta de > RAM.... Vc setando o DOP para um valor fixo na tabela resolveu a > questão PARA AQUELAS TABELAS, vc ainda corre risco para outras > operações paralelas em outras tabelas, em índices... Sugestão : bota o > PARALLEL_MAX_SERVERS prum valor mais razoável, OU sete o DOP para > TODAS as tabelas/índices que podem ser usadas em parallel (colocando 1 > para aquelas que vc não quer), OU deixe todo mundo como DEGREE 1 (que > é não-paralelo) e acione via hint de PARALLEL o paralelismo apenas nos > SQLs em que vc o deseje, OU use o algoritmo de tunning de paralelismo > (parametro de automatic tunning), que aí ele controla o DOP de acordo > com o uso - veja lá o que é mais viável pra vc, no seu caso... > > []s > > Chiappa > --- Em oracle_br@yahoogrupos.com.br <mailto:oracle_br%40yahoogrupos.com.br> <mailto:oracle_br%40yahoogrupos.com.br> , "Carlos Eduardo P. Martello" > <carlos.martello@> escreveu > > > > Pessoal, bom dia.... > > > > > > > > Finalmente consegui resolver o problema que vem tirando meu sono > > (literalmente) já que os processos de carga rodam durante a madrugada. > > > > > > > > Fiz as seguintes alterações: > > > > > > > > Setei o parâmetro degree das tabelas de produção onde o valor era > DEFAULT > > para 8. > > > > > > > > Além disso minha memória e o SPFILE ficaram assim: > > > > > > > > Memória Instância Oracle: > > > > Shared Pool = 768mb > > > > Buffer cache = 1504mb > > > > Large pool = 64mb > > > > Java pool = 32mb > > > > > > > > SPFILE: > > > > *.audit_sys_operations=TRUE > > > > *.audit_trail='TRUE' > > > > *.background_dump_dest='F:\Oracle\admin\riprod27\bdump' > > > > *.compatible='9.2.0.0.0' > > > > > *.control_files='F:\Oracle\oradata\riprod27\control01.ctl','F:\Oracle\oradat > > a\riprod27\control02.ctl','F:\Oracle\oradata\riprod27\control03.ctl' > > > > *.core_dump_dest='F:\Oracle\admin\riprod27\cdump' > > > > *.cursor_space_for_time=FALSE > > > > *.db_block_size=16384 > > > > *.db_cache_size=1572864000 > > > > *.db_domain='' > > > > *.db_file_multiblock_read_count=64 > > > > *.db_name='riprod27' > > > > *.db_writer_processes=0 > > > > *.dbwr_io_slaves=0 > > > > *.dispatchers='(PROTOCOL=TCP) (SERVICE=riprod27XDB)' > > > > *.fast_start_mttr_target=300 > > > > *.hash_area_size=1048576 > > > > *.hash_join_enabled=TRUE > > > > *.instance_name='riprod27' > > > > *.java_pool_size=33554432 > > > > *.job_queue_processes=10 > > > > *.large_pool_size=67108864 > > > > *.log_checkpoint_timeout=0 > > > > *.max_dump_file_size='1048576' > > > > *.open_cursors=300 > > > > *.parallel_automatic_tuning=FALSE > > > > *.parallel_max_servers=80 > > > > *.parallel_threads_per_cpu=2 > > > > *.pga_aggregate_target = 536870912 > > > > *.processes=300 > > > > *.query_rewrite_enabled='FALSE' > > > > *.remote_login_passwordfile='EXCLUSIVE' > > > > *.session_max_open_files=20 > > > > *.sga_max_size=3221225472 > > > > *.shared_pool_size=805306368 > > > > *.sort_area_size=1048576 > > > > *.sql_trace=FALSE > > > > *.star_transformation_enabled='FALSE' > > > > *.timed_statistics=TRUE > > > > *.undo_management='AUTO' > > > > *.undo_retention=10800 > > > > *.undo_tablespace='UNDOTBS1' > > > > *.user_dump_dest='F:\Oracle\admin\riprod27\udump' > > > > > > > > Assim fica documentado e caso alguém sofra com esse "mal", podem ter > algumas > > idéias de como resolver o problema RS. > > > > > > > > Abraços a todos. > > > > > > > > De: Carlos martello > > Enviada em: terça-feira, 11 de novembro de 2008 15:05 > > Para: oracle_br@yahoogrupos.com.br <mailto:oracle_br%40yahoogrupos.com.br> <mailto:oracle_br%40yahoogrupos.com.br> > > Assunto: ORA-04030 > > Prioridade: Alta > > > > > > > > Boa tarde a todos. > > > > > > > > Pessoal, essa é minha primeira participação na lista e gostaria de > uma ajuda > > se possível. > > > > > > > > Tenho uns processos de carga que rodam durante a madrugada e em > paralelo. > > > > > > > > Processo A - começa as 20:30 > > > > Processo B - começa as 22:00 > > > > Processo C - começa as 06:00 > > > > > > > > Quando os processos A e B entram em paralelo, 99% das vezes recebo > erros do > > tipo ORA-04030. > > > > > > > > Já li bastante material, já pesquisei no histórico da própria lista, no > > metalink do Oracle e ainda não consegui resolver o problema. > > > > > > > > Vou passar alguns dados e talvez assim possam me ajudar: > > > > > > > > Servidor: > > > > WINDOWS 2003 Server 64-bit > > > > 8 processadores > > > > 8 GB RAM > > > > > > > > Memória Instância Oracle: > > > > Shared Pool = 768mb > > > > Buffer cache = 1504mb > > > > Large pool = 160mb > > > > Java pool = 32mb > > > > > > > > SPFILE: > > > > *.db_block_size=16384 > > > > *.db_cache_size=1572864000 > > > > *.db_domain='' > > > > *.db_file_multiblock_read_count=64 > > > > *.db_name='riprod27' > > > > *.db_writer_processes=0 > > > > *.dbwr_io_slaves=0 > > > > *.dispatchers='(PROTOCOL=TCP) (SERVICE=riprod27XDB)' > > > > *.fast_start_mttr_target=300 > > > > *.hash_area_size=1048576 > > > > *.hash_join_enabled=TRUE > > > > *.instance_name='riprod27' > > > > *.java_pool_size=33554432 > > > > *.job_queue_processes=10 > > > > *.large_pool_size=167772160 > > > > *.log_checkpoint_timeout=0 > > > > *.max_dump_file_size='1048576' > > > > *.open_cursors=300 > > > > *.parallel_automatic_tuning=FALSE > > > > *.parallel_max_servers=80 > > > > *.parallel_threads_per_cpu=2 > > > > *.pga_aggregate_target = 805306368 > > > > *.processes=300 > > > > *.query_rewrite_enabled='FALSE' > > > > *.remote_login_passwordfile='EXCLUSIVE' > > > > *.session_max_open_files=20 > > > > *.sga_max_size=3221225472 > > > > *.shared_pool_size=805306368 > > > > *.sort_area_size=1048576 > > > > *.sql_trace=FALSE > > > > *.star_transformation_enabled='FALSE' > > > > *.timed_statistics=TRUE > > > > *.undo_management='AUTO' > > > > *.undo_retention=10800 > > > > *.undo_tablespace='UNDOTBS1' > > > > *.user_dump_dest='F:\Oracle\admin\riprod27\udump' > > > > > > > > > > > > Atenciosamente, > > > > > > > > Carlos Martello. > > > > > > > > [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]
