tech 2005-06-28 - By michael.d.taylor@(protected)
Gabi,
Welcome to the world of 32 bit Linux. Basically, only 1.7 GB is available
for your total SGA on 32 bit Linux due to the SGA base address of the
executables. There are some documents on metalink.oracle.com that provide
instructions for increasing SGA for Red Hat Linux, but I have not been able
to get these to work on SLES9 32 bit. You can increase your SGA to your
kernel.shmmax just fine on 64 bit SLES9 and 64 bit 9.2.0.4 or higher. In my
opinion, 32 bit linux is only suitable for demonstration or development
environments. We have too many processes in our ERP environments that
require grater than 3GB SGA to complete without error. Not to mention, a
1.7 GB restriction also limits the number of concurrent users you can
support. Once you migrate to 10g and native compilation, it gets even
worse. I had to shrink the SGA to 600 MB just to get standard gather
statistics jobs to complete without ORA-04030 (See ORA-04030.ora-code.com) out of process memory
errors...
I am getting the impression Oracle is dropping support for 64 bit Oracle
though. I logged a tar for the release date of 10.1.0.4, since it was
released in May for Solaris, Windows, HPUX, and Windows 64 bit. I was told
the Linux 64 bit 10.1.0.4 release date was 15 Dec 2005.
Regards,
-Michael
Here are some notes on things you can try:
http://metalink.oracle.com/metalink/plsql/showdoc?db=Not&id=260152.1
-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---
-- ---
Since shmfs is a memory file system, its size can
be as high as the maximum allowable VM size which is 64GB.
SGA MAX Size 62GB theoretic (depending on block size)
Only the buffer cache part of the SGA can take advantage of the additional
memory
For RHEL3 to use the VLM option to create a very large buffercache,
you have two options (details on [4]Note 262004.1):
- Use shmfs much as you would in RHAS2.1:
mount a shmfs with a certain size to /dev/shm,
and set the correct permissions.
Keep in mind that in RHEL3, shmfs allocate memory is pageable.
- Use ramfs: ramfs is similar to shmfs,
except that pages are not pageable/swappable.
This approach provides the commonly desired effect.
Ramfs is created by mount -t ramfs ramfs /dev/shm
(unmount /dev/shm first).
The only difference here is that the ramfs pages are not
backed by big pages.
The parameter use_indirect_data_buffers=true remains the same;
the settings on the Oracle side should not have to change.
How to use the memory file system shmfs in short,
for details see [1]Note 211424.1:
- Mount the shmfs file system as root using command:
% mount -t shm shmfs -o nr_blocks=8388608 /dev/shm
- Set the shmmax parameter to half of RAM size
$ echo 3000000000 >/proc/sys/kernel/shmmax
- Set the init.ora parameter use_indirect_data_buffers=true
- Startup oracle.
How to use the memory file system ramfs in short,
for details see [4]Note 262004.1:
- Mount the shmfs file system as root using command:
% umount /dev/shm
% mount -t ramfs ramfs /dev/shm
% chown oracle:dba /dev/shm
- Increase the "max locked memory" ulimit (ulimit -l)
Add the following to /etc/security/limits.conf:
oracle soft memlock 3145728
oracle hard memlock 3145728
(in case of ssh see details on [4]Note 262004.1)
- Set the init.ora parameter use_indirect_data_buffers=true
- Startup oracle.
-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---
-- ---
If we lower the the mapped Base Address from 0x40000000
(decimal 1073741824) to 0x15000000 (decimal 352321536),
we reduce the space for Text/Code and can get another 0.75Gb (768Mb) for the
SGA
0.3 GB Text/code
2.7 GB available process memory for mmap, malloc /
address space (e.g. usable by shared Pool)
0.3 GB Stack
1.0 GB Kernel
How to Lowering mapped_base in short, for details see [1]Note 211424.1:
- Modify shmmax:
% echo 3000000000 > /proc/sys/kernel/shmmax
- Relocating the SGA (low SGA attach address):
% cd $ORACLE_HOME/rdbms/lib
% cp ksms.s ksms.s_orig
% genksms -s 0x15000000 > ksms.s
% make -f ins_rdbms.mk ksms.o
% make -f ins_rdbms.mk ioracle
- lower the mapped base for a single bash terminal session
1. Open a terminal session (Oracle session).
2. Open a second terminal session and su to root (root session).
3. Find out the process id for the Oracle session.
For example: do "echo $$" in the Oracle session.
4. Now lower the mapped base for the Oracle session to 0x10000000.
From the root session, echo 268435456 >/proc/<pid>/mapped_base,
where <pid> is the process id determined in step 4.
5. From the Oracle terminal session, startup the Oracle instance.
The SGA now begins at a lower address, so more of the address
space can be used by Oracle.
Now you can increase the init.ora values of db_cache_size or
db_block_buffers
to increase the size of the database buffer cache.
In this case the max SGA size will be 2.7 GB
-- --Original Message-- --
From: Draghici Gabi [mailto:gabi.draghici@(protected)]
Sent: Tuesday, June 28, 2005 9:29 AM
To: suse-oracle@(protected)
Subject: [suse-oracle] tech
Hello all ! I've sucessfully installed Oracle 9i on Sles 9 but when I begun
to grow the SGA(actually the db_cache_size parameter from 1G to 1,5G when
there are 3 G of RAM from which 1 remains free !) I got ORA-27123 (See ORA-27123.ora-code.com):unable to
attach to shared memory segment . Now, I found a few ideeas about the page
size and Oracle but none of them work it ! Can someone explain the hole
mecanism of alocation please ?!
GAbi
--
To unsubscribe, email: suse-oracle-unsubscribe@(protected)
For additional commands, email: suse-oracle-help@(protected)
Please see http://www.suse.com/oracle/ before posting
|
|
