Wednesday, March 28, 2012
Lock timeout
I need to set a default value for lock timeout on all
connections. Is there any way to do this without running:
set @.@.lock_timeout = ?
at the beginning of every connection? I'd like a global
setting on this.
Best regardsHi,
I feel there is no setting to control Lock time out at server level.
Thanks
Hari
MCDBA
"Johnny" <anonymous@.discussions.microsoft.com> wrote in message
news:0a5c01c3c8f9$8a88d120$a001280a@.phx.gbl...
> Hi all,
> I need to set a default value for lock timeout on all
> connections. Is there any way to do this without running:
> set @.@.lock_timeout = ?
> at the beginning of every connection? I'd like a global
> setting on this.
> Best regardssql
Friday, February 24, 2012
Local Connections & General network Error
running on the server with SQL Agent) it really doesn't pay to FORCE the
connection to use TCP sockets, with a TCP alias. Since the connection is
local to the server, the SQL Server can utilize Shared memory or Local
pipes and never touch the network.
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.ok. I'll try tonight to run the job with Name Pipe
Activated. I give you a feelback tomorrow.
thanks
quote:
>--Original Message--
>When connections are being made on the local server (as
with local jobs
quote:
>running on the server with SQL Agent) it really doesn't
pay to FORCE the
quote:
>connection to use TCP sockets, with a TCP alias. Since
the connection is
quote:
>local to the server, the SQL Server can utilize Shared
memory or Local
quote:
>pipes and never touch the network.
>Thanks,
>Kevin McDonnell
>Microsoft Corporation
>This posting is provided AS IS with no warranties, and
confers no rights.
quote:|||Ok now after 10 days I can tell you I don't received
>
>.
>
again the General NEtwork Error.
But now I got some type of lock like LCK_M_S, OLEDB,
CXPACKET...
How I can eliminate this Wait Type ?
quote:
>--Original Message--
>When connections are being made on the local server (as
with local jobs
quote:
>running on the server with SQL Agent) it really doesn't
pay to FORCE the
quote:
>connection to use TCP sockets, with a TCP alias. Since
the connection is
quote:
>local to the server, the SQL Server can utilize Shared
memory or Local
quote:
>pipes and never touch the network.
>Thanks,
>Kevin McDonnell
>Microsoft Corporation
>This posting is provided AS IS with no warranties, and
confers no rights.
quote:
>
>.
>
Monday, February 20, 2012
Local and Remote Connections question
Hello all,
We are currently testing all our applications on Vista and SQL Server 2005. Everything is running and working, but our applications that connect to SQL Server 2005 are running very slow. We have our client installed on a vista pc running SQL Server 2005 on the same pc. I was trying to troubleshoot the problem and realized that we had "Local connections only" checked in the Surface Area Configuration tool, and changed it to "Local and remote connections". After making this change all our apps seem to be running much faster. I just didn't expect this to be the problem since we were connecting from the same computer that is running the server. Can anyone explain to me why this has made the difference in performance?
Thanks for your time and attention,
DrewV
Hi DrewV,
How many connections were you attempting to sql server through your application(s).
How much memory do you have on the box and how much memory is configured for SQL Server?
regards
Jag
|||There is only one connection being opened by our app.
The machine is a brand new Dell Precision 390 with 2GB or ram.
We are running SQL Express which I think uses a max of 1GB.
It is almost like it is trying to connect with a "remote" connection and trying locally after the first attempt fails. I just don't understand why since we are running on the same machine.
|||I'm only guessing here, but the local connections system generally uses shared memory to pass the information between the client and server avoiding the network protocols. However this requires an area of memory which is accessible to both processes.
It may be that this is seen as a security weakpoint in Vista (direct access to non-process specific memory ... hmmm) so that there is a significant amount of checking and policing of such access which did not occur before and so slows down the whole process. The remote connection goes through the network stack and so is probably considered less of a vulnerability and so does not need the extra control.
Maybe SQL Server 2005 prefers on Vista to use the tcp/ip stack (if available) rather than shared memory (because it will be faster) - but this is only possible if you enable remote as well as local connections.
Also you don't say which service pack of SQL Server 2005 you are using.
|||Thanks for your response. We are on Service Pack 2.