Viewing 15 posts - 7,321 through 7,335 (of 22,219 total)
That's really odd that the 120 compatibility level would do this. Have you applied any of the CUs?
"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 22, 2014 at 9:21 am
My first thoughts were around parameter sniffing and issues there, especially if you're seeing changes in behavior based on changing the cardinality estimator (changing the compatibility level). But, I'm also...
"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 22, 2014 at 5:48 am
Put your database code into source control and start treating it, as much as possible, like your application code. But, if you really want to start talking about database deployment...
"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 22, 2014 at 1:14 am
Take a look at what Kendal Van Dyke has been working on, it might help.
"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 22, 2014 at 1:11 am
You might take a look at this article[/url] on Simple-Talk. It could help.
"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 22, 2014 at 1:10 am
That's pretty small data growth. Check the execution plans for the query from the old database as compared to the new one. See if they're different.
"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 21, 2014 at 6:16 am
One very good reason for calling procedures from within a wrapper procedure is when you're dealing with IF statements in the procedure that would lead to bad parameter sniffing issues...
"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 20, 2014 at 3:45 pm
With completely different data sets? No, there's no way to use transaction logs to do this. What you're describing is basically merge replication. That might be something to explore.
"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 20, 2014 at 3:42 pm
Well, there's nothing inherent in SQL Server that would result in the system running slower just because of the time passed. You've already hit on what is usually the biggest...
"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 20, 2014 at 3:40 pm
Absolutely beguiling. I think everyone knows it so well because we've all been bitten by it at one point or another.
"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 20, 2014 at 3:28 pm
Jacek Falkiewicz (10/20/2014)
Grant Fritchey (10/19/2014)
"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 20, 2014 at 10:06 am
In addition to the OR, we're doing NOT EQUALS. Between the two you're pretty much guaranteed scans on your indexes.
"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 20, 2014 at 10:00 am
If you need to capture events per database, you can set up a filter in extended events. In fact, it's filtering mechanism is the one gigantic improvement over trace events...
"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 20, 2014 at 7:24 am
Eirikur Eiriksson (10/19/2014)
"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 20, 2014 at 4:51 am
Probably not, since everything changed. You might want to modify that process too.
"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 20, 2014 at 4:48 am
Viewing 15 posts - 7,321 through 7,335 (of 22,219 total)