Showing posts with label production. Show all posts
Showing posts with label production. Show all posts

Wednesday, March 28, 2012

Query work on developement sql server 2005 but not on the production server

This is the most rediculous situation.

I have a sql server 2005 running on my computer.

When I go to the clients site they have set up a Sql server 2005 over there.

The query works on my computer but not on the clients machine.

I had them install the latest Service packs and hotfixes but no luck.

You don't have to read the entire query at the button here is what makes it stop working.

Or at least slow down enough to time out.

Its there where clause.

Without it it work great, with it it fails.

What funny is that when I have it set to just one check it works

WHERE Tbl_MainAgents.AgentCommissionCode ='3'

when I check for multiple values it fails

WHERE Tbl_MainAgents.AgentCommissionCode ='3'

or Tbl_MainAgents.AgentCommissionCode ='4'

or Tbl_MainAgents.AgentCommissionCode ='5'

I have trying doing the check using HAVING and I've tried it in the join, I've tried several different was of check for a 3, 4, or 5 but no luck

I even took a backup of the database on the clients machine, restored i on my machine and then it works.

I'm trying to avoid asking the clients to reinstall thier sql server. I already blamed there server by making them install the hotfixes.

here is the query :

SELECTMin([Qry_DetailCommType3&4&5_A].transaction_id)AS FirstOftransaction_id,

[Qry_DetailCommType3&4&5_A].store_no,

[Qry_DetailCommType3&4&5_A].store_name,

[Qry_DetailCommType3&4&5_A].transaction_date,

[Qry_DetailCommType3&4&5_A].PayableSubAgent,

Tbl_SubAgents.SubAgentDesc,

[Qry_DetailCommType3&4&5_A].PayableAgent,

Tbl_MainAgents.AgentName,

Tbl_MainAgents.TypeAS AgentType,

Tbl_MainAgents.AgentCommissionCode,

Tbl_AgentCommCode.AgentCommDesc,

Sum([Qry_DetailCommType3&4&5_A].NoOfCoupon)AS NoOfCoupon,

Sum([Qry_DetailCommType3&4&5_A].Food)AS Food,

Sum([Qry_DetailCommType3&4&5_A].NonHiloHattie)AS NonHiloHattie,

Sum([Qry_DetailCommType3&4&5_A].PrivateLabel)AS PrivateLabel,

Sum([Qry_DetailCommType3&4&5_A].Media)AS Media,

Sum([Qry_DetailCommType3&4&5_A].Others)AS Others,

Sum([Qry_DetailCommType3&4&5_A].SaleItems)AS SaleItems,

Sum([Qry_DetailCommType3&4&5_A].NonCommissionable)AS NonCommissionable,

Sum([Qry_DetailCommType3&4&5_A].InvalidClass)AS InvalidClass,

Tbl_SubAgents.C_PrivateLabel,

Tbl_SubAgents.C_Others,

Tbl_SubAgents.C_NonHiloHattie,

Tbl_SubAgents.C_Media,

Tbl_SubAgents.C_Food,

Tbl_SubAgents.C_SaleItems,

Sum([Qry_DetailCommType3&4&5_A].GwpMugs)AS GwpMugs,

Sum([Qry_DetailCommType3&4&5_A].GwpTshirt)AS GwpTshirt,

Sum([Qry_DetailCommType3&4&5_A].GwpCandies)AS GwpCandies,

Sum([Qry_DetailCommType3&4&5_A].GwpOthers)AS GwpOthers,

Sum([Qry_DetailCommType3&4&5_A].GwpSpecialty)AS GwpSpecialty,

Sum([Qry_DetailCommType3&4&5_A].GwpTowels)AS GwpTowels,

Tbl_SubAgents.MugsDeduction,

Tbl_SubAgents.CandiesDeduction,

Tbl_SubAgents.TShirtsDeduction,

Tbl_SubAgents.OthersDeduction,

Tbl_SubAgents.TowelsDeduction,

Tbl_SubAgents.SpecialtyDeductions,

Sum([Qry_DetailCommType3&4&5_A].CountOfgc)AS CountOfgc,

