Menu de navegação

[ramasineParticipante]

Caros colegas,

Tenho um banco de dados 9.2.0.8, com AIX 5.

Estamos tomando o erro abaixo:

ORA-04031: unable to allocate 16408 bytes of shared memory (“large
pool”,”unknown object”,”koh-kghu sessi”,”kod objects”).

Já pesquisei as seguintes opções:

BUGS: Não são o caso (acho eu), a versão 9.2.0.8, pesquisei e executei
os scripts recomendados no metalink..e nada!!

Esse erro acontece de forma intermitente, as vezes sim, as vezes não!!

Abaixo a minha configuração de SGA (que está manual):

Total System Global Area 9018781176 bytes
Fixed Size 753144 bytes
Variable Size 4009754624 bytes
Database Buffers 4999610368 bytes
Redo Buffers 8663040 bytes

Abaixo os parametros de SHARED:

NAME Type VALUE
———————————— ————————- ———-
hi_shared_memory_address integer 0
max_shared_servers integer 80
shared_memory_address integer 0
shared_pool_reserved_size big integer 107374176
shared_pool_size big integer 2701131776
shared_servers integer 40
shared_server_sessions integer 1243

Já usei o shared_pool_advisor do 9IR2 e não me da muitas saídas.
Já aumentei um pouco a large_pool, mas o erro permanece…
Já pinei alguns objetos com a dbms_shared_pool..os com mais uso de memória!
E fiz inumeros flushes na shared_pool..sem sucesso…o processo
arrebenta…da mesma forma!!

Há um detalhe, em pesquisa já vi (o banco de dados está em MTS), que o
consumo de large_pool em banco de dados com MTS é grande…
Há como forçar que determinado processo client faça as requisições ao
banco de dados de forma DEDICATED e não SHARED? Via algum parâmetro ou
algo do tipo?

Já estou cansado!! rss..Alguma luz e ajuda é bem-vinda!!
Obrigado

Marcelo

Existem alguns parametros como o _large_pool_min_alloc, que eu acho
que já está fora de uso no 9IR2…9.2.0.8…

[Regis AraujoParticipante]

Salve Ramazine.. bom dia..

Rode o comando abaixo no seu servidor.. caso o valor de PERCENTAGEM..


SELECT
MAX(B.VALUE)/(10241024) TAMANHO_SHARED_POOL,
SUM(A.BYTES)/(10241024) USADO_SHARED_POOL,
(MAX(B.VALUE)/(10241024)) - (SUM(A.BYTES)/(10241024)) LIVRE_SHARED_POOL,
((SUM(A.BYTES)/(10241024))/(MAX(B.VALUE)/(10241024)))*100 PERCENTAGEM_USADO_SHARED_POOL
FROM V$SGASTAT A, V$PARAMETER B
WHERE A.POOL= 'shared pool'
AND A.NAME NOT IN ('free memory')
AND B.NAME='shared_pool_size';


Este select irá te mostrar o valor de Shared_Pool

Rode um “Alter system flush shared_pool” se o comando não reduzir a PERCENTAGEM_USADO você terá que aumentar o tamanho do parametro SHARED_POOL_SIZE dentro do seu arquivo INIT.ora

Isto requer shutdown e restart do seu banco…

Abraços.. Espero ter ajudado…

[ramasineParticipante]

Regiz,

Segue o resultado, antes e depois do FLUSH:

TAMANHO_SHARED_POOL USADO_SHARED_POOL LIVRE_SHARED_POOL PERCENTAGEM_USADO_SHARED_POOL

---

           2576        686,164818        1889,83518                     26,636833                  

15:56:29 sql’@’BPOSING > /

TAMANHO_SHARED_POOL USADO_SHARED_POOL LIVRE_SHARED_POOL PERCENTAGEM_USADO_SHARED_POOL

---

           2576        253,930656        2322,06934                   9,85755654

[Regis AraujoParticipante]

Bom.. então o problema não está na Shared_Pool..

O erro acontece quando a memória compartilhada está baixo para o tanto de sessões rodando em seu servidor…

Altere o parametro de Large Pool.. primeiro vamos verificar qual o tamanho e depois altere…

rode este comando..

SELECT NAME,SUM(BYTES)/(1024)||’K’ FROM V$SGASTAT
WHERE POOL=’large pool’ GROUP BY ROLLUP (NAME) ;

Verifica o tamanho e se estiver muito pequeno.. altere para um tamanho razuavel.. eu costumo colocar 10x menos o tamanno da shared_pool..

Comando para alterar..

alter system large_pool_size = M ou K

Abraços..

[vieriParticipante]

Você está penando porque não leu o erro direito!

Quem está estourando é a LARGE_POOL.

peça um :

show parameters large_pool_size ;

em quanto ele está ?

deve está ai com uns 400Mb,
aumente sem pena para 1 ou 2Gb e verifique se ainda persiste.

MTS utliza large pool, assim como grande requisições em paralelismo
e operações do RMAN também utilizam, se seu ambiente tem essa característica vale a pena investir nele.

Como ele usa MTS que teóricamente consome menos shared_pool,
e mais large_pool.

