Showing posts with label open_tran. Show all posts
Showing posts with label open_tran. Show all posts

Friday, March 23, 2012

Open_tran in sys.sysprocesses has unexpected count

I'm running SQL Server 2005 SP1 on WinXP SP2.

I'm running a query to look for open transactions or blocked transactions. The actual query I'm running registers as having 2 open transactions and I can't figure out why. It seems to have something to do with the temp table because I don't get the open transactions when there is no temp table. I could perhaps see why I might have 1 open transaction pertaining to the open temp table, but why 2. Here is the query and the data from sys.sysprocesses:

IF object_id('tempdb.dbo.#MyProcesses','U') is not NULL
BEGIN DROP table #MyProcesses; END
DECLARE @.MyVariable varchar(100)
, @.Mycmd nvarchar(1000)
, @.LoginTime int
, @.LastBatch int
, @.LastBatchFilter datetime
, @.LoginTimeFilter datetime;
SELECT @.MyVariable = '' , @.LoginTime = -600 , @.LastBatch = -145 ;

SELECT @.LastBatchFilter = DATEADD(mi,@.LastBatch,Current_timestamp);
SELECT @.LoginTimeFilter = DATEADD(mi,@.LoginTime,Current_timestamp);

-- I've reduced the number of columns in my SELECT for this example
SELECT b.[name] MyDB
, a.spid
, a.blocked
, a.open_tran
, RTRIM(a.program_name) program_name
INTO #MyProcesses
FROM sys.sysprocesses a
JOIN sys.sysdatabases b on a.dbid = b.dbid
WHERE (a.blocked = 1 or a.open_tran > 0);

Select * from #MyProcesses

MyDB spid blocked open_tran program_name
master 56 0 2 Microsoft SQL Server Management Studio - Query

Please educate me.

Thanks,

Paul

The "transaction count" is not really that important. There are many things which implicitly create transactions. The important item is "blocked".

In your case, creating a temp table with an @.tablename creates a transaction around the query, so when it ends, it "rolls back" the temp table and deletes it. This is an internal mechanisim and not under your control.sql

Open_tran in sys.sysprocesses has unexpected count

I'm running SQL Server 2005 SP1 on WinXP SP2.

I'm running a query to look for open transactions or blocked transactions. The actual query I'm running registers as having 2 open transactions and I can't figure out why. It seems to have something to do with the temp table because I don't get the open transactions when there is no temp table. I could perhaps see why I might have 1 open transaction pertaining to the open temp table, but why 2. Here is the query and the data from sys.sysprocesses:

IF object_id('tempdb.dbo.#MyProcesses','U') is not NULL
BEGIN DROP table #MyProcesses; END
DECLARE @.MyVariable varchar(100)
, @.Mycmd nvarchar(1000)
, @.LoginTime int
, @.LastBatch int
, @.LastBatchFilter datetime
, @.LoginTimeFilter datetime;
SELECT @.MyVariable = '' , @.LoginTime = -600 , @.LastBatch = -145 ;

SELECT @.LastBatchFilter = DATEADD(mi,@.LastBatch,Current_timestamp);
SELECT @.LoginTimeFilter = DATEADD(mi,@.LoginTime,Current_timestamp);

-- I've reduced the number of columns in my SELECT for this example
SELECT b.[name] MyDB
, a.spid
, a.blocked
, a.open_tran
, RTRIM(a.program_name) program_name
INTO #MyProcesses
FROM sys.sysprocesses a
JOIN sys.sysdatabases b on a.dbid = b.dbid
WHERE (a.blocked = 1 or a.open_tran > 0);

Select * from #MyProcesses

MyDB spid blocked open_tran program_name
master 56 0 2 Microsoft SQL Server Management Studio - Query

Please educate me.

Thanks,

Paul

The "transaction count" is not really that important. There are many things which implicitly create transactions. The important item is "blocked".

In your case, creating a temp table with an @.tablename creates a transaction around the query, so when it ends, it "rolls back" the temp table and deletes it. This is an internal mechanisim and not under your control.

open_tran = 1

We use i-net sprinta jdbc driver and use pooled connections. What I've
noticed is that when connections are not being used and are in sleeping
state Open_Tran in the sysprocesses table is 1 and not 0. Anyone know
why? We commit our transactions.
Doesn't matter if you COMMIT or not, if you continuely open another one,
then you'll see it open.
Here's what I've seen when our developer's have used JDBC drivers. They
continually SELECT 1 to keep their pooled connections open. They use SET
IMPLICIT TRANSACTIONS ON, which automatically starts transactions without
having to explicitly use the BEGIN TRANSACTION statement. Problem is that
they start on most T-SQL statements, including SELECT.
Sincerely,
Anthony Thomas

