Gb não usado no momento, isso **** NÂO **** quer dizer que essa RAM
estava e estaria sempre inativa , e que vc poderia portanto aumentar
em 1 Gb os caches do banco. ACONTECE que em conexão dedicada a RAM
que a sessão usa é retirada do SO só quando ela conecta (e mais tarde
ainda mais é retirado do SO conforme for necessário), assim dessa RAM
que estava sem uso no momento, vc TEM QUE deixar um pouco para
eventuais futuras conexões, certo ??? Pelo jeito foi exatamente esse
o seu erro, vc NÂO DEIXOU RAM suficiente reservada para futuras
conexões, quando elas aconteceram não havia RAM livre no sistema, no
way to go, no pass, no soup for you....
Quanto à SORT_AREA_SIZE, vc diz "tamanho da Sort_Area_Size....para
que não fique muito grande o espaço desperdiçado de memória para quem
não a esteja utilizando?", isso parece indicar que vc está achando
que o sort_area_size é uma porção de RAM que é imediatamente ocupada
assim que a sessão conecta, mesmo que não esteja usando, isso é
absolutamente FALSO, ERRADO, NÃO-VERDADEIRO, como mostrado em
http://asktom.oracle.com/pls/ask/f?
p=4950:8:::::F4950_P8_DISPLAYID:9195350400185 : sort_area-size é um
LIMITE MÁXIMO apenas, se uma sessão não precisar de sort ou de hash
ou similares ela vai consumir ZERO bytes desse limite, se a sessão
precisar de 64 Kb é APENAS 64 Kb que ela vai alocar, AINDA QUE vc
tenha sort_area_size de 100 Mb, confere ????
De recomendações eu diria pra vc então : primeiro, já que o
switch /3G normalmente não é exatamente 3Gb que ele te dá
(normalmente tem algum consumozinho por parte do sistema), digamos
que vc consiga um máximo de 2.8 Gb, ie, 3.006.477.108 bytes. desse
total, como eu disse, vc TEM QUE reservar espaço pras futuras
conexões E pra SGA toda (que NÃO É só block buffers, ela é (falando
das coisas principais) block buffer + shared pool + log buffer + área
fixa : sendo assim, em cima da recomendação padrão (que é vc deixar
mais ou menos 1/3 da RAM pra SGA, reservando o resto pra futuras
conexões e necessidades do tipo), eu diria pra vc dar uns 300 Mb para
block buffers, uns 400 Mb para shared pool , 2 Mb para log_buffer, e
inicialmente 4 Mb para sort_area_size, mais a área fixa isso deve dar
+ ou - 1/3 da RAM. Feito isso, em cima dessa situação vc (se é vc o
DBA) vai monitorando o comportamento de sort, o consumo de RAM por
sessão (e NÃO SÓ "consumo do Oracle" geral, como ao que parece vc
está fazendo!), se necessário vai ajustando, pra isso se usa
principalmente a v$session, v$sesstat joineada com v$statname, e a
v$session_wait pode dar algumas dicas relacionadas. A nível de SO, já
que TODAS as sessões do banco são threads dum único processo
oracle.exe , E o win não te dá o consumo por thread, vc TEM QUE
baixar algo a mais pra acompanhar isso, eu sugiro os utilitários de
www.sysinternals.com e o freeware ProcessStudio.
Afora isso, db_multiblock_read de 8 é o default e é normalmente
PÉSSIMO, altere isso. Esse setting tão importante deixado como
default ** SUGERE ** fortemente que esse banco está com outros também
default, pra quanto antes o DBA teria que os ver, também - ao menos
principalmente (já que é banco 8i) o optimizer_features_enable,
compatible, hash_join_enabled, query_rewrite_nn (pra poder usar
FBIs), e se estiver usando CBO, os params de CBO, em outras msgs aqui
do Forum a gente já teve discussões a respeito.
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, Diones Kleber Machado da Cruz
<[EMAIL PROTECTED]> escreveu
>
> Valeu Chiappa,
>
> Realmente é 32 bits SO, mas esta referenciado no boot o /3gb
conforme linha
> abaixo.
>
> [operating systems]
> multi(0)disk(0)rdisk(0)partition(2)\WINNT="Microsoft Windows 2000
Advanced
> Server" /fastdetect /3gb
>
> -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
*-*-*-*-*
>
> Estava aumentando a SGA exatamente para agilizar os processos de
fim de mês
> pois, a máquina apresentava uma utilização de 1.6Mb da memória para
o Oracle
> e 350Mb para o restante dos processos, incluindo os processos do
SO, me
> sobrava 1Gb da memória para melhorar a performance. Só que ao
modificar
> estes parametros, após uma determinada hora, os usuários não
puderam mais
> conectar no banco, sei lá, se por quantidade de conexões com o mesmo
(pouco
> provável) ou por falta de espaço na memória(mais provável).
>
> -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
*-*-*-*-*
>
> Quanto a Sort_Area_Size, como tenho aproximadamente 400 usuários
conectados
> ao banco, cada um alocará a sua área de sort, então pergunto.
>
> Tens alguma sugestão para o tamanho da Sort_Area_Size seguindo os
parametros
> abaixo, para que não fique muito grande o espaço desperdiçado de
memória
> para quem não a esteja utilizando?
>
> Oracle 8.1.7.4
> Windows Server 2000
> 3000 gb de RAM
>
> db_block_buffers = 204800
> db_block_lru_latches = 4
> db_block_size = 4096
> db_files = 1024
> db_file_multiblock_read_count = 8
> dml_locks = 200
> distributed_transactions = 10
>
> shared_pool_size = 377487360
> large_pool_size = 20971520
> java_pool_size = 10000000
>
>
>
> Att.
> Diones Kleber Cruz
> ----------------------------------------------------------
> DBA Oracle 9i
> Desenv de Sistemas Senior
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> ----------------------------------------------------------
> JOSAPAR - ARROZ TIO JOÃO
> Joaquim Oliveira S/A Participações
> Fone: (53) 3284-1044
> ----------------------------------------------------------
>
>
> -----Mensagem original-----
> De: jlchiappa [mailto:[EMAIL PROTECTED]
> Enviada em: terça-feira, 2 de maio de 2006 13:00
> Para: oracle_br@yahoogrupos.com.br
> Assunto: [oracle_br] Re: Erro 125040
>
> Vc não diz, mas ** imagino ** que seja um Sistema Operacionale um
> hardware de 32 bits, certo ?? Em sendo isso, SOs do tipo em
hardwares
> do tipo por default são LIMITADOS em relação à qtdade de RAM que
> podem alocar duma só vez sem configuração especial (normalmente
esse
> limite é de pouco menos de 2 Gb, coisa do tipo) - assim, o problema
> que vc está tendo deve ser simplesmente que o SO/hardware NÃO está
> conseguindo alocar a qtdade de RAM que vc especifica, ajuste-o - no
> caso de windows, normalmente vc deve adicionar um switch /PAE
ou /3G
> ou similares no arquivo de config de boot do sistema.
> Isto posto, aconselho vc a repensar a sua estratégia nesse
> servidor, penso ser QUESTIONÁVEL vc querer deixar uma porção tão
> grande da RAM do seu sistema dedicada à caches e coisa do tipo,
pois
>
> a) vc fica VULNERÁVEL à erros de falta de RAM se a qtdade de
> conexões subir um pouco, o que é natural de acontecer em picos de
fim
> de mês & coisas do tipo
>
> e
>
> b) vc está deixando a área de sort À MÍNGUA, fatalmente vc está
DES-
> ESTIMULANDO o banco a usar hashes e contrutos em RAM nos seus SQLs.
> 500 k é MUITO POUCO normalmente, isso é tamanho de RAM pra AGENDAS
DE
> BOLSO ... sort_area e hash_areas devem estar na casa dos MEGABYTES
> via de regra, a não ser que algum fator externo impeça.
>
> []s
>
> Chiappa
>
> --- Em oracle_br@yahoogrupos.com.br, Diones Kleber Machado da Cruz
> <[EMAIL PROTECTED]> escreveu
> >
> > Ae galera,
> >
> >
> >
> > Oracle 8.1.7.4
> >
> > Windows Server 2000
> >
> > 3000 gb de RAM
> >
> >
> >
> > Modifiquei o init da minha base para
> >
> >
> >
> > db_block_buffers = 300000
> >
> > db_block_lru_latches = 4
> >
> > db_block_size = 4096
> >
> > db_files = 1024
> >
> > db_file_multiblock_read_count = 8
> >
> > dml_locks = 200
> >
> > distributed_transactions = 10
> >
> >
> >
> > shared_pool_size = 512000000
> >
> > large_pool_size = 20971520
> >
> > java_pool_size = 10000000
> >
> >
> >
> > sort_area_size = 524288
> >
> > sort_area_retained_size = 524288
> >
> >
> >
> > E olha o erro que começou a aparecer.
> >
> >
> >
> > TNS-12500: TNS:listener failed to start a dedicated server process
> >
> > TNS-12540: TNS:internal limit restriction exceeded
> >
> > TNS-12560: TNS:protocol adapter error
> >
> > TNS-00510: Internal limit restriction exceeded
> >
> > 32-bit Windows Error: 8: Exec format error
> >
> >
> >
> > A base possui em torno de 370 conexões simultâneas.
> >
> >
> >
> >
> >
> > O que poderá estar ocorrendo???
> >
> >
> >
> >
> >
> > Diones Kleber Cruz
> >
> > ----------------------
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
>
>
>
>
>
>
> --------------------------------------------------------------------
--------
> ----------------------------------------------
> Atenção! As mensagens deste grupo são de acesso público e de inteira
> responsabilidade de seus remetentes.
> Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/
> --------------------------------------------------------------------
--------
> ----------------------------------------------
______________________________
> ____________________________________
>
> Este Grupo recebe o apoio da SQL Magazine -
www.devmedia.com.br/sqlmagazine
> __________________________________________________________________
> O grupo Oracle_br não aceita anexos. Quando oferecer algum arquivo,
tenha o
> link do mesmo para evitar trafego(pedidos) desnecessário.
> Links do Yahoo! Grupos
>
--------------------------------------------------------------------------------------------------------------------------
Atenção! As mensagens deste grupo são de acesso público e de inteira responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/
--------------------------------------------------------------------------------------------------------------------------__________________________________________________________________
Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine
__________________________________________________________________
O grupo Oracle_br não aceita anexos. Quando oferecer algum arquivo, tenha o link do mesmo para evitar trafego(pedidos) desnecessário.
| Yahoo! Grupos, um serviço oferecido por: | |
|
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:
[EMAIL PROTECTED]
- O uso que você faz do Yahoo! Grupos está sujeito aos Termos do Serviço do Yahoo!.
