develooper Front page | perl.dbi.users | Postings from June 2009

Re: DBD-Oracle 1.23 reports ORA-24334 in t/58object.t

Thread Previous
From:
Charles Jardine
Date:
June 9, 2009 03:10
Subject:
Re: DBD-Oracle 1.23 reports ORA-24334 in t/58object.t
Message ID:
4A2E3502.4050601@cam.ac.uk
On 08/06/09 15:43, Martin Gainty top-posted as follows:
> Good Afternoon Charles and Jeremy
> 
> Are there any potential side-effects for turning off
> signal-processing? i am wondering what the implications might be for
> turning off signal events to Processors for multi-process
> configurations?

> http://www.scribd.com/doc/2713811/Oracle-Configuration-And-Tuning-MultiThreaded-Server-Architecture

This was in response to this posting of mine:

>> On 05/06/09 06:31, Peter Jeremy wrote:

[snip]

>>> These two tests fail because Oracle is setting a SIGCHLD handler so
>>> the waitid(2) in system() is returning ECHILD

[snip]

>> I believe you will only see this error if you are using the 'bequeather'
>> to connect to a server on the same host as the client. You can fix it
>> by adding
>>
>>   bequeath_detach = yes
>>
>> to your sqlnet.ora file.

I believe that Martin has been misled by Oracle's poor documentation
of the BEQUEATH_DETACH protocol option. There is a good description
of this option in Metalink knowledge article 452122.1, with useful
references.

BEQUEATH_DETACH controls whether server processes launched directly
from client processes during the setup of a 'Bequeather' connection
do or do not detach from the client by forking a second time.

If BEQUEATH_DETACH is set to 'no', the second fork does not occur -
The client process remains the parent of the server process, and
Oracle sets a SIGCHLD handler in the client process to clear up when
the server process terminates.

If the setting is yes, a second fork produces a server process whose
parent is the init process. The init process automatically deals with
the clearup of the server process, and Oracle has no need to mess
with signal handlers in the client at all.

This is the only effect of setting BEQUEATH_DETACH. BEQUEATH_DETACH
has no effect on remote connections, or on local connections mediated
by a listener. Server processes launched from a listener always detach.

The only downside to setting BEQUEATH_DETACH=yes is that the 
Parent Process Id (PPID) of the server process, as displayed by ps(1),
will always be that of the init process (i.e. 1 in most unixes).
With BEQUEATH_DETACH=no, the PPID of the server process identifies
the client process. Some DBAs may have found this useful.

Server processes created by the bequeather are always dedicated, so
and article about multi-threaded servers must be irrelevant in this
context.

-- 
Charles Jardine - Computing Service, University of Cambridge
cj10@cam.ac.uk    Tel: +44 1223 334506, Fax: +44 1223 334679

Thread Previous


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About