Menu de navegação

[mpunganParticipant]

Preciso alterar os parâmetros abaixo:

db_16k_cache_size de 60GB para 120GB
pga_aggregate_target de 6GB para 10GB
pga_aggregate_limit de 12GB para 20GB

Mas nunca lembro se os valores tem que ser baixados de sga_max_size e sga_target! Se tem que baixar também esses valores?

[José Laurindo ChiappaModerator]

Colega, depende totalmente dos pontos que vc (pra variar) não diz : qual versão de RDBMS Oracle vc tá usando ? Tá usando gerenciamento automático de memória (params MEMORY_TARGET e MEMORY_MAX_TARGET) ?? Tá usando gerenciamento de SGA automático (parâmetros SGA_TARGET e SGA_MAX_SIZE) ??
Com essas respostas podemos palpitar um pouco mais porém de modo geral : PGA é uma área que é alocada na memória (e portanto TEM que estar prevista nos params MEMORY_xxx, os aumente correspondentemente se vc os usar) mas é criada/consumida à parte da SGA, portanto SGA_xxx em princípio não precisa ser alterada…
Já os params de cache e/ou de pool ** TODOS ** (o que INCLUI db_16k_cache_size, claro) são TODOS alocados dentro da SGA, então se vc os aumentar TEM que subir SGA também , em princípio…

Agora – não é o que vc perguntou mas eu TENHo que observar :

a. db_16k_cache_size é um cache de dados ESPECÍFICO para tablespaces com blocos de 16k como banco que não use 16k como blocksize geral – vc tem Absoluta certeza de precisar disso ?

e

b. 120GB só pra ** UM ** dos caches de bloco me parece um tanto excessivo : vc tem quanto de RAM nesse servidor, 500 GB ? Um Tb ?? uau…. E 20 Gb pra PGA, que basicamente é para SORTs e variáveis de programas de usuários ??
Vc tá CERTO desses tamanhos ? Vc não tá “roubando” memória de outros caches/itens que poderiam ajudar mais, ou mesmo não tá causando nenhum tipo de paginação no seu sistema, não ??

[]s

Chiappa

[mpunganParticipant]

Versão do Banco:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 – 64bit Production
PL/SQL Release 12.1.0.2.0 – Production
“CORE 12.1.0.2.0 Production”
TNS for Linux: Version 12.1.0.2.0 – Production
NLSRTL Version 12.1.0.2.0 – Production

Sim, estou usando gerenciamento automático. Sim uso tablespaces de 16K. Isso é necessário.

Configuração atual do banco:
sga_max_size 340G
pga_aggregate_limit 12G
sga_target 340G
db_16k_cache_size 60G
pga_aggregate_target 6G

[José Laurindo ChiappaModerator]

Ok, mas e o ** resto ** das Informações, tal como blocksize desse database, tamanho da memória RAM real/física do servidor , o setting atual dos params memory* (já que vc diz que tá usando AMM), setting atual do param worksize* (pra ver se esses seus params PGA* estão sendo efetivamente usados) ?? Setting dos demais parâmetros relacionados à composição de SGA que estejam setados com valor não default (ie, pool, size, cache , buffer) ???? COM essas informações aí sim a gente pode te indicar o que tem que ser mudado (se é que precisa) pra vc poder aumentar o cache de 16k e a PGA que vc quer ….
E novamente, não é o que vc perguntou mas como eu tinha Observado antes eu TENHO que observar de novo : esses valores indicados são ANORMALMENTE ALTOS, eles estão ** efetivamente ** ‘batendo’ com a qtdade de RAM física ** livre ** que vc tem nesse servidor ??? Não que vc especificar um limite máximo irreal/falso/não condizente com a RAM física vá “quebrar”/bugar o RDBMS (o gerenciamento de RAM automático é um pouco mais esperto que isso) mas COM CERTEZA vc tá passando dados FALSOS pro Otimizador do RDBMS, ele tranquilamente pode (por exemplo) se enganar em relação à fração de dados que é provável dele encontrar em cache, em tamanhos para tabelas internas que ficam em memória e coisas assim – EU, pessoalmente, sempre penso que a Administração bem-feita e profissional de um database Oracle já é por si só desafiadora o Suficiente pra não ter que buscar por potenciais problemas dando configurações inconsistentes com o hardware….

[]s

Chiappa

