Conference orarep::nomahs::sql_services

Hi Sue,


I have a customer experiencing this problem.  They have been running V6.1 of
SQL/Services, no patches, for quite some time.  They never had this problem
before.  Now they have seen it 2ce in the same week.  I told him that ECO 1 
of SQL/Services V6.1 fixes the problem, but he wants to know what CAUSES the
problem so that he can "workaround it".  He cannot upgrade.  Why did it work
for so long and all of a sudden stop?  He is hoping the IVLOCKID error might
be some system resource he can change to prevent the error from occuring, but
from reading this note and other notes on this problem, I doubt it.  In any
case, there was never a really clear reason for why this problem occurs other
than the server shutting down and the executor trying to get rid of some 
lock it has on the comm server.  I think that is what I read! :)

This customer said that they are not shutting down the server... folks are just
working when this happens.  By the way, it appears that there are so many
executor errors with this ivlockid error that the comm server is shut down
due to too many errors.  There are no other errors that he sees.  

I have asked for all the log files and the bugcheck dump, but in the meantime,
is there something he can do to alleviate the problem, what exactly is the
problem, and is there some workaround for it other than upgrade?

Thanks
Renee

Hi Renee,

SQL/Services 6.1 and earlier used locks to detect process termination.  The 
communications server created and held its own lock.  As each excute server 
came up, it queued up a request for the comm server lock.  If an execute 
server ever gets the comm server lock, it knows the comm server has shut down.

The only time we've seen the IVLOCKID or COMLCKDEQEXE error was when the comm 
server shut down.  An execute server was then granted the comm server lock.
It attempts to deq the lock so the next executor can detect that the comm 
server has shutdown.  Sometimes this deq fails.  We never did figure out why.
We only tried to deq the lock if our enq had suceeded - so the deq should have
succeeded.  But it really didn't matter since we shut down the execute server 
process when we detect comm server shutdown, and process shutdown will 
release our locks.

If your customer is really seeing these errors while the comm server is up 
and running, this is a problem we haven't run into before.  But I'd be 
suspicious especially since you did mention that they see a comm server 
failure due to too many errors.  The comm server shouldn't consider it too 
many erorrs if lots of execute servers fail with IVLOCKID or COMLCKDEQEXE... 
so I'd guess the comm server came down for anther reason and that's what 
started the flurry of execute server errors.

Sue

>If your customer is really seeing these errors while the comm server is up 
>and running, this is a problem we haven't run into before.  But I'd be 
>suspicious especially since you did mention that they see a comm server 
>failure due to too many errors.  The comm server shouldn't consider it too 
>many erorrs if lots of execute servers fail with IVLOCKID or COMLCKDEQEXE... 
>so I'd guess the comm server came down for anther reason and that's what 
>started the flurry of execute server errors.

I think your right.  I asked the customer what kind of failures they are 
seeing before all this happens.  He said they changed the application, so 
recently they have incurred many invalid passwords due to the changed 
application.  Would the comm server shut down due to too many authorization
failures?  If so, is there a way to control the limit of failures the comm
server will allow before it shuts itself down?

Renee

Nope - the comm server should stay up and running regardless of the number of  
authorization failures.  If the comm server shutdown, they should have a log 
and dump file.  These would help us determine the cause of the shutdown.

Sue

I've asked him for a copy of the SQLSRV$.LOG file... I still don't have
it and I asked a couple days ago!  Will look into it when I get it.

Thanks!
Renee

I have exactly the same problem after upgrading to Rdb V6.1-04
and SQL Services V6.1-0 for VAX/VMS V6.2.

I have contacted Oracle Belgium (Luc Allemeersch)
who adviced me to install SQL Services V6.1-02

I have this problem only, for pre-attached databases, i.e.
with a Database Class, this is an entry in 

jgofi2> type sys$startup:sqlsrv*61.dat/tail
SYS$COMMON:[SYS$STARTUP]SQLSRV$CONFIG61.DAT;5
...
-- ----------------------------------------------------------
TYPE    "ROSSFA_UTO"
STARTUP "SQLSRV$SRV61"
USER    "ROSSFAREP"
EXECUTE "ATTACH 'FILENAME disk$APPLIC_914:[ROSSDATA_ABE.FA_RDB]RSI_FA_DATABASE'"
IDENT   "RSI_FAUSER"
MIN     1
MAX     20
IDLE    0



One work-around is to let the user attach explicitly from her PC running
MS-access and include the following:

Attach Statement: attach 'filename ross_abe_fa_database'

rather than using the MS-Access 'Data Source Name'.


Therefore, on the VMS Server I have included in the application
startup now:

$ define /system ross_abe_fa_database -
	disk$APPLIC_914:[ROSSDATA_ABE.FA_RDB]RSI_FA_DATABASE