Viewing 15 posts - 2,206 through 2,220 (of 22,227 total)
Yeah it's not the compression. That's fine. (although I know where you can get even better than native compression <cough> Redgate </cough>), it's the TDE with compression that can lead...
"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
January 3, 2020 at 11:12 pm
Don't forget, even with a log file, if the backup process ignored SQL Server transactions, the attach could still fail.
"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
January 3, 2020 at 2:10 pm
First, you can't do this on a server where the same database already exists. You must be doing this on a new, or different, instance of SQL Server.
"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
January 3, 2020 at 10:34 am
While the results may be the same, putting the JOIN criteria and the filtering criteria into the WHERE clause is less clear. I'd always default to having the JOIN criteria...
"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
January 2, 2020 at 1:17 pm
Check the execution plans, but I'll bet the second choice there performs better.
"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
January 2, 2020 at 1:15 pm
Thanks for the link - one that I wasn't aware of and rather good for sure
Not a problem. Niko is the best. It's where I start when I have...
"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
December 27, 2019 at 6:06 pm
Frederico, do you have any test case to support your speculations?
I (and I guess Jeff Moden too) would be particularly interested in a test script which demonstrates advantages 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
December 27, 2019 at 11:02 am
I would still consider them good for history/audit tables as these aren't queried often - saving on space is what would really be important here, not speed of processing...
"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
December 25, 2019 at 12:40 pm
Columnstore index is a workaround for denormalised data storage.
follow basic data normalisation rules and there won’t be any place for columnstore indexes in your database.
not to mention - you’re...
"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
December 25, 2019 at 12:39 pm
Second, aggregates. Analysis. These are where they shine. If you're not seeing GROUP BY in the queries, I wouldn't suggest using them.
So, not good for general history/audit tables...
"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
December 25, 2019 at 12:37 pm
You could certainly query sys.dm_exec_query_stats. That's going to show the queries that are currently in the cache, recent activity. It includes a last execution time too, so you can get...
"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
December 20, 2019 at 1:42 pm
Post the plans for both queries and it might be possible to suss out what's going on.
"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
December 20, 2019 at 1:39 pm
Yes to all the stuff @leo-2.Miller states. We simply don't have the data we need to tell you what the solution is. I'm pretty sure you don't have the 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
December 20, 2019 at 12:11 pm
The app may be handling the deadlock "gracefully" by retrying the failed process (try/catch) without the user even knowing, but ideally the app should be fixed to reduce the...
"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
December 20, 2019 at 12:09 pm
Thanks Grant. I really appreciate for helping me with this. Yes it is a classic deadlock problem . Actually we have only one table and just one simple update....
"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
December 20, 2019 at 12:07 pm
Viewing 15 posts - 2,206 through 2,220 (of 22,227 total)