Sum([Qry_DetailCommType3&4&5_A].gross_line_amount)AS gc_amount,

Sum([Qry_DetailCommType3&4&5_A].[GCDeduc$])AS [GCDeduc$],

'Coupons'AS CommType,

[Qry_DetailCommType3&4&5_A].period,

[Qry_DetailCommType3&4&5_A].Month_Year

FROM(Tbl_MainAgents InnerJOIN Tbl_AgentCommCode ON Tbl_AgentCommCode.AgentCommCode = Tbl_MainAgents.AgentCommissionCode )

InnerJOIN([Qry_DetailCommType3&4&5_A] INNERJOIN Tbl_SubAgents ON [Qry_DetailCommType3&4&5_A].PayableSubAgent = Tbl_SubAgents.SubAgent)ON Tbl_MainAgents.MainAgent = Tbl_SubAgents.MainAgent

WHERE Tbl_MainAgents.AgentCommissionCode ='3'or Tbl_MainAgents.AgentCommissionCode ='4'or Tbl_MainAgents.AgentCommissionCode ='5'

GROUPBY [Qry_DetailCommType3&4&5_A].store_no,

[Qry_DetailCommType3&4&5_A].store_name,

[Qry_DetailCommType3&4&5_A].transaction_date,

[Qry_DetailCommType3&4&5_A].PayableSubAgent,

Tbl_SubAgents.SubAgentDesc,

[Qry_DetailCommType3&4&5_A].PayableAgent,

Tbl_MainAgents.AgentName,

Tbl_MainAgents.Type,

Tbl_MainAgents.AgentCommissionCode,

Tbl_AgentCommCode.AgentCommDesc,

Tbl_SubAgents.C_PrivateLabel,

Tbl_SubAgents.C_Others,

Tbl_SubAgents.C_NonHiloHattie,

Tbl_SubAgents.C_Media,

Tbl_SubAgents.C_Food,

Tbl_SubAgents.C_SaleItems,

Tbl_SubAgents.MugsDeduction,

Tbl_SubAgents.CandiesDeduction,

Tbl_SubAgents.TShirtsDeduction,

Tbl_SubAgents.OthersDeduction,

Tbl_SubAgents.TowelsDeduction,

Tbl_SubAgents.SpecialtyDeductions,

[Qry_DetailCommType3&4&5_A].period, [Qry_DetailCommType3&4&5_A].Month_Year

What's the error? Can you post it?

Adamus

|||

I'm not at the client site now but I think eventualy a timeout message came.

Sometime I get a timeout, sometimes it just keeps going. I let the timer go for more than 16 minuets.

|||when I don't have the "where " in the query it only takes 9 seconds|||

How many records are we talking about?

Is this a production server?

Is the table being locked somehow?

Is the field indexed?

If you add one check to the where clause does it take 9 seconds, then 2 checks = 18 secs?...

Just a few raw thoughts.

Adamus

|||

Is there an index on Tbl_MainAgents.AgentCommissionCode ?

What does the query plan show?

Are their statistics current?

Have you run it through profiler?

|||

It returns 20,000 records.
The server than can not handle this sql is in production.
On my my personal computer (which is not 1/2 as good as the production server) it works fine. Even with the where clause.


I don't know if the table is being locked. I assume not because other querries work.
And when I don't check for agentcommcode more than once it works.


Agentcommcode is a varchar(2). It is a primary key. I don't know why they made it a varchar(2) instead of an int. but I don't want to change it, might break some code somewhere.


with One check

where agencCommCode = '3' it takes 9 seconds

with 2 checks

where agencCommCode = '3' or agencCommCode = '4' take forever


I am very new to sql server 2005, I havn't tried statistics, or lookin at the query plan.

But I took a back up of the database from the production server.
Restored in on my own little PC. Won't all the indexes and query plan come over with that.
When I run the exact database that I backed up from production to my pc it works great.

|||

I'd be interested in see the query plans generated for the differing WHERE clauses.

They haven't tried to do any manual "tuning" on the server have they? Like using fibers or restricting CPU selection, etc?