"Ken" <kshapley@.sbcglobal.net> wrote in message
news:1102791403.549396.160930@.z14g2000cwz.googlegr oups.com...
We use i-net sprinta jdbc driver and use pooled connections. What I've
noticed is that when connections are not being used and are in sleeping
state Open_Tran in the sysprocesses table is 1 and not 0. Anyone know
why? We commit our transactions.
|||Anthony,
You are right. Now my question is does this have any negative
consequences to performance. We are an asp with 100s of databases on
our sql 2000 servers, each with there own pooled connections. I have on
average over 3000 - 4000 of these connections always in an open
transaction state?
|||Yep, but I would be worried about that many concurrent connections, open
transactions or not. Are you running the 32-bit or 64-bit installation?
I ask because 32-bit has a serious memory drawback. Although the higher end
stuff can create a very nice Buffer Pool with AWE, all of the other memory
objects must be resident in the 2 GB--or 3 GB, depending on versions,
editions, and parameters--USER MODE address space. Moreover, the conection
structures are part of what lives in the MEM TO LEAVE region; so, you are
even more confined.
Now, you add object lock structures and multiple concurrent open
transactions and you are inviting disaster. I would seriously look at going
multi-instanced or the 64-bit installation, with a TON OF MEMORY, or course.
Sincerely,
Anthony Thomas

"Ken" <kshapley@.sbcglobal.net> wrote in message
news:1102990516.435766.91180@.c13g2000cwb.googlegro ups.com...
Anthony,
You are right. Now my question is does this have any negative
consequences to performance. We are an asp with 100s of databases on
our sql 2000 servers, each with there own pooled connections. I have on
average over 3000 - 4000 of these connections always in an open
transaction state?

open_tran = 1

We use i-net sprinta jdbc driver and use pooled connections. What I've
noticed is that when connections are not being used and are in sleeping
state Open_Tran in the sysprocesses table is 1 and not 0. Anyone know
why? We commit our transactions.Doesn't matter if you COMMIT or not, if you continuely open another one,
then you'll see it open.
Here's what I've seen when our developer's have used JDBC drivers. They
continually SELECT 1 to keep their pooled connections open. They use SET
IMPLICIT TRANSACTIONS ON, which automatically starts transactions without
having to explicitly use the BEGIN TRANSACTION statement. Problem is that
they start on most T-SQL statements, including SELECT.
Sincerely,
Anthony Thomas
"Ken" <kshapley@.sbcglobal.net> wrote in message
news:1102791403.549396.160930@.z14g2000cwz.googlegroups.com...
We use i-net sprinta jdbc driver and use pooled connections. What I've
noticed is that when connections are not being used and are in sleeping
state Open_Tran in the sysprocesses table is 1 and not 0. Anyone know
why? We commit our transactions.|||Anthony,
You are right. Now my question is does this have any negative
consequences to performance. We are an asp with 100s of databases on
our sql 2000 servers, each with there own pooled connections. I have on
average over 3000 - 4000 of these connections always in an open
transaction state?|||Yep, but I would be worried about that many concurrent connections, open
transactions or not. Are you running the 32-bit or 64-bit installation?
I ask because 32-bit has a serious memory drawback. Although the higher end
stuff can create a very nice Buffer Pool with AWE, all of the other memory
objects must be resident in the 2 GB--or 3 GB, depending on versions,
editions, and parameters--USER MODE address space. Moreover, the conection
structures are part of what lives in the MEM TO LEAVE region; so, you are
even more confined.
Now, you add object lock structures and multiple concurrent open
transactions and you are inviting disaster. I would seriously look at going
multi-instanced or the 64-bit installation, with a TON OF MEMORY, or course.
Sincerely,
Anthony Thomas
"Ken" <kshapley@.sbcglobal.net> wrote in message
news:1102990516.435766.91180@.c13g2000cwb.googlegroups.com...
Anthony,
You are right. Now my question is does this have any negative
consequences to performance. We are an asp with 100s of databases on
our sql 2000 servers, each with there own pooled connections. I have on
average over 3000 - 4000 of these connections always in an open
transaction state?