Memory windows problem

[Paruj_2]

Dear All,
I have problem on 2 servers (V2600), memory 8GB/server and both are running MC/SG cluster.
On each server, I have 3 oracle instance running. We also implement memory windows for our environment. The problem occurr when the cluster tried to move database from fail-server.It 's look like some limitation of my setting environment.

Can anybody tell me:
What is the limitation for my environment?
What is the configuration that should be?

[Patrick Wallek]

What kind of problem occurred? What error message did you get? Have you checked any log files?

To implement Memory Windows for Oracle you have to set the max_mem_win (I think) kernel parameter and then configure the /etc/services.window file. It is not difficult.

Give us some more information and we may be able to help more.

[Paruj_2]

All of my cluster nodes already configured and using /etc/services.window . The problem shown when it tried to fail-over. It look like some resource not enough. Why I said that ? Because, If I stop database on adoptive node before do the fail-over. All of databases from primary node can startup and running on adoptive node.

The below error message is example log in cluster directory ( when tried to startup db without shutdown db on adoptive node before):


Oracle Server Manager Release 3.1.7.0.0 - Production

Copyright (c) 1997, 1999, Oracle Corporation. All Rights Reserved.

Oracle8i Enterprise Edition Release 8.1.7.0.0 - Production
With the Partitioning option
JServer Release 8.1.7.0.0 - Production

SVRMGR> Connected.
SVRMGR> ORACLE instance started.
Total System Global Area 162339860 bytes
Fixed Size 76820 bytes
Variable Size 78761984 bytes
Database Buffers 81920000 bytes
Redo Buffers 1581056 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 10 - see DBWR trace file
ORA-01110: data file 10: '/dbgisPR1/oracle/TAOGIS/oradata1/taogis_cporange04.dbf'
SVRMGR> Server Manager complete.

[twang]

Take a look at the following doc:
/usr/share/doc/mem_wndws.txt.Z

[Sridhar Bhaskarla]

Hi Paruj,

This does not have anything to do with ServiceGuard. All it does is to start the database based on the startup/shutdown script you have for the database.

I would suggest you to do the following.

1. Make sure the configuration files of your oracle are same on all the nodes in the cluster.
2. Make sure /etc/services.window files are the same on all the nodes.
3. Mount the filesystems manually (vgchange -a e vg01, mount /dev/vg01/lvol1 /dbxxx etc). Start the database manually using svrmgrl/sqlplus and see if it works. If not, then you will have to fix the configuration. Do not try anything through serviceguard until you have the database up and running.
4. Once step 3 is fixed, look at your startup/shutdown script. Run it manually with the filesystems mounted. This will ensure that serviceguard will work. Fix the script if there are any problems.
5. Stop oracle, unmount the filesystems and deactivate the VGs (vgchange -a n). Start the database through the package.

Repeat this on all the nodes that are configured as adoptive nodes.

-Sri

[Paruj_2]

Hi guy,

The MC/SG configuration not be a issue. The issue is can't multiple oracle 32 bit database on adoptive when primary has failed.

I need the one who has experience in multiple oracle 32 bit instances on HP-UX 11.0 in cluster environment.

P.S. I got 3 instances on each server. And SGA per instance around 700-800 MB.

[Sridhar Bhaskarla]

Paruj,

It's not a serviceguard issue. That's why I mentioned to mount the filesystems manually and fix the problem.

You knew already that for 32-bit windows, the maximum available shared memory is 1.75 GB with Share_Magic. Even with memory windows that can allow you to use upto 1-2 GB per window (based on your Sh*_Magic), the rule of contiguity still remains. With 800 MB of shared segment, you should have each database with it's own memory window. If not, it may be the issue.

-Sri

[Massimo Bianchi]

Hi,
what are you kernel parameters ?

I suspect problems in the nfile and nflocks .

In general, it's best that you close all your oracle instances, before trying to start them in the adoptive node, because the can run for resources like file locks, sharem memory segments, semaphores.

I don't think of semaphores or shared memory, otherwise you will not even be able to allocate sga, but file locks can be an issue.

Another very usefull procedure, in case of failover, is the cleaning of shared memory.

Not always oracle cleanup it perfectly, there are utilities like sysresv that can help you in having a clean start.

HTH,
Massimo