What else runs on this same machine?

Is there another DB used by another app that is intensive?

|||

I can't answer some of these questions becuase I am not on the clients machine.

I am on my own computer, where everything works fine.

I guess I'll just tell them to reinstall thier sql server.

After that I'll go over there and if the problem still exists, I'll try looking at statistic, and query plan and all that.

If that doesn't work I might tell them to use sql server 2000. I've never had any problem with that. And I do miss enterprise manager.

|||

Just out of mere curiousity, if you change the = '1' to LIKE '%1%' Does it effect the query time even with 3 checks?

(I know it'll return undesired results but I'm curious about the datatype)

Adamus

|||

Again I am currently on my own computer, where everything works fine

changing to like didn't make any difference,

I'll try it on the clients machine and let you know. That is if we still have the problem after reinstalling sql serve 2005,

|||

ksy

Do they have an anti-virus running on that production box?

If so, have they excluded file extensions .mdf, .ndf, and .ldf from the AV processing?

If AV is on the box and they haven't excluded the SS files, that can be an issue.

|||

No there was not anitvirus on that machine.

I delete the table Tbl_AgentCommCode and its relationshipt with the table Tbl_mainAgent and then recreate this table.

This fixed it. I have no idea why. Whats funny is that before I recreate this table I tried my query without this table and it still didn't work.

Anyway now it works. Thanks everybody who tried to help.

|||

Ok, but you don't want to do that every time a query is slow, do you?

It was likely one of a few things.

* Index Stats

* Index fragmentation

* Poor stored query plan (though if you altered it for the test that was probably not it.)

Updating stats would have probably done it, or rebuilding indexes. You really need to look at the plan of a query using Management Studio or Query Analyzer to see what isn't happening on one server and not the other. It will save you time in the future to try these things first.

sql

Query work on developement sql server 2005 but not on the production server

This is the most rediculous situation.

I have a sql server 2005 running on my computer.

When I go to the clients site they have set up a Sql server 2005 over there.

The query works on my computer but not on the clients machine.

I had them install the latest Service packs and hotfixes but no luck.

You don't have to read the entire query at the button here is what makes it stop working.

Or at least slow down enough to time out.

Its there where clause.

Without it it work great, with it it fails.

What funny is that when I have it set to just one check it works

WHERE Tbl_MainAgents.AgentCommissionCode = '3'

when I check for multiple values it fails

WHERE Tbl_MainAgents.AgentCommissionCode = '3'

or Tbl_MainAgents.AgentCommissionCode = '4'

or Tbl_MainAgents.AgentCommissionCode = '5'

I have trying doing the check using HAVING and I've tried it in the join, I've tried several different was of check for a 3, 4, or 5 but no luck

I even took a backup of the database on the clients machine, restored i on my machine and then it works.

I'm trying to avoid asking the clients to reinstall thier sql server. I already blamed there server by making them install the hotfixes.

here is the query :

SELECT Min([Qry_DetailCommType3&4&5_A].transaction_id) AS FirstOftransaction_id,

[Qry_DetailCommType3&4&5_A].store_no,

[Qry_DetailCommType3&4&5_A].store_name,

[Qry_DetailCommType3&4&5_A].transaction_date,

[Qry_DetailCommType3&4&5_A].PayableSubAgent,

Tbl_SubAgents.SubAgentDesc,

[Qry_DetailCommType3&4&5_A].PayableAgent,

Tbl_MainAgents.AgentName,

Tbl_MainAgents.Type AS AgentType,

Tbl_MainAgents.AgentCommissionCode,

Tbl_AgentCommCode.AgentCommDesc,

Sum([Qry_DetailCommType3&4&5_A].NoOfCoupon) AS NoOfCoupon,

Sum([Qry_DetailCommType3&4&5_A].Food) AS Food,

Sum([Qry_DetailCommType3&4&5_A].NonHiloHattie) AS NonHiloHattie,

Sum([Qry_DetailCommType3&4&5_A].PrivateLabel) AS PrivateLabel,

Sum([Qry_DetailCommType3&4&5_A].Media) AS Media,