OBS : a linha “TNS for Linux” nos informa que vc está usando Linux de 64-bits como SO – vc tá ciente que o procedimento RECOMENDADO no Linux para SGA gigante (de mais do que alguns GBs, o que parece ser seu caso) é usar LARGE PAGES, cfrme as notas metalink “HugePages on Linux: What It Is… and What It Is Not…” (Doc ID 361323.1) e “HugePages on Oracle Linux 64-bit” (Doc ID 361468.1) …. Isso tá OK ? Pois se não estiver é ** COMUM ** vc observar “engasgos” e má-performance geral devido à page stealing e/ou ao esforço necessário para o SO gerenciar tanta RAM…. #fikadika#

[mpunganParticipant]

O servidor tem um 1TB de memória, já esta tudo ajustado, de acordo com o recomendado, só estou com essa dúvida que realmente, nunca lembro se aumentar esses valores tenho que diminuir ou aumentar a sga_max_size e sga_target.

[mpunganParticipant]

Eu uso o Enterprise Manager, e esses valores foram sugeridos pelo Enterprise Manager para serem alterados.

[José Laurindo ChiappaModerator]

Esse é o ponto : **** não pense **** que o Enterprise manager tá fazendo nenhuma super-análise, que ele é uma inteligência artificial que não erra nunca…. Bem ao contrário, ele é um simples ** ASSISTENTE ** que dá Sugestões Simples, e (acima de tudo) ele ** não é Capaz** de avaliar o overhead de gerenciar qtdade grandes de RAM, ele ** não sabe ** o quanto reservar de RAM pro SO, não sabe se é mesmo só o RDBMS que rodas aí nesse servidor, então VIA DE REGRA ele NÂO SABE implementar LARGE/HUGE PAGES, não sabe setar corretamente kernel…. Fique Avisado…

Muito bem : já que *** AINDA *** ficou faltando informação (ie, o valor atualmente setado para os parâmetrosd memory*, cache , pool), que eu Perguntarei qual é pela 3a vez ( a 3a é a da Sorte, dize) ainda não dá pra gente AVALIAR se dentro desse setting de 320 GB para SGA há espaço suficiente para aumentar pra 120GB o db_16k_cache_size , ** E ** se a soma dos PGA* + SGA cabe no memory*…. Sacou ? Esta é a conta em princípio : SGA + PGA ** tem ** que caber nesse valor indicado pro MEMORY_TARGET e MEMORY_MAX_TARGET, e os componentes da SGA (ie, caches, pools, etc) TEM que caber no valor do SGA_MAX_SIZE + SGA_TARGET ….

Nos diga então COMO estão setados os demais parâmetros que vc não indicou que a gente faz a conta e te diz… ok ?

[]s

Chiappa

OBS :

é claro, imagino que vc SAIBA que ao setar valor pros parâmetros MEMORY* (ie, o MEMORY_TARGET e/ou o MEMORY_MAX_TARGET) vc ** ATIVA ** o AMM (Automatic Memory Management) : com essa tecnologia ativa, o próprio RDBMS gerencia a sua memória, os parâmetros cache, pool, SGA, PGA e demais ref. memória viram apenas Balizas, apenas Sugestões pro gerenciamento automático…..
Assim sendo, eu ** imagino ** que vc está setando esses parâmetros justamente para INFLUENCIAR o gerenciamenbto automático, de modo que ele já de cara se puder já reserve essas áreas de memória como vc indica – OU SEJA, não é que vc TENHA que se assegurar que SGA+PGA cabe dentro do memory, que os sub-componetes da SGA caibam no SGA_MAX (afinal o gerenciamento automático em tese cuida disso), a questão aqui é INFLUENCIAR o AMM para que ele se comporte mais como vc quer, é uma Customização digamos assim….

[mpunganParticipant]

Envio os parâmetros, para dar uma olhada.

[José Laurindo ChiappaModerator]

Nope, não recebi nada – via de regra o Fórum bloqueia anexos, por questão de Segurança : sobe o arquivo com os params pra algum site de compartilhamento e manda o link, OU então extrai em formato-texto os params não-default e seus valores, depois copia/cola numa outra mensagem – pra se fazer isso, uma opção é conectar no banco via sqlplus com usuário privilegiado e executar um :

set pages 999 lines 100
col name format a30
col value format a50
select name
, value
from v$parameter
where isdefault = ‘FALSE’
and value is not null
order by name
/

Aí copia e cola o resultado numa nova mensagem….

[]s

Chiappa

[mpunganParticipant]

Segue a lista de parâmetros.

