SHMMAX

[Nobody's Hero]

Running Oracle 8.1.6 and Remedy on a K420 OS=11. I run an fbackup script, it shutsdown Remedy-Oracle-Does BBackup-Start Apps. During the shutdown I get "ORA-03113: end-of-file on communication channel". Oracle does not go all the way down. I noticed that the SHMMAX parm is set kinda low "134217728". All my other boxes are over 1gig. I just recently upgraded this box and patches to 11.0. Do you think the low shmmax parm could be causing this problem?

[Clemens van Everdingen]

Hi,

Follow this thread:

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0xb376abe92dabd5118ff10090279cd0f9,00.html

Clemens

[Emiel van Grinsven]

Hi,

check the following:

The shmmax 'Single shared memory segment' is limited to 1 GB (0x40000000)
on a 32-bit HP-UX 11.0 system. When running under the 64-bit operating
system, shmmax is limited to 1 TB (0x10000000000).

The maximum shared memory accessible (all segments/quadrants) is limited
to 2.75 GB on 32-bit, and 4 TB on 64-bit HP-UX systems. SAM's (System
Administration Manager) online help incorrectly states that the shmmax
maximum value is 1.75 GB (0x70000000).

grt, E

[Steven Gillard_2]

I would expect a low shmmax to cause problems on database startup, not shutdown. How large is your SGA?

The 'end of file on communication channel' error usually means the server process your sqlplus/svrmgr session was talking to has died for some reason. Are there any errors in the alert log? Does this problem only occur when running the script - what happens when you start / stop the database from an interactive session?

Regards,
Steve

[Nobody's Hero]

Steve,When I came in this morning, I went into svrmgr,connect internal and did a shutdow. I got a mssage that oracle was not available. I had to do a shutdown abort. Then I re-ran the startup scripts and everything came up fine. I dont see any errors in the alert log.

[Bill Hassell]

Shared memory for 32 bit applications is a single addressing space in which all programs must fight for space. While you can link programs to address more than 1Gb of space, there is no guarentee that a contiguous (must be contiguous) space of the size needed will be available. So if Oracle's SGA is 800 megs, it may fail because fbackup needs 150 megs and it's location is right in the middle of the shared area. This shared area contains shared libraries, memory mapped files, shared memory segments, etc for all 32bit programs and can get very fragmented.

Even if you have 10Gb of RAM, the limited 32bit addressing space will not improve. The issue is planned sharing of the space (or switch to a 64bit version which has no practical limits, or use memory windows) by starting and stopping applications in a specific order to minimize fragmentation of the shared area.

Read the docs in /usr/share/doc on mem_mgt, proc_mgt and if you are up to date on patches, mem_windws. And get a copy of shminfo so you can actually see the fragmentation and true memory map for 32bit programs:

ftp://contrib:9unsupp8@hprc.external.hp.com/sysadmin/programs/shminfo/

[Nobody's Hero]

Steve, Also, SGA is 50 Mb

[Steven Gillard_2]

Robert,

In that case it can't be a shmmax problem as this is just a fence to limit the size of a shared memory segment. If your SGA is only 50Meg you're well under your current setting of 128Meg.

It must be something else causing the problem... here's a heap of other things for you to check:

- Are there any files dumped in the cdump / udump directories? Usually a crashing Oracle server process will leave something there.

- Does this problem occur every time the script runs or is this the first time?

- Exactly where in the shutdown does the error occur - is it straight after the SHUTDOWN IMMEDIATE is performed or before (ie after the CONNECT)? Can you provide some more info here?

Regards,
Steve

[Nobody's Hero]

Steve,,,
Nothing in Cdump. Here is a file in udump:

/app/oracle/admin/remedyp/udump/ora_17531_remedyp.trc
Oracle8i Enterprise Edition Release 8.1.7.0.0 - Production
With the Partitioning option
JServer Release 8.1.7.0.0 - Production
ORACLE_HOME = /app/oracle/product/8.1.7
System name: HP-UX
Node name: ihshp4
Release: B.11.00
Version: C
Machine: 9000/869
Instance name: remedyp
Redo thread mounted by this instance: 1
Oracle process number: 12
Unix process pid: 17531, image: oracle@ihshp4

*** SESSION ID:(11.22) 2002-04-10 23:05:37.262
SHUTDOWN: waiting for logins to complete.
*** 2002-04-10 23:10:48.374
SHUTDOWN: waiting for logins to complete.
*** 2002-04-10 23:15:59.429
SHUTDOWN: waiting for logins to complete.
*** 2002-04-10 23:21:10.514
SHUTDOWN: waiting for logins to complete.
*** 2002-04-10 23:26:21.569
SHUTDOWN: waiting for logins to complete.
*** 2002-04-10 23:31:32.647
SHUTDOWN: waiting for logins to complete.
*** 2002-04-10 23:36:43.736
SHUTDOWN: waiting for logins to complete.
*** 2002-04-10 23:41:54.796
SHUTDOWN: waiting for logins to complete.
*** 2002-04-10 23:47:05.915
SHUTDOWN: waiting for logins to complete.
*** 2002-04-10 23:52:16.971
SHUTDOWN: waiting for logins to complete.
*** 2002-04-10 23:57:28.047
SHUTDOWN: waiting for logins to complete.
*** 2002-04-11 00:02:39.105
SHUTDOWN: waiting for logins to complete.
*** 2002-04-11 00:07:50.163
SHUTDOWN: waiting for logins to complete.
*** 2002-04-11 00:13:01.222
ora_17531_remedyp.trc (19%)

*****************************************
also, here is the output from my backup log during shutdown of the DB.

I wanted to show you but I dont know how to attach a file on this site, help.

[Steven Gillard_2 · Accepted solution]

Robert,

The attachment box should appear below the text window on the reply page.

Also it appears from the trace that you are doing a normal SHUTDOWN of Oracle, instead of a 'SHUTDOWN IMMEDIATE'. That means Oracle will wait for all open sessions to be closed before shutting down. Is that the behaviour you want?

Regards,
Steve

[Nobody's Hero]

Thanks Steve, I didn't notice that. I will change the shutdown script to do an 'immediate'
this could be the problem for sure, I'll let you know tomorrow after I make the change.

Thanks,
Bob Menefee

[Nobody's Hero]

Hey Steve,
Looks like changing my shutdown to 'immediate' helped. Backup-shutdown-startup ran fine last night. I guess the hanging sql connections were causing the problem, 'immediate' did seem to not care and proceeded with the shutdown.

Thanks to everyone.

Bob