Bom, primeiro dá alguns esclarecimentos Importantes :
=> desses 96 GB, QUANTO vc já tem comprometido/usado pelas coisas afora a
instância que vc está tunando (ie, Sistema Operacional, ASM, Clusterware,
eventuais daemons/agentes/alikes que a Aplicação exige que estejam presentes
no(s) servidore(s), outras Instâncias de menor criticidade) ???? Isso é
CRÍTICO, de nada adianta vc ter 96 GB mas ter x% usado para outras coisas, a
gente TEM que saber quanto está "livre" para direcionarmos na instância-alvo...
=> vc diz que "Esta maquina" (singular) "tem 96 G de RAM", mas se é RAC de 3
nós, vc tem que ter 3 máquinas... Cada nó é uma VM, e o servidor físico com 96
GB, é isso ?? Se sim, QUANTO tem cada VM ??? Ou não é isso, vc Realmente tem 3
servidores cada um com 96 GB ??
=> notar que "máquina" ABSOLUTAMENTE NÃO PEDE coisa alguma para "aumentar
SGA+PGA" : o servidor em si é controlado pelo Sistema Operacional, que
DESCONHECE o que é SGA ou PGA.... EU ** IMAGINO ** que na verdade é algum
software na máquina que faz Recomendações de tuning que está fazendo essa
Recomendação, confere ??? Sendo isso, Qual é o dito cujo ??
De cara já Aviso que se o software em questão for o Advisor da Oracle (seja
acessado diretamente, seja acessado pelo OEM, não importa) ele é meio
"burrinho", no sentido que ao detectar aumento de I/O ele já sai sugerindo
aumentar SGA, sem levar muito em conta a utilização efetiva do cache... Isso é
notável principalmente em ambientes DW, onde NECESSARIAMENTE vc está
trabalhando com grandes volumes (que DE JEITO NENHUM cabem no cache, E onde
full table scans - que bypassam cache - abundam) : o Advisor não tá nem aí, ele
sai mesmo recomendando aumentar SGA, se vc for atrás dele num ambiente que não
pode se aproveitar muito de cache, vc fica doidinho
=> SE vc Realmente for deixar as áreas de memória (especialmente a SGA, claro)
num volume de dezenas de GB, a Oracle *** RECOMENDA *** que vc implemente
Hugepages : a nota metalink "HugePages on Oracle Linux 64-bit" (Doc ID
361468.1) é cristalina a respeito :
"Why Do You Need HugePages?
HugePages is crucial for faster Oracle database performance on Linux if you
have a large RAM and SGA. If your combined database SGAs is large (like more
than 8GB, can even be important for smaller), you will need HugePages
configured. Note that the size of the SGA matters. Advantages of HugePages are:
Larger Page Size and Less # of Pages: Default page size is 4K whereas the
HugeTLB size is 2048K. That means the system would need to handle 512 times
less pages.
Reduced Page Table Walking: Since a HugePage covers greater contiguous
virtual address range than a regular sized page, a probability of getting a TLB
hit per TLB entry with HugePages are higher than with regular pages. This
reduces the number of times page tables are walked to obtain physical address
from a virtual address.
Less Overhead for Memory Operations: On virtual memory systems (any modern
OS) each memory operation is actually two abstract memory operations. With
HugePages, since there are less number of pages to work on, the possible
bottleneck on page table access is clearly avoided.
Less Memory Usage: From the Oracle Database perspective, with HugePages,
the Linux kernel will use less memory to create pagetables to maintain virtual
to physical mappings for SGA address range, in comparison to regular size
pages. This makes more memory to be available for process-private computations
or PGA usage.
No Swapping: We must avoid swapping to happen on Linux OS at all Document
1295478.1. HugePages are not swappable (whereas regular pages are). Therefore
there is no page replacement mechanism overhead. HugePages are universally
regarded as pinned.
No 'kswapd' Operations: kswapd will get very busy if there is a very large
area to be paged (i.e. 13 million page table entries for 50GB memory) and will
use an incredible amount of CPU resource. When HugePages are used, kswapd is
not involved in managing them. See also Document 361670.1
"
Eu *** IMAGINO *** que é por isso (ie, por causa da incompatibilidade de
hugepages com AMM (vide nota "HugePages and Oracle Database 11g Automatic
Memory Management (AMM) on Linux" (Doc ID 749851.1) que o teu DBA desabilitou o
gerenciamento automático de memória (ie, zerou o memory target)... Agora, e o
resto do setup de hugepages, tá feito ?? Feito DIREITO ???? Aponte pra ele as
notas metalink "HugePages on Linux: What It Is... and What It Is Not..." (Doc
ID 361323.1) , "Shell Script to Calculate Values Recommended Linux HugePages /
HugeTLB Configuration" (Doc ID 401749.1) e os links delas...
=> tipicamente, DW implica em UMA, ou em MUITO POUCAS sessões rodando SQLs
mega-complexos, então pode valer a pena usar workspace management manual e
manualmente setar sort_area_size / hash_area_size em valores superaltos, pode
ser de grande uso Paralelismo (então um large cache maior pode ser útil)....
Esse tipo de análise deve ser feita no local....
Minha crítica maior inicialmente sobre isso nos parâmetros que vc mostra é o
parallel_max_servers de 1200 e o parallel_servers_target de 900 : vc TEM
hardware suficiente pra bancar isso ???? Veja que CADA parallel slave não só
ocupa RAM mas ocupa Também CPU, é um elemento a mais Atacando o seu sub-sistema
de I/O.... ASSEGURE-SE que realmente teu hardware Suporta essa config tão
permissiva em questão de Parellel SQL...
[]s
Chiappa
