- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: Contiguous shared memory for oracle
Operating System - HP-UX
1752678
Members
5289
Online
108789
Solutions
Forums
Categories
Company
Local Language
юдл
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
юдл
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-11-2002 11:58 AM
тАО09-11-2002 11:58 AM
Contiguous shared memory for oracle
I'm running oracle 7.3.4 on 10.20 with a 5 node Service Guard cluster. I tried to verify our primary DB can run on the failover node, but it would not come up, the usual error 12, not enough memory. I've searched the forums till I'm blue in the face, and the hits are all the same, shmmax, maxdsize, swap, etc. Been there, done those long ago... I know these are not the issue, as I've done this several times over the last 3 years, and we've not changed anything. (not even patches for 2 years). My DBA and I suspect that there is a contiguous memory issue. We even tested all five packages on this server at once during Service Guard implementation.
The 2 machines in question are identical T600's with 3.75GB ram. The failover server is running a QA DB with a 512mb SGA, and another 60mb used by the system. The production DB wants 1GB, 250mb less than should be available.
How can I determine if I have a problem with contiguous memory? Any easy way to 'see' how it's being used? I suspect Q4 and the kernel tables would tell me, but I'm not sure I know enough about the tables to do that.
Thanks!
John
The 2 machines in question are identical T600's with 3.75GB ram. The failover server is running a QA DB with a 512mb SGA, and another 60mb used by the system. The production DB wants 1GB, 250mb less than should be available.
How can I determine if I have a problem with contiguous memory? Any easy way to 'see' how it's being used? I suspect Q4 and the kernel tables would tell me, but I'm not sure I know enough about the tables to do that.
Thanks!
John
3 REPLIES 3
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-11-2002 01:02 PM
тАО09-11-2002 01:02 PM
Re: Contiguous shared memory for oracle
Hi John,
Here is what I think is happening. In 32-bit HP-UX, your memory is divided into four 1Gb quadrants. The Oracle SGAs are part of shared memory, and shared memory is limited to quadrants 3 and 4. The last .25Gb of quadrant 4 is reserved, so essentially you can have up to 1.75 Gb of shared memory, in a 1.0Gb chunk and a 0.75Gb chunk. Now, on your failover box you are running a database with 500 Mb of shared memory. My guess is that the SGA for this database is living in quadrant 3. When you try to failover your production database and it asks for 1.0 Gb of shared memory for the SGA it fails, not because you don't really have it, but because it is spread across two quadrants. The trick is, to either get your QA instance on the failover box to use its 500 Mb SGA in quadrant 4, or else to get the production database to split up its SGA into two chunks that will fit in the two quadrants. I'm not enough of a wizard to know how to do that, but that is what I think is happening.
JP
Here is what I think is happening. In 32-bit HP-UX, your memory is divided into four 1Gb quadrants. The Oracle SGAs are part of shared memory, and shared memory is limited to quadrants 3 and 4. The last .25Gb of quadrant 4 is reserved, so essentially you can have up to 1.75 Gb of shared memory, in a 1.0Gb chunk and a 0.75Gb chunk. Now, on your failover box you are running a database with 500 Mb of shared memory. My guess is that the SGA for this database is living in quadrant 3. When you try to failover your production database and it asks for 1.0 Gb of shared memory for the SGA it fails, not because you don't really have it, but because it is spread across two quadrants. The trick is, to either get your QA instance on the failover box to use its 500 Mb SGA in quadrant 4, or else to get the production database to split up its SGA into two chunks that will fit in the two quadrants. I'm not enough of a wizard to know how to do that, but that is what I think is happening.
JP
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-11-2002 04:36 PM
тАО09-11-2002 04:36 PM
Re: Contiguous shared memory for oracle
I think john is right and if I remember correctly there was patch which would adjust the quadrants . But I don't remember now .
I saw it in the knowledge base section . If you search there with key words shared memory or semaphores , you might get it .
I saw it in the knowledge base section . If you search there with key words shared memory or semaphores , you might get it .
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-11-2002 11:07 PM
тАО09-11-2002 11:07 PM
Re: Contiguous shared memory for oracle
Hi, John!
Fitting large databases into the 32bit constraints is likely to be prolematic. You should be able to find several approaches in the Forum... one of them could be to get a SHMEM_MAGIC linked version of Oracle. Then Q2 is available for shared objects also, resulting in 3.75GB.
Another approach could be setting the use_bestfit kernel global to 1.
See Patch text of PHKL_16751:
The global variable (flag) `use_bestfit' determines what
allocation policy will be used. The default setting of this
flag is 0, resulting in first-fit being used for all
allocations for shared virtual addresses. To enable the
system to use best-fit, this flag (use_bestfit) must be set
to a non-zero value (say 1) using `adb.' The value can be
set/reset at any time during system operation. The policy
that will be used is based on the current value of this
flag.
---
The adb command would look like:
echo "use_bestfit/W1" | adb -w /stand/vmunix /dev/kmem
Maybe this allocation policy could cure your problems.
Regards...
Dietmar.
Fitting large databases into the 32bit constraints is likely to be prolematic. You should be able to find several approaches in the Forum... one of them could be to get a SHMEM_MAGIC linked version of Oracle. Then Q2 is available for shared objects also, resulting in 3.75GB.
Another approach could be setting the use_bestfit kernel global to 1.
See Patch text of PHKL_16751:
The global variable (flag) `use_bestfit' determines what
allocation policy will be used. The default setting of this
flag is 0, resulting in first-fit being used for all
allocations for shared virtual addresses. To enable the
system to use best-fit, this flag (use_bestfit) must be set
to a non-zero value (say 1) using `adb.' The value can be
set/reset at any time during system operation. The policy
that will be used is based on the current value of this
flag.
---
The adb command would look like:
echo "use_bestfit/W1" | adb -w /stand/vmunix /dev/kmem
Maybe this allocation policy could cure your problems.
Regards...
Dietmar.
"Logic is the beginning of wisdom; not the end." -- Spock (Star Trek VI: The Undiscovered Country)
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
News and Events
Support
© Copyright 2024 Hewlett Packard Enterprise Development LP