O7_DICTIONARY_ACCESSIBILITY TRUE
kks_obsolete_dump_threshold 0
_optimizer_aggr_groupby_elim FALSE
audit_file_dest /soft/oracle/app/oracle/admin/BP1N/adump
audit_trail DB, EXTENDED
cluster_database TRUE
cluster_interconnects 10.10.11.26
compatible 12.1.0.2.0
control_files +DATA1N/bp1n/controlfile/current.256.858959175, +INDX1N/bp1n/controlfile/current.256.858959175
cursor_sharing SIMILAR
db_16k_cache_size 64424509440
db_block_size 8192
db_create_file_dest +DATA1N
db_create_online_log_dest_1 +DATA1N
db_create_online_log_dest_2 +INDX1N
db_file_multiblock_read_count 16
db_name BP1N
db_recovery_file_dest /soft/oracle/app/oracle/fra
db_recovery_file_dest_size 17592186044416
diagnostic_dest /soft/oracle/app/oracle
dispatchers (PROTOCOL=TCP) (SERVICE=BP1NXDB)
instance_number 2
java_jit_enabled TRUE
log_archive_dest_1 LOCATION=+ARCH1 REOPEN
log_archive_dest_2 LOCATION=+ARCH2 REOPEN
log_archive_format %t%s_%r.arc
open_cursors 300
parallel_max_servers 64
parallel_servers_target 2
pga_aggregate_target 6442450944
processes 1000
remote_listener racpn1-scan:2570
remote_login_passwordfile EXCLUSIVE
resource_limit TRUE
sessions 1536
sga_max_size 365072220160
sga_target 365072220160
thread 2
undo_tablespace UNDOTBS2

[José Laurindo ChiappaModerator]

Opa, agora sim : ** sem ** adivinhação na parada, estamos vendo a coisa real – nada como se poder DISPOR de barro pra fazer tijolos, tava Bem Difícil atuar sem a info mínima…
Muito bem : primeira coisa, eu vejo que vc ** NÂO TEM ** os parâmetros MEMORY* setados, portanto (** AO CONTRÁRIO ** do que vc tinha dito antes) vc NÂO ESTÁ usando Automatic Memory Management… Não estando presente AMM, é só mesmo somar os componentes da PGA (e ver se eles cabem no target/max_size proposto) E também somar os componentes da SGA e ver se eles cabem nos limites propostos – sem AMM, não haverá per se um controle do máximo de RAM que SGA+PGA podem alocar, além dos settings de kernel, do ulimit e dos limites da SGA e da PGA em si…

No caso, começando pela PGA, vc tem :

pga_aggregate_target 6.442.450.944

não especifica WORKAREA_SIZE_POLICY (portanto assume-se o default de AUTO, com gerenciamento automático portanto de sort area/hash area/variáveis na PGA)

e quer passar PGA_AGGREGATE_TARGET dos cerca de 6 Gb atuais para 12 Gb – ok, sem AMM nada mais é necessário alterar, é só se certificar que kernel e ulimit/users params no Linux o permitem, E QUE (se em uso) qtdade de hugepages disponível comporta…. Nada mais….

Para a SGA, hoje vc tem :

sga_max_size = SGA_TARGET = 365.072.220.160 (ie, cerca de 340 Gb)

e dentro desses + ou – 340 Gbs a única área fixa é :

DB_16K_CACHE_SIZE 64.424.509.440

ou seja, cerca de 60 Gb para 16k cache – o resto da SGA, que é coisa de quase 300 Gb como vc não tem nenhum parâmetro cache mais definido, nem pool, nem area ou nenhum outro relacionado tão sendo gerenciados automaticamente…
Vc tinha dito que quer passar db_16k_cache_size para 120GB – ok, como o setting de 340 Gb ainda comporta RAM para os usos automáticos mesmo acrescendo esse aumento então a sua resposta é NÃO , vc Não é tecnicamente Obrigado a aumentar os params de SGA* para repassar DB_16K_CACHE_SIZE para 60 Gb….

Se as condigs de kernel/ulimit/hugepages o permitirem (E dando de barato que Existem Razões de peso para trabalhar com este tipo de config sem AMM), dada a Abundante memória de 1 Tb (a qual, se só tem o RDBMS no servidor, vai estar em grande parte livre, imagino) eu recomendo que vc aumente proporcionalmente os params de SGA*, adicionando mais 60 Gb neles para refletir os 60 Gb a mais que vc vai colocar no DB_16K_CACHE, mas repito, isso Não é Obrigatório tecnicamente….

[]s

Chiappa

[Author]

Posts