Sorry for this latency,
Thanks to all of the following admins,
-- Han Pilmeyer, han_at_zk3.dec.com
- Vipin Gokhale
- Alan Davis (answer greatly appreciated)
vmemconfigure:segmented shared memory and granularity hints are mutually
exclusive.Turning off granularity hints.
as the above error messages says, Segmented shared memory and granularity hints can not co-exist.So you have to set
ssm-threshold=0 (in the ipc subsystem)
You can do this with the dxkerneltuner or
sysconfig -r ipc ssm-treshold=0 (changes kernel attribute in run-time but lost after boot so best method is to change the boot time value with dxkerneltuner and reboot the box)
I think this allows to cancel the segmented shared memory option.
You must reserve as many as shared memory used by oracle SGA. Another important point , memory reserved by gh-chunks can not be used by OS so if it is more than needed, it can not be returned to OS .
Steps for this (as far as I understood) BUT I COULD NOT IMPLEMENT THIS IN MY MACHINE BECAUSE I COULD NOT REBOOT MY BOX !!! (YET)
1- Make the oracle SGA (can be seen with ipcs -mb ) evenly divisible by 8388608 (8 MB in decimal) (it is advised to regulate sharedpool area for this)
2- gh-chunks = Your_SGA_size / 4 MB (= 4194304) (may be +1) (to open granularity hints )
3- ssm-treshold=0
4- shm-max=at least your_SGA_size (this provides SGA to be in *only* 1 shared segment which optimize performance )
5- reboot your box
If I am wrong please correct me. Anyway, you can find much more than this in the following DOC.
selcuk.karaca_at_aski.gov.tr
I am giving the whole doc sent by Alan Davis which very good.
------------------------Starting from here-------------------------------------------------------------------------
Forcing Oracle to use 8 MB-aligned shared memory segments.
This note was written by Elizabeth Sperling and Glenn Stasse of the
Washington, D.C. Benchmark Center. It addresses some setup features when
running Oracle7 on Digital UNIX/Alpha systems. It is applicable to
Digital UNIX Version 3.x systems with the OSF350-055 patch installed and
to Digital UNIX version 3.2D systems.
Introduction:
An optimization has been developed for the use of large, shared memory
segments on Digital Unix V3.x. This optimization involves the use of
shared page table entries(PTEs) to map shared memory segments and the
use of an Alpha architectural feature called granularity hints. When
this patch is applied and the shared memory segments are properly
aligned, each process attaching to the shared segments will use the
shared PTEs to map the shared segments, reducing memory consumption and
improving performance, particularly when attaching and detaching to the
shared segments.
A by-product of this optimization is that the shared memory segments
need to be aligned on 8MB boundaries (that is, the lower 23 bits of the
address must be zero) in order to function properly. Non-aligned
segments will bypass the shared PTE mechanism and revert to the
traditional virtual memory system.
This note addresses one method found to be successful in size-aligning
the shared memory usage of Oracle7 such that the Oracle shared memory
usage is falls on an even 8MB boundary. This note does NOT address the
need for a shared segment's attach address to be aligned.
Setting a value for Granularity Hints for shared memory segments:
The granularity hints fix makes use of the granularity hints bits in the
page table entry (PTE) as specified in the Alpha Architecture.
Granularity hints is a Translation Buffer (TB) optimization that allows
the TB to map more than a single page. Enabling the granularity hints
fix also enables the shared PTE fix. The granularity hints fix is
enabled by setting the "gh-chunks" parameter in OSF /etc/sysconfigtab.
The gh-chunks parameter is the number of 4 Megabyte chunks reserved at
boot time for shared memory use.
In /etc/sysconfigtab set the value for gh-chunks according to the size
of your shared memory requirements. The entry should be similar to the
following:
vm:
gh-chunks=512
OR
gh-chunks=0x200
This reserves 2 Gigabytes of physical memory for shared memory. The
calculation is:
In decimal: 4194304 * 512 = 2147483648
In Hex: 0x400000 * 0x200 = 0x80000000
Please Note: Memory that is set aside at boot time for shared memory by
specifying a value for gh-chunks will not be used for anything other
than shared memory. Unused memory from this region is not given back to
the system.
Finding Current Values for the database
You can determine the systems view of shared memory segments with the
command 'ipcs -mb'. On a system using an SGA of approximately 2.4GB
this displays:
Shared Memory:
T ID KEY MODE OWNER GROUP SEGSZ
m 0 71535248 --rw-r----- oracle users 784
m 1 138644112 --rw-r----- oracle users 2139095040
m 2 205752976 --rw-r----- oracle users 273563648
Note the two values for SEGSZ owned by Oracle(other than the first).
This is the QUANTITY of shared memory allocated by Oracle for the SGA,
etc. The sum of these two numbers (2139095040 + 273563648 = 2412658688)
is not evenly divisible by 8388608 (8 MB in decimal) so these segments
are not properly aligned. (In fact, the first of these two values IS
properly aligned already so all the modifications will apply to the
second value, which is the difference between the largest segment
available and the application requirements.)
Calculating new values
A simple way to get to the value you need is:
Divide the sum of the shared segments by 8MB:
2412658688/8388608 = 287
Round up(or down) to the next highest value and multiply by 8MB:
288*8388608 = 2415919104
Subtract the original value for shared memory from the new
value:
2415919104 - 2412658688 = 3260416
Add THIS value to the parameter shared_pool_size in
initXXXX.ora:
80000000 + 3260416 = 83260416
After modifying shared_pool_size and bouncing the database, the same
'ipcs -mb' command now shows: Shared Memory:
T ID KEY MODE OWNER GROUP SEGSZ
m 0 71535248 --rw-r----- oracle users 784
m 1 138644112 --rw-r----- oracle users 2139095040
m 2 205752976 --rw-r----- oracle users 276824064
Note the growth in the size of the second segment. The first segment is
already as big as it can be so the difference will be reflected in the
size of the second segment. (This may NOT be the case when the SGA size
is less than 2 GB.) These sum of these two values are properly aligned:
2139095040 + 276824064 = 2415919104 which is properly aligned
because:
2415919104/(8388608*288) = 1
Another way to think about it is the shared memory used by Oracle is
composed of 288 8MB segments.
Notes and Comments
Note 1:
This entire exercise is meaningless on systems where the patch to use
shared PTEs has not been applied.
Note 2:
This methodology should result in improved performance although no
testing has been done to characterize this.
Note 3:
There are other values in the Oracle parameter file that affect the size
of Oracle's shared memory usage. You can tweak any of them that are
appropriate for your requirements but in the end the ipcs display must
total an even multiple of 8388608. Adding a value to shared pool is a
fairly easy way out.
Note 4:
When the SGA is 2GB and above, a good value to use for shm-max in
/etc/sysconfigtab is 2139095040. Other notes around suggested a value of
2118123520. This new value has the lower 23 bits = 0 (i.e., properly
aligned).
Note 5:
Trying to relate the values Oracle gives you for it's usage to the ipcs
display can be a difficult. There is overhead added to the request made
by the application. Consider the following:
When the Oracle database starts up it displays:
ORACLE instance started.
Database mounted.
Database opened.
Total System Global Area 2412649680 bytes
Fixed Size 70736 bytes
Variable Size 117770368 bytes
Database Buffers 2293760000 bytes
Redo Buffers 1048576 bytes
(You can get the same numbers using the query 'select * from v$sga;' and
'select sum(value) from v$sga;'.)
The sum of Fixed Size, Variable Size, Database Buffers, and Redo Buffers
is 2412649680. The sum of the ipcs display is 2412658688. The
difference between the two is 9008, a value that relates in no obvious
way. Chasing these numbers around may not yield quick results! It's
probably faster to look at the numbers in the ipcs display, change the
values in initXXX.ora, and bounce the database.
Note 6:
For completeness sake here are the raw values used while working on this
note.
Before (shared_pool_size=80000000)
--------------------------------------------
ipcs -mb
Shared Memory:
T ID KEY MODE OWNER GROUP SEGSZ
m 0 71535248 --rw-r----- oracle users 784
m 1 138644112 --rw-r----- oracle users2139095040
m 2 205752976 --rw-r----- oracle users 273563648
ORACLE instance started.
Database mounted.
Database opened.
Total System Global Area 2412649680 bytes
Fixed Size 70736 bytes
Variable Size 117770368 bytes
Database Buffers 2293760000 bytes
Redo Buffers 1048576 bytes
After (shared_pool_size=83260448)
--------------------------------------------
ipcs -mb
Shared Memory:
T ID KEY MODE OWNER GROUP SEGSZ
m 0 71535248 --rw-r----- oracle users 784
m 1 138644112 --rw-r----- oracle users2139095040
m 2 205752976 --rw-r----- oracle users 276824064
ORACLE instance started.
Database mounted.
Database opened.
Total System Global Area 2415910128 bytes
Fixed Size 70736 bytes
Variable Size 121030816 bytes
Database Buffers 2293760000 bytes
Redo Buffers 1048576 bytes
SQL> select * from v$sga;
NAME VALUE
-------------------- ----------
Fixed Size 70736
Variable Size 121030816
Database Buffers 2293760000
Redo Buffers 1048576
SQL> select sum(value) from v$sga;
SUM(VALUE)
----------
2415910128
Received on Fri Mar 03 2000 - 07:04:40 NZDT