oracle application 11i and the recomended kernel parameter on L 1000 64 bit server where application

[Shumi Begum]

I was not sure where to post this message to as this is my first posting. I searched some related topic and post this question there ( old topic dated Nov. 2000), so if this appears more than 1 place my apology.

HERE IS THE question/problem I am facing.

We just intalled oracle application 11i (11.5.3) and 8i (8.1.6) database on L server 64 bit 1000 model. we have 2 CPU and 2gig memory. this server is not in production yet. All we are doing is that setting up common application area in 11i by 1 user. I found as soon as I started the database and concurrent manager with other backgroun processes like form server, report server etc. Memory utilization jumped from 48% to 76%. as that user compile one table memory utilization jumped to 84% and it did not released when she is done and log out. It is now 90%. I have changed the Kernel to following before installing the 11i and 8i. they are:
maxtsiz_64bit - 1073741824
maxdsiz_64 bit - 1073741824
faxfiles - 60 as it was
nfile - 5000
nprocs - 520
shmmax - 1073741824
shmmni - 200
shmseg - 120
semmni - 100 ( as it was)
semmns - 500 ( as it was)
I found entry like maxdsiz and maxtsiz which is about 168 MB. IS oracle using these maxdsiz and maxtsiz variable. I understand that oracle 11i and 8i are 32 bit not 64. Could some one please tell me if I need to change Kernel variables in order to get memory not to be utilized to its max and hang! We will run at least 2 instance simultaneously later on.
the current instance has the followings:
Total System Global Area 365034328 bytes
Fixed Size 72536 bytes
Variable Size 322945024 bytes
Database Buffers 40960000 bytes
Redo Buffers 1056768 bytes

aegis001(root):/>swapinfo -tm
Mb Mb Mb PCT START/ Mb
TYPE AVAIL USED FREE USED LIMIT RESERVE PRI NAME
dev 1964 0 1964 0% 0 - 1 /dev/vg00/lvol2
reserve - 1310 -1310
memory 1540 788 752 51%
total 3504 2098 1406 60% - 0 -
aegis001(root):/>
aegis001(root):/>ipcs -bm
IPC status from /dev/kmem as of Tue Feb 27 11:44:22 2001
T ID KEY MODE OWNER GROUP SEGSZ
Shared Memory:
m 0 0x411c0232 --rw-rw-rw- root root 348
m 1 0x4e0c0002 --rw-rw-rw- root root 31040
m 2 0x41201050 --rw-rw-rw- root root 8192
m 3 0x331814e8 --rw------- root root 1129272
m 4 0x6d18130f --rw-rw-rw- root root 47120
m 20205 0x590e62e0 --rw-r----- devora dba 365146112
m 6 0x06347849 --rw-rw-rw- root sys 77384
m 8 0x00000000 D-rw------- devap oaa 46084


Please help. Talking to Oracle found out to be useless.

Thanks

Shumi

[Bill Hassell]

Using memory 100% is exactly what you want to do. The processes will take what they require. Setting maxdsiz or maxdsiz_64 to smaller values will cause the processes to abort. These are fences to prevent runaway (bad) programs from consuming all your swap space.

HP-UX is a virtual memory system so RAM is only a part of memory. With swapmem_on=1 in gthe kernel, you have virtual memory for processes up to 1750 Mb + whatever is in swap. Use swapinfo -tm to understand what is actually being used in swap.

It is important to note that the Oracle SGA size has a direct impact on the performance of your Oracle database. Similarly, the buffer cache in HP-UX can help although placing the right items into SGA will be more effective than increasing SGA.

Also note that 64-bit HP-UX works best with 4 Gb of RAM or more. Most large Oracle sites (hundreds of clients) have 6-16 Gb of RAM with large SGA's. Large RAM means little or no swapping. There are many parameters you can adjust in Oracle to improve performance, but making the programs use less RAM is not one of them.

[Shumi Begum]

Thanks for the reply. Problem is I have to run 2 instances simultaneously. With one instance it is working fine after I changed the dbc_max_pct from 50 to 10 and changed maxdsiz and maxtsiz to 1 gig. But as soon as I started the second instances and it's background processes, memory utilization jumped to 92% and swap by 66% (glance plus report). With few users and little bit of activities will hang processes and users will scream!

My question is there anyway we could set up the kernel or swap space to solve this problem or our only solution is to buy the expensive memory ( 2 gig cost 18 thousand dollar) If so how that can be achieved?

we have 2 gig swap/dump space in /dev/vg00/lvol2.

Thanks again
shumi