Hi all,
we have a strange problem in SQL2000 SP3a with SQLTransaction's.
When running SQL Profiler the duration for some SQLTransactions (Commit) are
over six seconds, but the individual SQL statements (sp's) are executed at n
o
time at all.
I've used sp_lock but there are no locks.
Here's an extract from SQLProfiler:
SQLTransaction Commit 6796 5 2005-03-04 15:30:27.887 2005-03-04
15:30:34.683 DTCXact 16335154 sa
Any Ideas ?
Regards Tommy S.Check out master..sysprocesses and find out what the waittypes are
to determine what is causing the extended commit operation.
is the Tlog file on the same disk as the data file . .how busy is the server
?
is this constantly reproduceable? or is it intermittent?
HTH
"Tommy S?derkvist" wrote:
> Hi all,
> we have a strange problem in SQL2000 SP3a with SQLTransaction's.
> When running SQL Profiler the duration for some SQLTransactions (Commit) a
re
> over six seconds, but the individual SQL statements (sp's) are executed at
no
> time at all.
> I've used sp_lock but there are no locks.
> Here's an extract from SQLProfiler:
> SQLTransaction Commit 6796 5 2005-03-04 15:30:27.887 2005-03-04
> 15:30:34.683 DTCXact 16335154 sa
> Any Ideas ?
> Regards Tommy S.
>|||Thanks,
I will try to check out the waittypes the next time I see a long running
transaction.
Yes, the log and the datafile are located on the same disk.
The CPU's (4 of them) are almost idle.
The problem is intermittent and it doesn't seem to be dependent on the
number of users, it can occur at early evening when the number of users
decrease significant.
/Tommy
"Olu Adedeji" wrote:
[vbcol=seagreen]
> Check out master..sysprocesses and find out what the waittypes are
> to determine what is causing the extended commit operation.
> is the Tlog file on the same disk as the data file . .how busy is the serv
er?
> is this constantly reproduceable? or is it intermittent?
> HTH
> "Tommy S?derkvist" wrote:
>|||"Tommy S?derkvist" <TommySderkvist@.discussions.microsoft.com> schrieb im
Newsbeitrag news:72BF587D-E3CF-41FE-9EC8-5681C62E472B@.microsoft.com...
> Thanks,
> I will try to check out the waittypes the next time I see a long running
> transaction.
> Yes, the log and the datafile are located on the same disk.
> The CPU's (4 of them) are almost idle.
> The problem is intermittent and it doesn't seem to be dependent on the
> number of users, it can occur at early evening when the number of users
> decrease significant.
My guess would be that you have an IO bottleneck which makes tx log
writing slow. You could use perfmon to verify this theory.
robert
[vbcol=seagreen]
> /Tommy
> "Olu Adedeji" wrote:
>
server?[vbcol=seagreen]
(Commit) are[vbcol=seagreen]
executed at no[vbcol=seagreen]
Showing posts with label profiler. Show all posts
Showing posts with label profiler. Show all posts
Friday, March 30, 2012
Long running SQLTransaction
Hi all,
we have a strange problem in SQL2000 SP3a with SQLTransaction's.
When running SQL Profiler the duration for some SQLTransactions (Commit) are
over six seconds, but the individual SQL statements (sp's) are executed at no
time at all.
I've used sp_lock but there are no locks.
Here's an extract from SQLProfiler:
SQLTransaction Commit 6796 5 2005-03-04 15:30:27.887 2005-03-04
15:30:34.683 DTCXact 16335154 sa
Any Ideas ?
Regards Tommy S.Check out master..sysprocesses and find out what the waittypes are
to determine what is causing the extended commit operation.
is the Tlog file on the same disk as the data file . .how busy is the server?
is this constantly reproduceable? or is it intermittent?
HTH
"Tommy Söderkvist" wrote:
> Hi all,
> we have a strange problem in SQL2000 SP3a with SQLTransaction's.
> When running SQL Profiler the duration for some SQLTransactions (Commit) are
> over six seconds, but the individual SQL statements (sp's) are executed at no
> time at all.
> I've used sp_lock but there are no locks.
> Here's an extract from SQLProfiler:
> SQLTransaction Commit 6796 5 2005-03-04 15:30:27.887 2005-03-04
> 15:30:34.683 DTCXact 16335154 sa
> Any Ideas ?
> Regards Tommy S.
>|||Thanks,
I will try to check out the waittypes the next time I see a long running
transaction.
Yes, the log and the datafile are located on the same disk.
The CPU's (4 of them) are almost idle.
The problem is intermittent and it doesn't seem to be dependent on the
number of users, it can occur at early evening when the number of users
decrease significant.
/Tommy
"Olu Adedeji" wrote:
> Check out master..sysprocesses and find out what the waittypes are
> to determine what is causing the extended commit operation.
> is the Tlog file on the same disk as the data file . .how busy is the server?
> is this constantly reproduceable? or is it intermittent?
> HTH
> "Tommy Söderkvist" wrote:
> > Hi all,
> > we have a strange problem in SQL2000 SP3a with SQLTransaction's.
> > When running SQL Profiler the duration for some SQLTransactions (Commit) are
> > over six seconds, but the individual SQL statements (sp's) are executed at no
> > time at all.
> > I've used sp_lock but there are no locks.
> > Here's an extract from SQLProfiler:
> > SQLTransaction Commit 6796 5 2005-03-04 15:30:27.887 2005-03-04
> > 15:30:34.683 DTCXact 16335154 sa
> > Any Ideas ?
> > Regards Tommy S.
> >|||"Tommy Söderkvist" <TommySderkvist@.discussions.microsoft.com> schrieb im
Newsbeitrag news:72BF587D-E3CF-41FE-9EC8-5681C62E472B@.microsoft.com...
> Thanks,
> I will try to check out the waittypes the next time I see a long running
> transaction.
> Yes, the log and the datafile are located on the same disk.
> The CPU's (4 of them) are almost idle.
> The problem is intermittent and it doesn't seem to be dependent on the
> number of users, it can occur at early evening when the number of users
> decrease significant.
My guess would be that you have an IO bottleneck which makes tx log
writing slow. You could use perfmon to verify this theory.
robert
> /Tommy
> "Olu Adedeji" wrote:
> > Check out master..sysprocesses and find out what the waittypes are
> > to determine what is causing the extended commit operation.
> >
> > is the Tlog file on the same disk as the data file . .how busy is the
server?
> > is this constantly reproduceable? or is it intermittent?
> >
> > HTH
> >
> > "Tommy Söderkvist" wrote:
> >
> > > Hi all,
> > > we have a strange problem in SQL2000 SP3a with SQLTransaction's.
> > > When running SQL Profiler the duration for some SQLTransactions
(Commit) are
> > > over six seconds, but the individual SQL statements (sp's) are
executed at no
> > > time at all.
> > > I've used sp_lock but there are no locks.
> > > Here's an extract from SQLProfiler:
> > > SQLTransaction Commit 6796 5 2005-03-04 15:30:27.887 2005-03-04
> > > 15:30:34.683 DTCXact 16335154 sa
> > > Any Ideas ?
> > > Regards Tommy S.
> > >
we have a strange problem in SQL2000 SP3a with SQLTransaction's.
When running SQL Profiler the duration for some SQLTransactions (Commit) are
over six seconds, but the individual SQL statements (sp's) are executed at no
time at all.
I've used sp_lock but there are no locks.
Here's an extract from SQLProfiler:
SQLTransaction Commit 6796 5 2005-03-04 15:30:27.887 2005-03-04
15:30:34.683 DTCXact 16335154 sa
Any Ideas ?
Regards Tommy S.Check out master..sysprocesses and find out what the waittypes are
to determine what is causing the extended commit operation.
is the Tlog file on the same disk as the data file . .how busy is the server?
is this constantly reproduceable? or is it intermittent?
HTH
"Tommy Söderkvist" wrote:
> Hi all,
> we have a strange problem in SQL2000 SP3a with SQLTransaction's.
> When running SQL Profiler the duration for some SQLTransactions (Commit) are
> over six seconds, but the individual SQL statements (sp's) are executed at no
> time at all.
> I've used sp_lock but there are no locks.
> Here's an extract from SQLProfiler:
> SQLTransaction Commit 6796 5 2005-03-04 15:30:27.887 2005-03-04
> 15:30:34.683 DTCXact 16335154 sa
> Any Ideas ?
> Regards Tommy S.
>|||Thanks,
I will try to check out the waittypes the next time I see a long running
transaction.
Yes, the log and the datafile are located on the same disk.
The CPU's (4 of them) are almost idle.
The problem is intermittent and it doesn't seem to be dependent on the
number of users, it can occur at early evening when the number of users
decrease significant.
/Tommy
"Olu Adedeji" wrote:
> Check out master..sysprocesses and find out what the waittypes are
> to determine what is causing the extended commit operation.
> is the Tlog file on the same disk as the data file . .how busy is the server?
> is this constantly reproduceable? or is it intermittent?
> HTH
> "Tommy Söderkvist" wrote:
> > Hi all,
> > we have a strange problem in SQL2000 SP3a with SQLTransaction's.
> > When running SQL Profiler the duration for some SQLTransactions (Commit) are
> > over six seconds, but the individual SQL statements (sp's) are executed at no
> > time at all.
> > I've used sp_lock but there are no locks.
> > Here's an extract from SQLProfiler:
> > SQLTransaction Commit 6796 5 2005-03-04 15:30:27.887 2005-03-04
> > 15:30:34.683 DTCXact 16335154 sa
> > Any Ideas ?
> > Regards Tommy S.
> >|||"Tommy Söderkvist" <TommySderkvist@.discussions.microsoft.com> schrieb im
Newsbeitrag news:72BF587D-E3CF-41FE-9EC8-5681C62E472B@.microsoft.com...
> Thanks,
> I will try to check out the waittypes the next time I see a long running
> transaction.
> Yes, the log and the datafile are located on the same disk.
> The CPU's (4 of them) are almost idle.
> The problem is intermittent and it doesn't seem to be dependent on the
> number of users, it can occur at early evening when the number of users
> decrease significant.
My guess would be that you have an IO bottleneck which makes tx log
writing slow. You could use perfmon to verify this theory.
robert
> /Tommy
> "Olu Adedeji" wrote:
> > Check out master..sysprocesses and find out what the waittypes are
> > to determine what is causing the extended commit operation.
> >
> > is the Tlog file on the same disk as the data file . .how busy is the
server?
> > is this constantly reproduceable? or is it intermittent?
> >
> > HTH
> >
> > "Tommy Söderkvist" wrote:
> >
> > > Hi all,
> > > we have a strange problem in SQL2000 SP3a with SQLTransaction's.
> > > When running SQL Profiler the duration for some SQLTransactions
(Commit) are
> > > over six seconds, but the individual SQL statements (sp's) are
executed at no
> > > time at all.
> > > I've used sp_lock but there are no locks.
> > > Here's an extract from SQLProfiler:
> > > SQLTransaction Commit 6796 5 2005-03-04 15:30:27.887 2005-03-04
> > > 15:30:34.683 DTCXact 16335154 sa
> > > Any Ideas ?
> > > Regards Tommy S.
> > >
Long running SQLTransaction
Hi all,
we have a strange problem in SQL2000 SP3a with SQLTransaction's.
When running SQL Profiler the duration for some SQLTransactions (Commit) are
over six seconds, but the individual SQL statements (sp's) are executed at no
time at all.
I've used sp_lock but there are no locks.
Here's an extract from SQLProfiler:
SQLTransactionCommit679652005-03-04 15:30:27.8872005-03-04
15:30:34.683DTCXact16335154sa
Any Ideas ?
Regards Tommy S.
Check out master..sysprocesses and find out what the waittypes are
to determine what is causing the extended commit operation.
is the Tlog file on the same disk as the data file . .how busy is the server?
is this constantly reproduceable? or is it intermittent?
HTH
"Tommy S?derkvist" wrote:
> Hi all,
> we have a strange problem in SQL2000 SP3a with SQLTransaction's.
> When running SQL Profiler the duration for some SQLTransactions (Commit) are
> over six seconds, but the individual SQL statements (sp's) are executed at no
> time at all.
> I've used sp_lock but there are no locks.
> Here's an extract from SQLProfiler:
> SQLTransactionCommit679652005-03-04 15:30:27.8872005-03-04
> 15:30:34.683DTCXact16335154sa
> Any Ideas ?
> Regards Tommy S.
>
|||Thanks,
I will try to check out the waittypes the next time I see a long running
transaction.
Yes, the log and the datafile are located on the same disk.
The CPU's (4 of them) are almost idle.
The problem is intermittent and it doesn't seem to be dependent on the
number of users, it can occur at early evening when the number of users
decrease significant.
/Tommy
"Olu Adedeji" wrote:
[vbcol=seagreen]
> Check out master..sysprocesses and find out what the waittypes are
> to determine what is causing the extended commit operation.
> is the Tlog file on the same disk as the data file . .how busy is the server?
> is this constantly reproduceable? or is it intermittent?
> HTH
> "Tommy S?derkvist" wrote:
|||"Tommy S?derkvist" <TommySderkvist@.discussions.microsoft.com> schrieb im
Newsbeitrag news:72BF587D-E3CF-41FE-9EC8-5681C62E472B@.microsoft.com...
> Thanks,
> I will try to check out the waittypes the next time I see a long running
> transaction.
> Yes, the log and the datafile are located on the same disk.
> The CPU's (4 of them) are almost idle.
> The problem is intermittent and it doesn't seem to be dependent on the
> number of users, it can occur at early evening when the number of users
> decrease significant.
My guess would be that you have an IO bottleneck which makes tx log
writing slow. You could use perfmon to verify this theory.
robert
[vbcol=seagreen]
> /Tommy
> "Olu Adedeji" wrote:
server?[vbcol=seagreen]
(Commit) are[vbcol=seagreen]
executed at no[vbcol=seagreen]
we have a strange problem in SQL2000 SP3a with SQLTransaction's.
When running SQL Profiler the duration for some SQLTransactions (Commit) are
over six seconds, but the individual SQL statements (sp's) are executed at no
time at all.
I've used sp_lock but there are no locks.
Here's an extract from SQLProfiler:
SQLTransactionCommit679652005-03-04 15:30:27.8872005-03-04
15:30:34.683DTCXact16335154sa
Any Ideas ?
Regards Tommy S.
Check out master..sysprocesses and find out what the waittypes are
to determine what is causing the extended commit operation.
is the Tlog file on the same disk as the data file . .how busy is the server?
is this constantly reproduceable? or is it intermittent?
HTH
"Tommy S?derkvist" wrote:
> Hi all,
> we have a strange problem in SQL2000 SP3a with SQLTransaction's.
> When running SQL Profiler the duration for some SQLTransactions (Commit) are
> over six seconds, but the individual SQL statements (sp's) are executed at no
> time at all.
> I've used sp_lock but there are no locks.
> Here's an extract from SQLProfiler:
> SQLTransactionCommit679652005-03-04 15:30:27.8872005-03-04
> 15:30:34.683DTCXact16335154sa
> Any Ideas ?
> Regards Tommy S.
>
|||Thanks,
I will try to check out the waittypes the next time I see a long running
transaction.
Yes, the log and the datafile are located on the same disk.
The CPU's (4 of them) are almost idle.
The problem is intermittent and it doesn't seem to be dependent on the
number of users, it can occur at early evening when the number of users
decrease significant.
/Tommy
"Olu Adedeji" wrote:
[vbcol=seagreen]
> Check out master..sysprocesses and find out what the waittypes are
> to determine what is causing the extended commit operation.
> is the Tlog file on the same disk as the data file . .how busy is the server?
> is this constantly reproduceable? or is it intermittent?
> HTH
> "Tommy S?derkvist" wrote:
|||"Tommy S?derkvist" <TommySderkvist@.discussions.microsoft.com> schrieb im
Newsbeitrag news:72BF587D-E3CF-41FE-9EC8-5681C62E472B@.microsoft.com...
> Thanks,
> I will try to check out the waittypes the next time I see a long running
> transaction.
> Yes, the log and the datafile are located on the same disk.
> The CPU's (4 of them) are almost idle.
> The problem is intermittent and it doesn't seem to be dependent on the
> number of users, it can occur at early evening when the number of users
> decrease significant.
My guess would be that you have an IO bottleneck which makes tx log
writing slow. You could use perfmon to verify this theory.
robert
[vbcol=seagreen]
> /Tommy
> "Olu Adedeji" wrote:
server?[vbcol=seagreen]
(Commit) are[vbcol=seagreen]
executed at no[vbcol=seagreen]
Wednesday, March 28, 2012
long query
My SQL server blocking for a while
After monitoring with SQL Profiler I found a lot of interesting situation:
query duration is 2045607 msec (=34 min)
CPU usage is 0 msec, number of reads is 3 and number of writes is 0
Where could be a bottleneck ?
Query is tooooooooo long but resorces usage seems to be OK.
Help... SOS ...What about locking?|||Originally posted by snail
What about locking?
It looks with no locks|||Post the query, please.
blindman|||Originally posted by blindman
Post the query, please.
blindman
This is one of many querys with long response
SELECT PPKZIP ,POPZIP ,Zupanija FROM AVEZIP ORDER BY PPKZIP ASC|||Originally posted by valentini
This is one of many querys with long response
SELECT PPKZIP ,POPZIP ,Zupanija FROM AVEZIP ORDER BY PPKZIP ASC
Nr of rows ?
DDL of the table ?
Any index ?|||Originally posted by fadace
Nr of rows ?
DDL of the table ?
Any index ?
Rows about 300
Index on first field - PPKZIP
Table with 3 fields|||Are you seriously saying that it is taking 34 minutes for SQL server to sort 300 rows on an indexed column?
Are there any other processes running? Check the database activity and check the status of any scheduled jobs.
How many users are on the system while this is happening?|||Originally posted by blindman
Are you seriously saying that it is taking 34 minutes for SQL server to sort 300 rows on an indexed column?
Are there any other processes running? Check the database activity and check the status of any scheduled jobs.
How many users are on the system while this is happening?
No scheduling jobs and no special database activity.
As you can see CPU is not used (0 msec)
But after 30 min SQL response with packet of data
Possible from cached memory.
But after 30 min ..............
Is there maybe problem in conlfict with some other transaction
problem with TCP/IP or with physical RAM
...|||What happens if you run the same statement directly from Query Analyzer on the database server?
After monitoring with SQL Profiler I found a lot of interesting situation:
query duration is 2045607 msec (=34 min)
CPU usage is 0 msec, number of reads is 3 and number of writes is 0
Where could be a bottleneck ?
Query is tooooooooo long but resorces usage seems to be OK.
Help... SOS ...What about locking?|||Originally posted by snail
What about locking?
It looks with no locks|||Post the query, please.
blindman|||Originally posted by blindman
Post the query, please.
blindman
This is one of many querys with long response
SELECT PPKZIP ,POPZIP ,Zupanija FROM AVEZIP ORDER BY PPKZIP ASC|||Originally posted by valentini
This is one of many querys with long response
SELECT PPKZIP ,POPZIP ,Zupanija FROM AVEZIP ORDER BY PPKZIP ASC
Nr of rows ?
DDL of the table ?
Any index ?|||Originally posted by fadace
Nr of rows ?
DDL of the table ?
Any index ?
Rows about 300
Index on first field - PPKZIP
Table with 3 fields|||Are you seriously saying that it is taking 34 minutes for SQL server to sort 300 rows on an indexed column?
Are there any other processes running? Check the database activity and check the status of any scheduled jobs.
How many users are on the system while this is happening?|||Originally posted by blindman
Are you seriously saying that it is taking 34 minutes for SQL server to sort 300 rows on an indexed column?
Are there any other processes running? Check the database activity and check the status of any scheduled jobs.
How many users are on the system while this is happening?
No scheduling jobs and no special database activity.
As you can see CPU is not used (0 msec)
But after 30 min SQL response with packet of data
Possible from cached memory.
But after 30 min ..............
Is there maybe problem in conlfict with some other transaction
problem with TCP/IP or with physical RAM
...|||What happens if you run the same statement directly from Query Analyzer on the database server?
Wednesday, March 21, 2012
Logout takes 20 minutes?
I have a problem where our middle tier and all clients connected to it stops
responding for 5 to 20 minutes once or twice a day.
I now did a Profiler trace and saw that there is an Audit Logout entry with
the following data:
EventClass:Audit Logout
CPU:3641
Reads:203866
Writes:0
Duration:1272060
Can anybody tell my why this sometimes take so long, and how to stop it?
Thanx,
ErrolThe logout event duration is the amount of time the user was logged in and
is not directly related to your problem.
Check for rpc completed and batch completed events for exceptionally long
durations. The symptoms you describe may be related to blocking so check
for blocked processing using sp_who2.
Hope this helps.
Dan Guzman
SQL Server MVP
"Errol Terblanche" <Errol Terblanche@.discussions.microsoft.com> wrote in
message news:54DCBF8F-DBFC-41D5-9062-78D64DA01799@.microsoft.com...
>I have a problem where our middle tier and all clients connected to it
>stops
> responding for 5 to 20 minutes once or twice a day.
> I now did a Profiler trace and saw that there is an Audit Logout entry
> with
> the following data:
> EventClass:Audit Logout
> CPU:3641
> Reads:203866
> Writes:0
> Duration:1272060
> Can anybody tell my why this sometimes take so long, and how to stop it?
> Thanx,
> Errol
>|||Also check for any processes that are in rollback state. You might have
uncommitted transactions that are rolling back.
Regards
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in message
news:Ou9V1enwEHA.1192@.tk2msftngp13.phx.gbl...
> The logout event duration is the amount of time the user was logged in and
> is not directly related to your problem.
> Check for rpc completed and batch completed events for exceptionally long
> durations. The symptoms you describe may be related to blocking so check
> for blocked processing using sp_who2.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "Errol Terblanche" <Errol Terblanche@.discussions.microsoft.com> wrote in
> message news:54DCBF8F-DBFC-41D5-9062-78D64DA01799@.microsoft.com...
>|||I have looked for blocks in the Process Info window, but there where none.
I will get a more complete trace to see if i can see anything else.
There are no Batches that took more that 170ms.
I'm starting to think it might be ADO as the middle tier sets up the
connection but it hangs at the connection.connect statement. When this
happens all users that connect gets a connection assigned to them but they
all hang at the connection.connect statement. The connection is set up to
timeout after 15 seconds, but this doesn't happen so i don't think it is
truely a connection problem. After some time all the pending connections
suddenly open, practically all at once.
I have also set up a second middle tier connecting to the same database and
it runs fine and connects promptly even when the first middle tier is
hanging...
Any advice?
Thanx,
Errol
"Mike Epprecht (SQL MVP)" wrote:
> Also check for any processes that are in rollback state. You might have
> uncommitted transactions that are rolling back.
> Regards
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> IM: mike@.epprecht.net
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
> "Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in message
> news:Ou9V1enwEHA.1192@.tk2msftngp13.phx.gbl...
>
>
responding for 5 to 20 minutes once or twice a day.
I now did a Profiler trace and saw that there is an Audit Logout entry with
the following data:
EventClass:Audit Logout
CPU:3641
Reads:203866
Writes:0
Duration:1272060
Can anybody tell my why this sometimes take so long, and how to stop it?
Thanx,
ErrolThe logout event duration is the amount of time the user was logged in and
is not directly related to your problem.
Check for rpc completed and batch completed events for exceptionally long
durations. The symptoms you describe may be related to blocking so check
for blocked processing using sp_who2.
Hope this helps.
Dan Guzman
SQL Server MVP
"Errol Terblanche" <Errol Terblanche@.discussions.microsoft.com> wrote in
message news:54DCBF8F-DBFC-41D5-9062-78D64DA01799@.microsoft.com...
>I have a problem where our middle tier and all clients connected to it
>stops
> responding for 5 to 20 minutes once or twice a day.
> I now did a Profiler trace and saw that there is an Audit Logout entry
> with
> the following data:
> EventClass:Audit Logout
> CPU:3641
> Reads:203866
> Writes:0
> Duration:1272060
> Can anybody tell my why this sometimes take so long, and how to stop it?
> Thanx,
> Errol
>|||Also check for any processes that are in rollback state. You might have
uncommitted transactions that are rolling back.
Regards
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in message
news:Ou9V1enwEHA.1192@.tk2msftngp13.phx.gbl...
> The logout event duration is the amount of time the user was logged in and
> is not directly related to your problem.
> Check for rpc completed and batch completed events for exceptionally long
> durations. The symptoms you describe may be related to blocking so check
> for blocked processing using sp_who2.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "Errol Terblanche" <Errol Terblanche@.discussions.microsoft.com> wrote in
> message news:54DCBF8F-DBFC-41D5-9062-78D64DA01799@.microsoft.com...
>|||I have looked for blocks in the Process Info window, but there where none.
I will get a more complete trace to see if i can see anything else.
There are no Batches that took more that 170ms.
I'm starting to think it might be ADO as the middle tier sets up the
connection but it hangs at the connection.connect statement. When this
happens all users that connect gets a connection assigned to them but they
all hang at the connection.connect statement. The connection is set up to
timeout after 15 seconds, but this doesn't happen so i don't think it is
truely a connection problem. After some time all the pending connections
suddenly open, practically all at once.
I have also set up a second middle tier connecting to the same database and
it runs fine and connects promptly even when the first middle tier is
hanging...
Any advice?
Thanx,
Errol
"Mike Epprecht (SQL MVP)" wrote:
> Also check for any processes that are in rollback state. You might have
> uncommitted transactions that are rolling back.
> Regards
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> IM: mike@.epprecht.net
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
> "Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in message
> news:Ou9V1enwEHA.1192@.tk2msftngp13.phx.gbl...
>
>
Subscribe to:
Posts (Atom)