This morning we received more RAM on our production database server from 64G to 96G total memory available.
This VM guest is a RHEL release 7.3 version 3.10.0-514.2.2.el7.x86_64
The oracle database version is 12.1.0.2.0 Enterprise Edition
We have 3 oracle non-CDB databases running on this VM guest.
We changed our init parameters on each of the three dB servers as follows and re-started the dB's:
ini.parameter Database # 1 Database # 2 Database # 3
value old/new old/new old/new
----------------- ------------------ ------------------- -------------------
sga_max_size 48G/64G 8G/10G
sga_target 48G/48G 8G/ 8G
pga_aggregate_target /2G 1G/1G
memory_target 0/0 0/0 0/0
memory_max_target 0/0 0/0 0/0
java_pool_size 0/0 0/0 0/0
After the oracle databases re-started, we then modified Linux Huge Pages per MOS (Doc ID 401749.1) as follows:
$ ./hugepages_settings.sh
Recommended vm.nr_hugepages = 39948
The setting on the database server is:
$ grep Hugepagesize /proc/meminfo | awk '{print $2}'
2048
MOS (Doc ID 361323.1)
says,
- HugePages can be allocated on-the-fly but they must be reserved during system startup. Otherwise the allocation might fail as the memory is already paged in 4K mostly.
QUESTION: Since the databases were re-started BEFORE making the HugePages change, does this mean the memory allocated to each of the databases IS NOT allocated to vm.nr_hugepages = 39948 ? Should we have bounced the server and/or the databases once more after making the change? {NOTE: We did run the sysctl -p command as root after making the change, does this substitute the need for an actual server and/or database re-start ? }