Blz ? A pergunta primeira é : esses 32 GB de RAM que a VM tem é memória REAL, física, que foi SEPARADA/ALOCADA pra vm lá no servidor físico, sim sim ?? Nada de memória VIRTUAL aqui, plz….
Muito bem : isso sendo assim, de modo geral se não houver outros softwares e/ou outras instãncias Oracle (e portanto a RAM na máquina vai ser dedicada só pra essa única instância) a Recomendação inicial da Oracle é vc alocar pra uso interno dessa única instância (SGA) uns 40% da RAM – tendo 32 GB nessa máquina, isso daria uns 12 GB… E ** lembrando **, para que uma proção assim larga de memória possa ser efetivamente usada, todos os unix-like (ie Solaris, HP-UX, Linux a afaik AIX também) EXIGEM que os parâmetros de controle de memória do kernel (principalmente SHMMAX e SHMALL no linux/unix, vejá lá os equivalentes AIX) ESTEJAM adequadamente setados, okdoc ?? Se assegure disso…
A segunda decisão é como gerenciar essa RAM : quando vc tem SGA de grande porte (ie sensivemente mais que uns 3 ou 4 GB), o Sistema Operacional vai ter que consumir bastante CPU pra controlar isso dinamicamente/automaticamente, e pode se ficar sujeito às políticas de paging do SO – se vc acha que isso pode ocorrer neste ambiente que vc está construindo (digamos, vai ser um banco ultra-hiper-acessado, onde performance é de suma importância), vc pode implementar o controle manual da RAM, e usar HUGE PAGES (ou LARGE PAGES no jargão AIX) – https://blog.pythian.com/enabling-large-pages-oracle-database-11g-running-ibm-aix/ dá um exemplo….
==> A DESVANTAGEM de vc implementar hugepages/largepages é que normalmente Isso implica em PERDER o gerenciamento automático de memória, vc teria que desabilitar o AMM e assim setar Exatamente o quanto vc quer de SGA, PGA, workarea, java, etc…. SE esse database é simplesmente de teste ou estudos, de pequeno porte, onde a performance máxima não é o objetivo, nem esquente com isso e mantenha o AMM mesmo….
[]s
Chiappa
Leandro Pinto.
Leandro Pinto.
Leandro Pinto
Leandro Pinto
José Laurindo Chiappa