Viewing 15 posts - 7,441 through 7,455 (of 7,602 total)
primary key = id
recorddate ascending = non unique, non clustered
That's your problem.
You must *cluster* by recorddate. Add a non-clus index on id, if you need it.
Lowell's change is vital...
May 11, 2012 at 8:17 am
How is "devicehistory" clustered?
If it's not clustered, or clustered by something irrelevant like an identity column, you could cluster it by recorddate and vastly speed up your queries.
Also, you should...
May 10, 2012 at 3:41 pm
I expected that, just wanted to be fair about it 🙂 .
The optimizer still needs improvement.
April 19, 2012 at 3:56 pm
Did you adjust the original query so you're doing an apples-to-apples comparison?
SELECT *
FROM #myData md
CROSS JOIN #patterns p
WHERE
md.descr LIKE p.pat
April 19, 2012 at 1:22 pm
Storing this will allow to keep our query sargable for best index usage.
Is that really necessary?
Won't SQL treat computations on a declared variable as a constant, so they are still...
April 17, 2012 at 3:26 pm
You should have something in place that checks for disk hardware errors, with immediate notification and fast response.
And do proper monitoring of the suspect pages table and the SQL error...
April 16, 2012 at 1:07 pm
178M rows shouldn't be a problem per se, if you index properly.
THE biggest factor is getting the correct clustered index.
Get that right, you should have no issues with that many...
April 16, 2012 at 12:54 pm
I use identity as a clus key only as a last resort. Usually there's a better business key value that yields much better overall performance.
On a table I knew...
March 28, 2012 at 1:28 pm
Why use the CHAR function to convert it back to a character?
Why not just check for the ASCII value?
March 28, 2012 at 1:13 pm
I would do a query with:
SELECT
COUNT(*) AS [Total],
COUNT(DISTINCT column_1) AS [Column_1],
COUNT(DISTINCT column_2) AS [Column_2],
...
March 28, 2012 at 1:06 pm
To be safe, I would move everything.
If/as you feel a particular object is not needed, rename it (or move to a different schema/db, if you prefer). See if any...
March 19, 2012 at 3:50 pm
If you can, for now I'd just move the remaining tables temporarily to another filegroup, completely emptying the original fg, then shrink it. Finally move the remaining tables back...
March 16, 2012 at 1:51 pm
Did you deletes of lots of table data in some cases rather than table drops?
At any rate, just to be sure, I would run sys.dm_db_index_physical_stats () on remaining tables to...
March 16, 2012 at 12:48 pm
The setup and maintenance on full-text indexes is not trivial.
It's not a problem for a full-time DBA, but if you're not a DBA, it can be a tricky thing, especially...
March 15, 2012 at 1:37 pm
Viewing 15 posts - 7,441 through 7,455 (of 7,602 total)