Sum([Qry_DetailCommType3&4&5_A].Others) AS Others,

Sum([Qry_DetailCommType3&4&5_A].SaleItems) AS SaleItems,

Sum([Qry_DetailCommType3&4&5_A].NonCommissionable) AS NonCommissionable,

Sum([Qry_DetailCommType3&4&5_A].InvalidClass) AS InvalidClass,

Tbl_SubAgents.C_PrivateLabel,

Tbl_SubAgents.C_Others,

Tbl_SubAgents.C_NonHiloHattie,

Tbl_SubAgents.C_Media,

Tbl_SubAgents.C_Food,

Tbl_SubAgents.C_SaleItems,

Sum([Qry_DetailCommType3&4&5_A].GwpMugs) AS GwpMugs,

Sum([Qry_DetailCommType3&4&5_A].GwpTshirt) AS GwpTshirt,

Sum([Qry_DetailCommType3&4&5_A].GwpCandies) AS GwpCandies,

Sum([Qry_DetailCommType3&4&5_A].GwpOthers) AS GwpOthers,

Sum([Qry_DetailCommType3&4&5_A].GwpSpecialty) AS GwpSpecialty,

Sum([Qry_DetailCommType3&4&5_A].GwpTowels) AS GwpTowels,

Tbl_SubAgents.MugsDeduction,

Tbl_SubAgents.CandiesDeduction,

Tbl_SubAgents.TShirtsDeduction,

Tbl_SubAgents.OthersDeduction,

Tbl_SubAgents.TowelsDeduction,

Tbl_SubAgents.SpecialtyDeductions,

Sum([Qry_DetailCommType3&4&5_A].CountOfgc) AS CountOfgc,

Sum([Qry_DetailCommType3&4&5_A].gross_line_amount) AS gc_amount,

Sum([Qry_DetailCommType3&4&5_A].[GCDeduc$]) AS [GCDeduc$],

'Coupons' AS CommType,

[Qry_DetailCommType3&4&5_A].period,

[Qry_DetailCommType3&4&5_A].Month_Year

FROM (Tbl_MainAgents Inner JOIN Tbl_AgentCommCode ON Tbl_AgentCommCode.AgentCommCode = Tbl_MainAgents.AgentCommissionCode )

Inner JOIN ([Qry_DetailCommType3&4&5_A] INNER JOIN Tbl_SubAgents ON [Qry_DetailCommType3&4&5_A].PayableSubAgent = Tbl_SubAgents.SubAgent) ON Tbl_MainAgents.MainAgent = Tbl_SubAgents.MainAgent

WHERE Tbl_MainAgents.AgentCommissionCode = '3' or Tbl_MainAgents.AgentCommissionCode = '4' or Tbl_MainAgents.AgentCommissionCode = '5'

GROUP BY [Qry_DetailCommType3&4&5_A].store_no,

[Qry_DetailCommType3&4&5_A].store_name,

[Qry_DetailCommType3&4&5_A].transaction_date,

[Qry_DetailCommType3&4&5_A].PayableSubAgent,

Tbl_SubAgents.SubAgentDesc,

[Qry_DetailCommType3&4&5_A].PayableAgent,

Tbl_MainAgents.AgentName,

Tbl_MainAgents.Type,

Tbl_MainAgents.AgentCommissionCode,

Tbl_AgentCommCode.AgentCommDesc,

Tbl_SubAgents.C_PrivateLabel,

Tbl_SubAgents.C_Others,

Tbl_SubAgents.C_NonHiloHattie,

Tbl_SubAgents.C_Media,

Tbl_SubAgents.C_Food,

Tbl_SubAgents.C_SaleItems,

Tbl_SubAgents.MugsDeduction,

Tbl_SubAgents.CandiesDeduction,

Tbl_SubAgents.TShirtsDeduction,

Tbl_SubAgents.OthersDeduction,

Tbl_SubAgents.TowelsDeduction,

Tbl_SubAgents.SpecialtyDeductions,

[Qry_DetailCommType3&4&5_A].period, [Qry_DetailCommType3&4&5_A].Month_Year

