Viewing 15 posts - 16 through 30 (of 44 total)
Mystery Jimbo,
I am also seeing issues that may or may not be related to this type of issue, we are still flushing out other potential issues, but can you...
July 25, 2011 at 10:38 am
Wow...I might just have to use this as Evidence Item #1 when convincing Dev to change the code....
Thanks everyone for your contributions, when we have a fix, I will definitely...
July 6, 2011 at 11:00 am
Yeah, I agree,
The unionall plan is attached...it looks MUCH better....2 seeks.
July 5, 2011 at 11:48 am
Current query with SET STATISTICS IO ON:
Table 'BH_UserWorkHistory'. Scan count 14, logical reads 5733, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead...
July 5, 2011 at 11:43 am
Thanks guys, I agree the biggest mystery to me is why it is worse on more (granted slower) CPUs. This code has not changed and I cannot unfortunate see the...
July 5, 2011 at 11:40 am
Ninja's_RGR'us (7/5/2011)
Hmm, where's the plan with the union all version?
...Sorry if I wasn't clear, if we can change the code, we would not even need to do it as a...
July 5, 2011 at 10:50 am
Ninja,
Thanks and I love it. The new plan is attached.
July 5, 2011 at 10:26 am
Ok, I changed that and it used the new index, but it is still a scan....
I need to go fight with development on changing the code for a little bit....
July 5, 2011 at 10:06 am
Ninja,
On the second table, I have a covering index, but I can't seem to get it to not do an index scan, the definition is below, am I missing...
July 5, 2011 at 9:40 am
Ninja,
The business use of the query is to keep two systems in sync. So the query runs (all the time) to check for the existence of rows.
The...
July 5, 2011 at 9:25 am
Thanks guys, sorry for the need to obfuscate. This one just has the schema and DBname changed.
the index definitions are also included.
July 5, 2011 at 8:56 am
Thanks Ninja.
attached as a txt. (small changes made to DB, schema and tables names for anonymity.) If that doesn't work, I can send directly.
July 5, 2011 at 8:31 am
So, forgive my ignorance, but that query returns 750 rows. The overwhelming vast majority(>90%) are the same query that also shows as being the highest CPU offender. It is shown...
July 5, 2011 at 8:23 am
Ok, so I have been monitoring this for about 90 min and am still seeing the same issues. Performance has not moved, still about 200% higher than on the previous...
July 5, 2011 at 8:00 am
Thanks Ninja,
I'll try to keep and eye on the tables that have been causing the most problems.
July 5, 2011 at 6:42 am
Viewing 15 posts - 16 through 30 (of 44 total)