Ora-27102: Out of memory-Error bringing up Oracle

[Mary Hart]

I know there are many references to this same problem on the forum but I believe I have tried everything mentioned and/or am unsure how much to increase/decrease a kernel parameter. You will cringe when you see my dbc_max_pct. However, for reasons that do not make sense to me, raising the dbc_max_pct is the only thing that prevents the "out of memory" error when the DBA attempts to increase the SGA or DB_Block_Buffers. I know everything I read indicates this should be about 10%, not 50%. The way I understand this parameter, it should only be affecting performance, not preventing me from bringing up the database. I am obviously missing something. Thanks for your help.

Here are my stats:
HP RP7410
HPUX 11.11
16 gb RAM
8 gb swap (not currently using all of my swap)
1 Oracle database and Oracle applications
SGA - 1.5 gb. Trying to increase it to 1.8 gb but cannot, receive "out of memory" error.
DB_BLOCK_BUFFERS - 100,000 blocks. Trying to increase to 120,000 but receive "out of memory" error.
Database block size - 8 k
Shared_Pool_Size - 600 mb
Java_Pool_Size - 70 mb

HP Kernel Parameters

NSTREVENT 50
NSTRPUSH 16
NSTRSCHED 0
STRCTLSZ 1024
STRMSGSZ 65535
acctresume 4
acctsuspend 2
aio_listio_max 256
aio_max_ops 2048
aio_physmem_pct 10
aio_prio_delta_max 20
allocate_fs_swapmap 0
alwaysdump 1
bufcache_hash_locks 128
bufpages 0
chanq_hash_locks 256
core_addshmem_read 0
core_addshmem_write 0
create_fastlinks 0
dbc_max_pct 50
dbc_min_pct 5
default_disk_ir 0
disksort_seconds 0
dmp_rootdev_is_vol 0
dmp_swapdev_is_vol 0
dnlc_hash_locks 512
dontdump 0
dst 1
effective_maxpid 30000
enable_idds 0
eqmemsize 15
executable_stack 1
fcp_large_config 0
fs_async 0
ftable_hash_locks 64
hdlpreg_hash_locks 128
hfs_max_ra_blocks 8
hfs_max_revra_blocks 8
hfs_ra_per_disk 64
hfs_revra_per_disk 64
hp_hfs_mtra_enabled 1
initmodmax 50
io_ports_hash_locks 64
ksi_alloc_max 192160
ksi_send_max 32
max_async_ports 50
max_fcp_reqs 512
max_mem_window 0
max_thread_proc 256
maxdsiz 1048576000
maxdsiz_64bit 1073741824
maxfiles 1024
maxfiles_lim 1024
maxssiz 131072000
maxssiz_64bit 131072000
maxswapchunks 5058
maxtsiz 1024000000
maxtsiz_64bit 1073741824
maxuprc 768
maxusers 3000
maxvgs 50
mesg 1
modstrmax 500
msgmap 2050
msgmax 32768
msgmnb 65536
msgmni 128
msgseg 32737
msgssz 32
msgtql 2048
nbuf 0
ncallout 42067
ncdnode 150
nclist 48100
ncsize 32788
ndilbuffers 30
nfile 45089
nflocks 1500
ninode 27668
nkthread 42051
no_lvm_disks 0
nproc 24020
npty 300
nstrpty 300
nstrtel 300
nswapdev 10
nswapfs 10
nsysmap 48040
nsysmap64 48040
o_sync_is_o_dsync 0
pfdat_hash_locks 128
public_shlibs 1
region_hash_locks 128
remote_nfs_swap 0
rtsched_numpri 32
scroll_lines 100
scsi_max_qdepth 8
scsi_maxphys 1048576
sema 1
semaem 16384
semmap 514
semmni 512
semmns 1100
semmnu 158
semmsl 2048
semume 128
semvmx 65535
sendfile_max 0
shmem 1
shmmax 2000000000
shmmni 1024
shmseg 308
st_ats_enabled 1
st_fail_overruns 0
st_large_recs 0
st_san_safe 0
streampipes 0
swapmem_on 1
swchunk 2048
sysv_hash_locks 128
tcphashsz 0
timeslice 10
timezone 420
unlockable_mem 0
vas_hash_locks 128
vnode_cd_hash_locks 128
vnode_hash_locks 128
vol_checkpt_default 10240
vol_default_iodelay 50
vol_fmr_logsz 4
vol_max_bchain 32
vol_max_nconfigs 20
vol_max_nlogs 20
vol_max_nmpool_sz 4194304
vol_max_prm_dgs 1024
vol_max_rdback_sz 4194304
vol_max_vol 8388608
vol_maxio 256
vol_maxioctl 32768
vol_maxkiocount 2048
vol_maxparallelio 256
vol_maxspecialio 256
vol_maxstablebufsize 256
vol_min_lowmem_sz 524288
vol_mvr_maxround 256
vol_rootdev_is_vol 0
vol_subdisk_num 4096
vol_swapdev_is_vol 0
vol_vvr_transport 1
volcvm_cluster_size 16
volcvm_smartsync 1
voldrl_max_drtregs 2048
voldrl_min_regionsz 512
voliomem_chunk_size 65536
voliomem_maxpool_sz 4194304
voliot_errbuf_dflt 16384
voliot_iobuf_default 8192
voliot_iobuf_limit 131072
voliot_iobuf_max 65536
voliot_max_open 32
volraid_rsrtransmax 1
vps_ceiling 16
vps_chatr_ceiling 1048576
vps_pagesize 4
vx_fancyra_enable 0
vx_ncsize 1024
vx_ninode 0
vxfs_max_ra_kbytes 1024
vxfs_ra_per_disk 1024
vxtask_max_monitors 32

