Oracle 32/64bit and Memory Windows

[Eric Buckner]

Hi everyone. We run a rather large system with 22 Oracle databases. We have a mixture of 32 and 64 bit databases. Recently we started bumping up against shared memory limits for our 32 bit databases. So our plan is to implement Memory Windows to get around this problem. Moving the databases to 64 bit is not an option as they are part of vendor applications that are all 32 bit. At any rate I decided to work with this on a smaller test server and have run into some strange issues.

OS - HPUX 11.11
Oracle Version 8.1.7 32 & 64 bit
Listener is running on the 64 bit side.

I have set the max_mem_window kernel parameter to 10 and remade/rebooted.

Added our 32 bit test database SID to the /etc/services.window and started up the database. Everything was great. memwin_stats showed the new window, but I now I can not start up the 64 bit databases and get the following messages:
ORA-24323: value not allowed
ORA-27146: post/wait initialization failed

I am also having problems connecting to this 32 bit database w/ anything outside the server. Which leads me to believe that the 8.1.7 64bit listener is causing the problems. At least according to documentation the 64bit Oracle as of 8.1.7 doesn't make the calls to getmemwindow.

Has anyone done this? And if so can you please shed some light on it?

Thanks,
Eric

[MANOJ SRIVASTAVA]

Hi Eric

My understanding is like this

For a bit architecture to address for the memory requierment of more tahn 1.75 gb these two systems call were included in Oracle to enable more use of memory , this is essentially based on the memory requiremnet of the user , ie when the user tries to connect to the databse setmemwindow will get teh adress of the memory segment and getmemewindow will map the space .However the same is not needed in 64 bit as the memory limitation is <4.0 GB . but Oracle still uses these calls to and has a load on the performance as evertime it has to excute thes two call ,and if you have amny uses it effects the system performance .

So in all our systems which have 32 bit we dont use this but use it on the system which have 64 bit UX and Oracle .


Manoj Srivastava
To unset it in 64 bit architecture all you have to do is add export memwidw=TRUE in the .profile of oracle and the user also and this will just excute one call rahter than 2.

[Eric Buckner]

Manoj,
Thanks for the reply. I am in total agreement about the 1.75 GB limit. Our problem is our production server is hitting this w/ 32 bit applicatons and 32 bit databases. These databases are vendor specific and as such we can not upgrade them to 64 bit. If we could this problem wouldn't exist, yet. I am just running into problems running Memory windows w/ 32 bit Oracle and also having 64 bit Oracle installed on the same system. If I start the 32 bit test database I then can not start the 64 bit test database. And vice versa. And this problem didn't exist until I enabled memory windows in the kernel and assigned the 32 bit database to a memory window.

Specifically I would like to hear from someone who has set up memory windows using both 64bit and 32bit Oracle. What hurdles you had to cross and do's and don'ts.

Thanks again!
Eric

[Eric Buckner]

Update.

We finally got the error resolved on the databases starting up. Now I have 2 64 bit databases running regularly and 1 32 bit database running in a memory window.

Now our 64 bit (8.1.7) listener is having problems making the connection to the 32 bit database (8.1.7). My guess is that since according to Oracle the 64 bit 8.1.7 doesn't make the getmemwindow call, the listener isn't either. However, I read somewhere in one of these messages that you had to have a different listener for each memory window. Is that really necessary? That seems like a bit to much overkill to me. I would think if the database could make the call then the listener should be able to as well.

Any ideas?

Thanks,
Eric

[Jaris Detroye]

Was this issue ever resolved? We have a mix of 320bit & 64-bin instances. The 32's are running up against the 1.75 limit. I was thinking about implementing memory windows, but your tale make me stop and think.

Have you gotten through this?

[Bill Hassell]

With memory windows, the shared memory inside the window is private to the applications that are started inside that window. Memory windows were designed to work around the crippling limits of 32bit apps. Trying to integrate 32 and 64 bit apps to share the same memory areas is going to be impossible.

I would be very concerned about the overall design. If multiple instances of Oracle are sharing memory (or possibly middleware), you'll need some expert help to make it all work together.

[Wodisch · Accepted solution]

Hi Eric,

AFAIK you'll have to run a separate instance of the oracle listener for each of the memory-windowed 32bit instances!
Be careful to start each 32bit-listener AND its 32bit-instance with the same memory-window-id!
Oh, and an additional 64bit-listener for all the 64bit instances, of course...

HTH,
Wodisch

[Dietmar Konermann]

Another option could be a listener allocating its memory from 32-bit-Quadrant 4, which is globally visible for all processes. If you start a 32-bit listener with space available in Q4 then all should be fine automatically, since we use first-fit (starting with Q4=.

BTW, using Q4 could be enforced by specifying IPC_GLOBAL with shmget(). But I doubt Oracle has an option to use this for its listener...

Regards...
Dietmar.

[Eric Buckner]

Sorry everyone I should have posted a follow up to this but have been extremely busy on other projects.

After much configuration testing, we came to the conclusion that Wood pointed out. You need to have separate listeners for each window.

We also went down the path of beating up our vendors to make at least the databases 64 bit compliant.

We had a couple of vendors to step up to the plate and tell us that after they tested they didn't see any problems with a 64-bit database. So as of now our problem is solved w/o having to implement memory windows. I still have it compiled into the kernel just in case, but as of now we are avoiding it like the plague.

Eric