Viewing 15 posts - 8,176 through 8,190 (of 49,571 total)
Gazareth (8/11/2014)
I was wondering that myself John, whether or not a clustered index is considered in the 'index' part of sp_spaceused.
I believe the non-leaf levels are, but the leaf levels...
August 11, 2014 at 4:32 am
I have a friend who is of the opinion that it is impossible for his accounts to be hacked. Not unlikely, not difficult. Flat out impossible. He also says he...
August 11, 2014 at 4:31 am
paul.knibbs (8/11/2014)
Jeff Moden (8/9/2014)
With the understanding you have of that counting problem and the additional understanding that I don't ask "trick" questions or questions based on trivia, explain or even...
August 11, 2014 at 4:22 am
You *need* to run frequent stats updates. There's no way around that, you can either run frequent stats updates or have terrible performance. Index defrags, not such a critical issue,...
August 11, 2014 at 4:20 am
LutzM (8/10/2014)
b) block that spammer (mominbd) and all its variations using a filter
This one's not going to work. Last night it was "mominbd", the previous day it was something completely...
August 11, 2014 at 12:38 am
billhol 40227 (8/10/2014)
August 10, 2014 at 12:49 pm
2005. The row counts in sys.partitions are supposed to be transactionally correct. If they are not, it is a bug and should be reported.
August 10, 2014 at 10:40 am
LutzM (8/10/2014)
GilaMonster (8/10/2014)
LutzM (8/10/2014)
Quote from BOL(SS2K14):rows (bigint): Indicates the approximate number of rows in this partition.
The value from sys.partitions is accurate, with the exception of a bug in SQL.
So, BOL...
August 10, 2014 at 10:26 am
LutzM (8/10/2014)
Quote from BOL(SS2K14):rows (bigint): Indicates the approximate number of rows in this partition.
The value from sys.partitions is accurate, with the exception of a bug in SQL.
August 10, 2014 at 10:14 am
alex_pixley (8/8/2014)
If I get rid of partitions 8-13 and then implement sliding window on a yearly basis, I will never have more than seven years worth of data.
And...
August 10, 2014 at 10:11 am
Your move of the join changed the way the optimiser 'wandered' through the search space, resulting in it finding a different 'good enough' plan.
I say not to do it, because...
August 9, 2014 at 2:36 pm
Update the stats, run the query again and post the new actual exec plan please. Currently the incorrect row estimations are messing everything up, it's not going to be possible...
August 9, 2014 at 1:50 pm
faisalfarouqi (8/9/2014)
August 9, 2014 at 10:47 am
faisalfarouqi (8/9/2014)
I would also request that if some suggestions around refactoring or maybe reordering of joins could be made to retrieve data quickly.
Reordering of joins won't do a thing, the...
August 9, 2014 at 7:51 am
The root of the problem here is that the row estimations are wildly off. Estimated rows 1, actual rows 8.3 million. No way the optimiser will manage a good job...
August 9, 2014 at 7:44 am
Viewing 15 posts - 8,176 through 8,190 (of 49,571 total)