What's the error? Can you post it?

Adamus

|||

I'm not at the client site now but I think eventualy a timeout message came.

Sometime I get a timeout, sometimes it just keeps going. I let the timer go for more than 16 minuets.

|||when I don't have the "where " in the query it only takes 9 seconds|||

How many records are we talking about?

Is this a production server?

Is the table being locked somehow?

Is the field indexed?

If you add one check to the where clause does it take 9 seconds, then 2 checks = 18 secs?...

Just a few raw thoughts.

Adamus

|||

Is there an index on Tbl_MainAgents.AgentCommissionCode ?

What does the query plan show?

Are their statistics current?

Have you run it through profiler?

|||

It returns 20,000 records.
The server than can not handle this sql is in production.
On my my personal computer (which is not 1/2 as good as the production server) it works fine. Even with the where clause.


I don't know if the table is being locked. I assume not because other querries work.
And when I don't check for agentcommcode more than once it works.


Agentcommcode is a varchar(2). It is a primary key. I don't know why they made it a varchar(2) instead of an int. but I don't want to change it, might break some code somewhere.


with One check

where agencCommCode = '3' it takes 9 seconds

with 2 checks

where agencCommCode = '3' or agencCommCode = '4' take forever


I am very new to sql server 2005, I havn't tried statistics, or lookin at the query plan.

But I took a back up of the database from the production server.
Restored in on my own little PC. Won't all the indexes and query plan come over with that.
When I run the exact database that I backed up from production to my pc it works great.

|||

I'd be interested in see the query plans generated for the differing WHERE clauses.

They haven't tried to do any manual "tuning" on the server have they? Like using fibers or restricting CPU selection, etc?

What else runs on this same machine?

Is there another DB used by another app that is intensive?

|||

I can't answer some of these questions becuase I am not on the clients machine.

I am on my own computer, where everything works fine.

I guess I'll just tell them to reinstall thier sql server.

After that I'll go over there and if the problem still exists, I'll try looking at statistic, and query plan and all that.

If that doesn't work I might tell them to use sql server 2000. I've never had any problem with that. And I do miss enterprise manager.

|||

Just out of mere curiousity, if you change the = '1' to LIKE '%1%' Does it effect the query time even with 3 checks?

(I know it'll return undesired results but I'm curious about the datatype)

Adamus

|||

Again I am currently on my own computer, where everything works fine

changing to like didn't make any difference,

I'll try it on the clients machine and let you know. That is if we still have the problem after reinstalling sql serve 2005,

|||

ksy

Do they have an anti-virus running on that production box?

If so, have they excluded file extensions .mdf, .ndf, and .ldf from the AV processing?

If AV is on the box and they haven't excluded the SS files, that can be an issue.

|||

No there was not anitvirus on that machine.

I delete the table Tbl_AgentCommCode and its relationshipt with the table Tbl_mainAgent and then recreate this table.

This fixed it. I have no idea why. Whats funny is that before I recreate this table I tried my query without this table and it still didn't work.

Anyway now it works. Thanks everybody who tried to help.

|||

Ok, but you don't want to do that every time a query is slow, do you?

It was likely one of a few things.

* Index Stats

* Index fragmentation

* Poor stored query plan (though if you altered it for the test that was probably not it.)

Updating stats would have probably done it, or rebuilding indexes. You really need to look at the plan of a query using Management Studio or Query Analyzer to see what isn't happening on one server and not the other. It will save you time in the future to try these things first.

Friday, March 9, 2012

Query to compare table data between Test and Production?

I am debugging one of our programs and ran the fix in Test. I would like
to compare table 1 between Production and Test. I want the query to output
column 1 if Production <> Test output.

What is the best way to achieve this?

jeff

--
Message posted via http://www.sqlmonster.comHow many columns did your fix affect? If it's just one, and it's not
your primary key (or unique identifier), then you could simply do
something like:

SELECT col1
FROM Production.dbo.Table 1 t1 JOIN Test.dbo.Table t2 ON
t1.col1=t2.col1
WHERE t1.AffectedColumn <> t2.AffectedColumn