[Dave Hutton]

Running both 64 bit OS and Database I'm assuming?

[Steven E. Protter]

You are correct. I am cringing.

Every time your system changes that dbc figure, its very consuming of CPU resources.

But memory errors could be due to shmmax and shsmseg.

A lot of what the database does ins in shared memory. shmmax can be up to 25% of available memory which is defined as actual ram plus activated swap.

Some advice.

Run through this doc:
http://www1.itrc.hp.com/service/cki/search.do?category=c0&docType=Security&docType=Patch&docType=EngineerNotes&docType=BugReports&docType=Hardware&docType=ReferenceMaterials&docType=ThirdParty&searchString=UPERFKBAN00000726&search.y=8&search.x=28&mode=id&admit=-682735245+1071596958300+28353475&searchCrit=allwords

Measure some performance in the background with the script I'm attaching.

SEP

[Kent Ostby]

Mary -- You can have the DBA add an event "event="27102 TRACE NAME
ERRORSTACK FOREVER" in init.ora parameter file.

This should create a trace file that could provide you or oracle with more data.

It will create a file that is something like: prd_ora_.trc

a find such as:

find . -name \*.trc on the oracle FS should find it.

Best regards,

Kent M. Ostby

[Jean-Luc Oudart]

Hi,

What is the Oracle version ?

select * from v$version

output please.

thanks,
Jean-Luc

[Mary Hart]

Database 8.17
Oracle applications 11.5.8
32 bit Oracle/64 bit HPUX

[Jean-Luc Oudart]

Oracle 32 bits :

Your SGA is limited to 1.75Gb

You can either migrate to Oracle 8174 64bits or reduce the other pool shared_pool, java_pool) if possible.
In the longer term you probably better with option#1

Regards,
Jean-Luc

check Metalink doc id 66956.999

[Jeff Schussele · Accepted solution]

Yep - I was waiting to see whether your Oracle was 32 or 64-bit.
Jean-Luc is quite correct - you are hitting a 32-bit limit & in reality you'll never get 1.75GB either. The best you can probably hope for is 1.6Gb.

If you need a larger SGA, you really have no other choice than go to 64-bit Oracle.
And don't expect any performance increase either as 64-bit is all about addressing - not performance. Many people have that misconception I've found.

Rgds,
Jeff

[Mary Hart]

I have passed the 32-bit limit issue onto the DBA. That is obviously our problem. Thank you for that very relavent fact.

Based upon the knowledge that we cannot increase our SGA, it is now time to tune the other parameters. Does this sound like a good start?

Increase shmmax to 5 gb from 2 gb
Decrease dbc_max_pct from 50% to 30% (as a first attempt. I know it should eventually get much lower).

What about shmseg, maxtsiz, maxssiz?
I keep seeing references to these also, but not any guidelines.

Thanks, Mary

[RAC_1]

You can use memory windows to overcome this problem.

With 32 bit applications/programs you are limited to 1.7 GB shmmax.