Lock_sga

LOCK_SGA locks the entire SGA into physical memory. It is usually advisable to lock

the SGA into real (physical) memory, especially if the use of virtual memory would

include storing some of the SGA using disk space. This parameter is ignored on

platforms that do not support it.

PRE_PAGE_SGA

PRE_PAGE_SGA determines whether Oracle reads the entire SGA into memory at

instance startup. Operating system page table entries are then prebuilt for each page of the SGA. This setting can increase the amount of time necessary for instance startup,

but it is likely to decrease the amount of time necessary for Oracle to reach its full

performance capacity after startup.

PRE_PAGE_SGA can increase the process startup duration, because every process that

starts must access every page in the SGA. The cost of this strategy is fixed; however,

you might simply determine that 20,000 pages must be touched every time a process

starts. This approach can be useful with some applications, but not with all

applications. Overhead can be significant if your system frequently creates and

destroys processes by, for example, continually logging on and logging off.

The advantage that PRE_PAGE_SGA can afford depends on page size. For example, if

the SGA is 80 MB in size and the page size is 4 KB, then 20,000 pages must be touched

to refresh the SGA (80,000/4 = 20,000).

If the system permits you to set a 4 MB page size, then only 20 pages must be touched

to refresh the SGA (80,000/4,000 = 20). The page size is operating system-specific and

generally cannot be changed. Some operating systems, however, have a special

implementation for shared memory whereby you can change the page size.

通过修改lock_sga和pre_page_sga参数可以保证SGA不被换出到虚拟内存，进而可以提高SGA的使用效率。

当lock_sga参数设置为TRUE时（默认值是FALSE），可以保证整个SGA被锁定在物理内存中，这样可以防止SGA被换出到虚拟内存。只要设置lock_sga为“TRUE”便可保证SGA被锁定在物理内存中，这里之所以顺便将pre_page_sga参数也设置为“TRUE”，是因为这样可以保证在启动数据库时把整个SGA读入到物理内存中，以便提高系统的效率（虽然会增加系统的启动时间）。

AIX 5L（AIX 4.3.3以上）

1. aix参数v_pinshm=1，默认是0，表示aix将支持pin住内存，设置方法为
#vmo -p -o v_pinshm=1

2. aix参数maxpin%=内存百分比，默认80%，表示支持的最大的可pin住内存的比例，设置方法为
#vmo -p -o maxpin%=90

3. oracle参数LOCK_SGA=true，表示oracle将使用这部分被pin住的内存，其实就是告诉oracle使用另外一种内存调用方法。

HP UNIX

1. root用户，创建权限配置文件/etc/privgroup
# touch /etc/privgroup
# vi /etc/privgroup
添加"dba MLOCK"到该文件

2. root用户，执行命令
# /etc/setprivgrp -f /etc/privgroup

3. oracle用户，修改Oracle参数lock_sga=true

SOLARIS （solaris2.6以上）

8i版本以上数据库默认使用隐藏参数 use_ism = true，自动锁定SGA于内存中，不用设置lock_sga。
如果设置 lock_sga =true 使用非 root 用户启动数据库将返回错误。

WINDOWS

不能设置lock_sga=true，可以通过设置pre_page_sga=true，使得数据库启动的时候就把所有内存页装载，这样可能起到一定的作用。

Red Hat5 Linux 2.64bit

1.查看lock_sga和pre_page_sga参数的默认值

2 重新启动Oracle使spfile的修改生效

失败原因，Linux操作系统对每一个任务在物理内存中能够锁住的最大值做了限制！需要手工进行调整。

5.“ORA-27102”及“Cannot allocate memory”问题处理
1）使用“ulimit -a”命令获得“max locked memory”的默认大小
oracle@sharkdg:[/u01/app/oracle/product/11.2.0/db_1/sqlplus/admin]  ulimit -a
core file size                          (blocks, -c)             0
data seg size                         (kbytes, -d)            unlimited
scheduling priority                (-e)                          0
file size                                    (blocks, -f)             unlimited
pending signals                    (-i)                          139264
max locked memory             (kbytes, -l)             32
max memory size                  (kbytes, -m)          unlimited
open files                                (-n)                        1024
pipe size                                  (512 bytes, -p)     8
POSIX message queues     (bytes, -q)             819200
real-time priority                     (-r)                           0
stack size                                (kbytes, -s)           10240
cpu time                                   (seconds, -t)       unlimited
max user processes             (-u)                        2047
virtual memory                        (kbytes, -v)           unlimited
file locks                                  (-x)                         unlimited

可见，一个任务可以锁住的物理内存最大值是32kbytes，这么小的值根本无法满足我们SGA的大小需求。

2）在root用户下尝试修改，成功。

调整完操作系统的限制后，我们再次尝试启动数据库。成功！