O fato de vc está aumentando a shared_pool e pinar objetos em memôria você está nadando contra a correnteza.

😉

[Regis AraujoParticipante]

Opa..

Esqueci do SET.. heheh..

abaixo comando correto..

alter system set large_pool_size = M ou K;

Ahh..

O Vieri explicou muito bem.. heheh..!!

Abraços…

[ramasineParticipante]

Vieri e Régis, antes de mais nada obrigado!!

Vamos lá, no post inicial, tinha colocado:

Já aumentei um pouco a large_pool, mas o erro permanece…

Minha large está com o tamanho abaixo:

17:34:18 sql’@’bposing > show parameter large

NAME TYPE VALUE

---

large_pool_size big integer 1073741824

Estou tentando agora editar um dos data-sources da aplicação, para que na conexão ele force o modo DEDICATED, fazendo com que ele roube-me menos da large_pool…

[Rodrigo AlmeidaParticipante]

Olá,

Poderia mostrar os últimos registros do seu alert.log e os valores que v$parameter. Pode postar para termos uma idéia.

Para mudar as suas sessões de SHARED para DEDICATED, basta ir no servidor de aplicação, encontrar o TNSNAMES.ORA do cliente e na entrada no TNSNAMES que aponta para o seu banco de dados retirar a opção SERVER=SHARED, pode comentar essa linha.

Aì as sessões entrarão em DEDICATED!!!

Seu problema com a alocação de mémoria, é que a sua instância não está mais fornencendo espaço para a criação de novas sessões. Se passar os valores que estão no v$parameter nós conseguimos identificar o problema.

Abraços,

Rodrigo Almeida

[vieriParticipante]

Se mudar no tnsnames do client para dedicated
certamente o seu gargalo poderá ser a shared_pool,
ao invês do large_pool e poderá vir a ter sérios problemas com latch.

Se implementaram essa base com mts é porque a aplicação abre muita sessão, e assim sendo com servidor compartilhado
menos processos são abertos e menor consumo/carga na SGA.

Experimente aumentar a large_pool para 2GB
e monitore o seu uso.

[ramasineParticipante]

Obrigado mais um vez pela ajuda de todos, Rodrigo, Vieri, Régis….

Antes de mais nada a minha large pool:

NAME TYPE VALUE

---

large_pool_size big integer 1073741824

O que acontecia é que um client, quando executava um determinado
processo consumia toda ou quase toda a large pool disponível! Este
processo estava ligado a um WebService Java, que através de uma
ligação via data-source ao banco de dados, carregava uma package, com
uma série de cursores mal escritos…para além do fato de pedirmos e
orientarmos a equipe de desenvolvimento a rever o código, conseguimos
editar o data-source responsável pela conexão, na linha
connection_pool da chamada ao tnsnames do banco de dados, alteramos o SERVER para DEDICATED, a sugestão que refere a esta alteração foi
encontrada no metalink!

Obrigado
Marcelo

[jspaulonciParticipante]

Bom dia Ramasine…acompanhei o sei problema , e aí resolver aumentando a large_pool ? ou a saída foi reescrever o package ?

Abraços

[ramasineParticipante]

João,

A saída passou por:

• Recomendações a equipe de desenvolvimento par alterar a package;
• Aumentei a large_pool em 400Mb..e ainda quero aumentar mais..
• Alteração de um data-source (Webservices Java) para força-lo a se conectar ao banco de dados no modo DEDICATED..

E assim vamos lutando por aqui em terras lusitanas…!!

Obrigado
Marcelo Ramasine

[vieriParticipante]

Parabéns Ramasine atuou em todos os ramos do problema!

[jspaulonciParticipante]

Muito bom Ramasine, é isso aí….

[ramasineParticipante]

Eu é que agradeço a ajuda, que sempre, estão dispostos a oferecer!
Obrigado ao João, Rodrigo, Vieri, Régis…

Aqui em terras lusitanas, longe da família e desbravando o mato, sem muitos com quem possa contar na hora do incêndio…

Conheço os caminhos..mas os mais experientes já conhecem os atalhos!!

Sempre quando chego pela manhã..leio um texto que criei com base no salmo 23, com todo o respeito que ele merece..
Segue ai, talvez funcione pra vcs tb!!

O Metalink é meu salvador, nada me escapará
Deitar-me faz em estáveis bancos de dados, guia-me mansamente a
restores tranquilos.
Refrigera a minha mente; guia-me pelas veredas dos complex tunnings,
por amor a nossa profissão
Ainda que eu andasse pelo vale da sombra da morte, não temeria nenhum desenvolvedor, porque Tom Kyte está comigo; as suas notes e os seus exemplos me esclarecem;
Ilumina-me para que prepares um statspack report, e na mesa de
reunião, na frente dos Chief’s Developers eu os faça ajoelhar,
enche a minha cabeça com notes, artigos e dicas, para que meu cérebro
transborde;
Assim certamente que a paciência e a tolerância me seguirão todos os
dias da minha vida; e habitarei com paz meu posto de DBA por longos dias.

Abs
Marcelo Ramasine

[Autor]

Posts