Oracle Error skgpspawn.....Possible cause/solution

[Rita C Workman]

Just thought I'd post this, because I have been looking for a resolution to this today.

Loaded patches yesterday on my Production box (yes I loaded them on Dev box first a week ago, with no issues)...but kept getting our database clobbered with zombies till it fell with :

failed to restart multi-threaded.. skgpspawn3 ....ORA-0600 errors

A really sharp HP guy (Ed Jones) suggested checking the parms. Even though I hadn't made any kernel changes with the patch load...I checked and sure enough "maxuprc & shmmax" dropped back to default values. Both are dynamic so they were changed immediately.

Possible cause....the system file had somehow gotten out of whack, so when patches were loaded and kernel rebuilt it used a system file that did not have these parms values contained in it, thus causing them to drop back to default values.

Hope this helps somebody who maybe hits this situation..

Rgrds,
Rita

....No Postings Necessary...This was just informational for Forum Users ! ..

[Uday_S_Ankolekar]

Just curious, which patch(es)could have caused this. Would you mind shring this with forum??

-USA..

[Ross Zubritski]

Rita,

Please provide patches applied.

Thanks in advance.

RZ

[Patrick Wallek]

Hi Rita,

Sounds like you had quite fun Sunday. :)

I gather that this was on an 11i box?

Patrick

[Steven E. Protter]

It must be 11i because of the dynamic parameters.

I would like to know the patch set as well, though I agree probably the system file was messed up prior to installation.

SEP

[Rita C Workman]

Ask and you shall receive....

Rgrds,
Rita

[Ross Zubritski]

Ouch, definately a long weekend.

Thanks

RZ

[Rita C Workman]

Forgot to mention..

Yes the box is 11i/64bit.

The patches probably did not cause it....just pointed it out. More than likely it was the system file that was missing the values for these two parms...so when kernel reformed, these dropped back to default value.

Rgrds,
Rita

[Indira Aramandla]

Hi,

It looks like you are unable to spawn shared servers (dispatchers).

Solution:
1. Increase swap or memory,

--OR--

2. Reduce the number of shared servers (dispatchers) that can be started.

Note: If you are running on Unixware and Oracle 8.1.5, apply the patch for Bug Number 1003255. This patch fixes a problem with excessive memory use by shadow processes.

Explanation:
When you are running MTS and more shared servers need to be started, they are automatically started up to the number of max servers specified in the init.ora file.

This problem is occurring because you are running out of resources on your machine that are required for the servers to startup.

The error messages:

skgpspawn failed:category = 27143, depinfo = 24, op = pipe, loc = skgpspawn2
skgpspawn failed:category = 27142, depinfo = 11, op = fork, loc = skgpspawn3

indicate that you are failing to spawn a shared server. The errors translate to:

Therefore, because there is a lack of memory and swap available on the system, this is causing the operating system calls pipe() and fork() to fail. When these calls fail, the shared servers are unable to start.

[Jeff Schussele]

I would add that we've had Dec '02 patches do the following to us recently...

1) Cause a rewrite of the ftp command line in /etc/inetd.conf - caused the -a parm to be added w/o the benefit of having the /etc/ftpd/ftpaccess file - caused ftp denials.

2) Caused ntpd to fail at first boot after patch application. You see this in syslog...IF you're watching.

We're still tracking both these down. We have a sneaking suspicion that both have to do with patches NOT included in QPK or HWE bundles, but rather in "recommended" or security related patch bundles which MAY be entirely unique to us...but never say never.

rgds,
Jeff