Viewing 15 posts - 7,366 through 7,380 (of 22,226 total)
Joy Smith San (10/16/2014)
Grant Fritchey (10/16/2014)
The size of the indexes is much more of a question than the number of them.
Thank you.
So if I have multiple unwanted indexes, obviously...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
October 17, 2014 at 3:08 am
The other option is to simply throw hardware at the problem, but that's very expensive and of limited utility. You're going to have to convince people about the realities of...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
October 17, 2014 at 3:07 am
I'd raise a stink internally. You can't work miracles. There are physical limitations to the universe and a query without a WHERE clause is going to smack right into them...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
October 16, 2014 at 4:02 pm
Random or not, they're ugly to read.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
October 16, 2014 at 8:03 am
If updating the indexes doesn't work, try updating the statistics, possibly with FULL SCAN.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
October 16, 2014 at 6:52 am
Possibly a change in indexes? Statistics are out of date or missing? Check the execution plan. It sure sounds like the optimizer is making some poor choices in executing this...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
October 16, 2014 at 6:40 am
I've got nothing either. You'd think, logically, adding additional AND logic would result in further filtering, not the addition of more data.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
October 16, 2014 at 4:22 am
I don't know of any mechanism of code enforcement at the server that you could do to make this happen. Sorry.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
October 16, 2014 at 4:19 am
It must be a hash of some kind based on the server. I got different values than you did. And, if I dropped the table and recreated it, I got...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
October 16, 2014 at 4:18 am
The size of the indexes is much more of a question than the number of them.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
October 16, 2014 at 4:10 am
TheSQLGuru (10/15/2014)
Grant Fritchey (10/15/2014)
TheSQLGuru (10/15/2014)
GilaMonster (10/15/2014)
TheSQLGuru (10/15/2014)
A proper profiler-to-local-disk script can be run to capture heavy CPU users with very little overhead on the system.
And an extended events session...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
October 15, 2014 at 12:18 pm
What he said.
And, you know where to go if you get stuck.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
October 15, 2014 at 11:20 am
BOR15K (10/15/2014)
I have created Countries_View and placed the problematic CASE within the view and then JOINT Cities A table with Countries_View B
and all works like...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
October 15, 2014 at 11:07 am
TheSQLGuru (10/15/2014)
GilaMonster (10/15/2014)
TheSQLGuru (10/15/2014)
A proper profiler-to-local-disk script can be run to capture heavy CPU users with very little overhead on the system.
And an extended events session will have even...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
October 15, 2014 at 11:03 am
Use extended events because they're much lower cost than trace (much, much, much lower). Capture rpc_complete and sql_batch_complete. That can show you which queries are running to completion and what...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
October 15, 2014 at 8:02 am
Viewing 15 posts - 7,366 through 7,380 (of 22,226 total)