If that ain't it, can you post more so we can narrow it down a bit?

Stu|||Stu,

No thanks that will do it...I just had a lapse in memory on how to achieve
this.

Jeff

--
Message posted via http://www.sqlmonster.com

Wednesday, March 7, 2012

Query Timeout

I have a rather complicated query statement in a stored proc which all of a
sudden hangs in production. I copy the same database to QA and run the store
d
proc and it executes in less than a second. The explain plans are different
between production and QA. I have recompiled (sp_recompile) the stored proc
in production. Still hangs. I have run sp_updatestats in production (but tha
t
still doesn't explain why QA works fine) and it still hangs. Any ideas?
Message posted via droptable.com
http://www.droptable.com/Uwe/Forum...server/200608/1Double-check the indexes on the production and QA boxes first to make sure
they are the same. Also try rebuilding indexes (DBCC DBREINDEX) in
production if the indexes are the same.
"cbrichards via droptable.com" <u3288@.uwe> wrote in message
news:64ebbf94f87e0@.uwe...
>I have a rather complicated query statement in a stored proc which all of a
> sudden hangs in production. I copy the same database to QA and run the
> stored
> proc and it executes in less than a second. The explain plans are
> different
> between production and QA. I have recompiled (sp_recompile) the stored
> proc
> in production. Still hangs. I have run sp_updatestats in production (but
> that
> still doesn't explain why QA works fine) and it still hangs. Any ideas?
> --
> Message posted via droptable.com
> http://www.droptable.com/Uwe/Forum...server/200608/1
>|||cbrichards via droptable.com wrote:
> I have a rather complicated query statement in a stored proc which all of
a
> sudden hangs in production. I copy the same database to QA and run the sto
red
> proc and it executes in less than a second. The explain plans are differen
t
> between production and QA. I have recompiled (sp_recompile) the stored pro
c
> in production. Still hangs. I have run sp_updatestats in production (but t
hat
> still doesn't explain why QA works fine) and it still hangs. Any ideas?
>
When the query "hangs", check sysprocesses to see what's blocking it...
My guess is your production server has more activity on it than the QA
server, and something is blocking your query.
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||The indexes are the same as I copied the database to QA. I have another post
on this website that Tracy has been responding to about the DBREindex not
having any affect on my fragmented index. But there has not been a response
on that issue since posting my SHOWCONTIG results.
Mike C# wrote:[vbcol=seagreen]
>Double-check the indexes on the production and QA boxes first to make sure
>they are the same. Also try rebuilding indexes (DBCC DBREINDEX) in
>production if the indexes are the same.
>
>[quoted text clipped - 6 lines]
Message posted via http://www.droptable.com|||Evaluating master.dbo.sysprocesses and running sp_who2 while the proc is
running has not revealed any blocking. Initially I suspected that too. I am
still stumped over the lack of affect of DBReindex on my indexes another pos
t
you responded too.
Tracy McKibben wrote:
>When the query "hangs", check sysprocesses to see what's blocking it...
> My guess is your production server has more activity on it than the QA
>server, and something is blocking your query.
>
Message posted via droptable.com
http://www.droptable.com/Uwe/Forum...server/200608/1|||cbrichards via droptable.com wrote:
> The indexes are the same as I copied the database to QA. I have another po
st
> on this website that Tracy has been responding to about the DBREindex not
> having any affect on my fragmented index. But there has not been a respons
e
> on that issue since posting my SHOWCONTIG results.
>
Actually there was a response from another poster, stating that the
index in question is too small to defragment. I didn't respond because
his answer is correct.
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||cbrichards via droptable.com wrote:
> Evaluating master.dbo.sysprocesses and running sp_who2 while the proc is
> running has not revealed any blocking. Initially I suspected that too. I a
m
> still stumped over the lack of affect of DBReindex on my indexes another p
ost
> you responded too.
>
There must be some clue in sysprocesses. Is there a waittype shown for
the query? Does the execution plan reveal any clues?
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||When I run "select * from master.dbo.sysprocesses" while the proc is about 3
0
seconds into running (It should complete in less than a half second), I get
the following from sysprocesses:
blocked = 0
lastwaittype = PAGELATCH_SH
CPU = 261204
When I run it in production (and times out) the explain plain provided in
profiler shows a Hash join and two Bookmark lookups that the "exact" copy on
QA does not show in its explain plan.
Tracy McKibben wrote:
>There must be some clue in sysprocesses. Is there a waittype shown for
>the query? Does the execution plan reveal any clues?
>
Message posted via droptable.com
http://www.droptable.com/Uwe/Forum...server/200608/1|||At about 20 minutes into the proc execution I ran sysprocesses again:
Blocked = 0 (in fact all the rows for the blocked column from sysprocesses
are zero)
LastWaitType = LCK_M_S
Tracy McKibben wrote:
>There must be some clue in sysprocesses. Is there a waittype shown for
>the query? Does the execution plan reveal any clues?
>
Message posted via droptable.com
http://www.droptable.com/Uwe/Forum...server/200608/1|||cbrichards via droptable.com wrote:
> When I run "select * from master.dbo.sysprocesses" while the proc is about
30
> seconds into running (It should complete in less than a half second), I ge
t
> the following from sysprocesses:
> blocked = 0
> lastwaittype = PAGELATCH_SH
> CPU = 261204
> When I run it in production (and times out) the explain plain provided in
> profiler shows a Hash join and two Bookmark lookups that the "exact" copy
on
> QA does not show in its explain plan.
>
For the two bookmark lookups, what index is being used? Are they the
same indexes that the query uses in QA? If not, you need to determine
why it's choosing different indexes. Is the amount of data the same
between QA and prod? Try forcing the index using an index hint, see if
that improves the performance.
Tracy McKibben
MCDBA
http://www.realsqlguy.com

Query Timeout

I have a rather complicated query statement in a stored proc which all of a
sudden hangs in production. I copy the same database to QA and run the stored
proc and it executes in less than a second. The explain plans are different
between production and QA. I have recompiled (sp_recompile) the stored proc
in production. Still hangs. I have run sp_updatestats in production (but that
still doesn't explain why QA works fine) and it still hangs. Any ideas?
--
Message posted via SQLMonster.com
http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200608/1Double-check the indexes on the production and QA boxes first to make sure
they are the same. Also try rebuilding indexes (DBCC DBREINDEX) in
production if the indexes are the same.
"cbrichards via SQLMonster.com" <u3288@.uwe> wrote in message
news:64ebbf94f87e0@.uwe...
>I have a rather complicated query statement in a stored proc which all of a
> sudden hangs in production. I copy the same database to QA and run the
> stored
> proc and it executes in less than a second. The explain plans are
> different
> between production and QA. I have recompiled (sp_recompile) the stored
> proc
> in production. Still hangs. I have run sp_updatestats in production (but
> that
> still doesn't explain why QA works fine) and it still hangs. Any ideas?
> --
> Message posted via SQLMonster.com
> http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200608/1
>|||cbrichards via SQLMonster.com wrote:
> I have a rather complicated query statement in a stored proc which all of a
> sudden hangs in production. I copy the same database to QA and run the stored
> proc and it executes in less than a second. The explain plans are different
> between production and QA. I have recompiled (sp_recompile) the stored proc
> in production. Still hangs. I have run sp_updatestats in production (but that
> still doesn't explain why QA works fine) and it still hangs. Any ideas?
>
When the query "hangs", check sysprocesses to see what's blocking it...
My guess is your production server has more activity on it than the QA
server, and something is blocking your query.
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||The indexes are the same as I copied the database to QA. I have another post
on this website that Tracy has been responding to about the DBREindex not
having any affect on my fragmented index. But there has not been a response
on that issue since posting my SHOWCONTIG results.
Mike C# wrote:
>Double-check the indexes on the production and QA boxes first to make sure
>they are the same. Also try rebuilding indexes (DBCC DBREINDEX) in
>production if the indexes are the same.
>>I have a rather complicated query statement in a stored proc which all of a
>> sudden hangs in production. I copy the same database to QA and run the
>[quoted text clipped - 6 lines]
>> that
>> still doesn't explain why QA works fine) and it still hangs. Any ideas?
--
Message posted via http://www.sqlmonster.com|||Evaluating master.dbo.sysprocesses and running sp_who2 while the proc is
running has not revealed any blocking. Initially I suspected that too. I am
still stumped over the lack of affect of DBReindex on my indexes another post
you responded too.
Tracy McKibben wrote:
>> I have a rather complicated query statement in a stored proc which all of a
>> sudden hangs in production. I copy the same database to QA and run the stored
>> proc and it executes in less than a second. The explain plans are different
>> between production and QA. I have recompiled (sp_recompile) the stored proc
>> in production. Still hangs. I have run sp_updatestats in production (but that
>> still doesn't explain why QA works fine) and it still hangs. Any ideas?
>When the query "hangs", check sysprocesses to see what's blocking it...
> My guess is your production server has more activity on it than the QA
>server, and something is blocking your query.
>
--
Message posted via SQLMonster.com
http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200608/1|||cbrichards via SQLMonster.com wrote:
> The indexes are the same as I copied the database to QA. I have another post
> on this website that Tracy has been responding to about the DBREindex not
> having any affect on my fragmented index. But there has not been a response
> on that issue since posting my SHOWCONTIG results.
>
Actually there was a response from another poster, stating that the
index in question is too small to defragment. I didn't respond because
his answer is correct.
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||cbrichards via SQLMonster.com wrote:
> Evaluating master.dbo.sysprocesses and running sp_who2 while the proc is
> running has not revealed any blocking. Initially I suspected that too. I am
> still stumped over the lack of affect of DBReindex on my indexes another post
> you responded too.
>
There must be some clue in sysprocesses. Is there a waittype shown for
the query? Does the execution plan reveal any clues?
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||When I run "select * from master.dbo.sysprocesses" while the proc is about 30
seconds into running (It should complete in less than a half second), I get
the following from sysprocesses:
blocked = 0
lastwaittype = PAGELATCH_SH
CPU = 261204
When I run it in production (and times out) the explain plain provided in
profiler shows a Hash join and two Bookmark lookups that the "exact" copy on
QA does not show in its explain plan.
Tracy McKibben wrote:
>> Evaluating master.dbo.sysprocesses and running sp_who2 while the proc is
>> running has not revealed any blocking. Initially I suspected that too. I am
>> still stumped over the lack of affect of DBReindex on my indexes another post
>> you responded too.
>There must be some clue in sysprocesses. Is there a waittype shown for
>the query? Does the execution plan reveal any clues?
>
--
Message posted via SQLMonster.com
http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200608/1|||At about 20 minutes into the proc execution I ran sysprocesses again:
Blocked = 0 (in fact all the rows for the blocked column from sysprocesses
are zero)
LastWaitType = LCK_M_S
Tracy McKibben wrote:
>> Evaluating master.dbo.sysprocesses and running sp_who2 while the proc is
>> running has not revealed any blocking. Initially I suspected that too. I am
>> still stumped over the lack of affect of DBReindex on my indexes another post
>> you responded too.
>There must be some clue in sysprocesses. Is there a waittype shown for
>the query? Does the execution plan reveal any clues?
>
--
Message posted via SQLMonster.com
http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200608/1|||cbrichards via SQLMonster.com wrote:
> When I run "select * from master.dbo.sysprocesses" while the proc is about 30
> seconds into running (It should complete in less than a half second), I get
> the following from sysprocesses:
> blocked = 0
> lastwaittype = PAGELATCH_SH
> CPU = 261204
> When I run it in production (and times out) the explain plain provided in
> profiler shows a Hash join and two Bookmark lookups that the "exact" copy on
> QA does not show in its explain plan.
>
For the two bookmark lookups, what index is being used? Are they the
same indexes that the query uses in QA? If not, you need to determine
why it's choosing different indexes. Is the amount of data the same
between QA and prod? Try forcing the index using an index hint, see if
that improves the performance.
Tracy McKibben
MCDBA
http://www.realsqlguy.com