dbTalk Databases Forums  

Re: Our continueing saga with ECDA and MSSQL

sybase.public.omni sybase.public.omni


Discuss Re: Our continueing saga with ECDA and MSSQL in the sybase.public.omni forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
Bill Menton
 
Posts: n/a

Default Re: Our continueing saga with ECDA and MSSQL - 04-26-2005 , 09:16 AM






Hi Joe,

Sorry it took so long to reply. Please crosspost CIS questions to
sybase.public.omni as well, please.

I'm glad you found a workaround, though lowering "cis cursor rows" will
probably negatively affect performance.

Please post your DDL and the problem statement so we can have a look at it.

Thanks,
Bill Menton
CIS QA

jbuhl wrote:
Quote:
Hello,

ASE 12.5.0.3 Solaris
ECDA 12.5 (latest patch) Solaris
MSSQL 2000 XP

We were getting deadlock errors when doing a simple join
between a proxy table (mssql) and an ASE table. I resolved
this by lowering the "cis cursor rows" configuration
parameter to a value or 25. It seems MSSQL was escalating
the locks and causing problems with the cursor on the ASE
side. But even though things are now working when I look
at the locks on MSSQL during this query they are of lock
type "x" I am pretty sure this is exclusive.

Now this all goes back to my early question to which I never
got an answer (See my post on Oct 5th, 2005 titled ECDA
locking problems with MSSQL200). Why is ASE/CIS causing
exclusive locks on the MS side for a simple query? I
suspect that CIS is opening a cursor without declaring it as
"read only". I believe the default is updatable , which
would result in an exclusive locks I am seeing and the lock
escalation on the MS side.

If anybody has any ideas or similiar experiences with this
behavior I would appreciate any information you have

Thanks
Joe

Reply With Quote
  #2  
Old   
Paul
 
Posts: n/a

Default Re: Our continueing saga with ECDA and MSSQL - 04-26-2005 , 01:14 PM






Hi Joe,

One thing I notice when I run a very simple join is that ASE/CIS sends a
TDS_LANGUAGE to ECDA, so the cursor is internal to CIS. On the ODBC Side,
ECDA does a SQLPrepare/SQLExecute. With a sniffer I can see that the ODBC
driver sends this sp_execute, which I assume is related to the statement
that was prepared. I also see a commit issued after all of this so this
implies some sort of locking, though I can never monitor locks when I do it
(my query is very simple so maybe the locks are set quickly so that I cannot
see them at all).

I am guessing that this sproc starts a transaction on MS SQL Server. If I
force a transaction on the ASE/CIS side, I do see that there are some locks
on the ms sql server side, one is "IX", others "IU", "U". I do not know the
details of your join statement, but I suspect the ODBC driver itself is
setting up the locks, based on the type of queries delivered by ASE/CIS.

I also notice that ECDA sets AutoCommit to OFF, which means implicit
transactions are turned on (When I turn OFF the isolation level) - so I am
not sure if this is appropriate or not. It seems that no metter what I set
the Access Service to do, like trying to turn off the implicit transactions,
it does not seem to matter.

This might warrant further research, leading to a possible connection
property on the ECDA to NOT turn on implicit transactions - this might
help - and instead of prepare / execute, maybe the ecda could be forced to
do SQLExecDirect, assuming no parameters are involved in the query (if
parameters are used for some reason, this goes to the dreaded
Prepare/Execute combo - which forces the driver to use sp_execute - which I
find is some sort of undocumented feature of the MS ODBC Driver).

PV


"Bill Menton" <wmenton (AT) sybase (DOT) com> wrote

Quote:
Hi Joe,

Sorry it took so long to reply. Please crosspost CIS questions to
sybase.public.omni as well, please.

I'm glad you found a workaround, though lowering "cis cursor rows" will
probably negatively affect performance.

Please post your DDL and the problem statement so we can have a look at
it.

Thanks,
Bill Menton
CIS QA

jbuhl wrote:
Hello,

ASE 12.5.0.3 Solaris
ECDA 12.5 (latest patch) Solaris
MSSQL 2000 XP

We were getting deadlock errors when doing a simple join
between a proxy table (mssql) and an ASE table. I resolved
this by lowering the "cis cursor rows" configuration
parameter to a value or 25. It seems MSSQL was escalating
the locks and causing problems with the cursor on the ASE
side. But even though things are now working when I look
at the locks on MSSQL during this query they are of lock
type "x" I am pretty sure this is exclusive.

Now this all goes back to my early question to which I never
got an answer (See my post on Oct 5th, 2005 titled ECDA
locking problems with MSSQL200). Why is ASE/CIS causing
exclusive locks on the MS side for a simple query? I
suspect that CIS is opening a cursor without declaring it as
"read only". I believe the default is updatable , which
would result in an exclusive locks I am seeing and the lock
escalation on the MS side.

If anybody has any ideas or similiar experiences with this
behavior I would appreciate any information you have

Thanks
Joe



Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.