Viewing 15 posts - 3,181 through 3,195 (of 22,224 total)
You can, although overall that sounds like a poor design. Name and address in both tables could lead to duplicate data and all sorts of issues.
I'd rather...
"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
May 11, 2018 at 6:05 am
Not to mention NOLOCK everywhere, SELECT *... This is just a series of common code anti-patterns.
"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
May 10, 2018 at 12:29 pm
"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
May 10, 2018 at 12:26 pm
"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
May 10, 2018 at 12:19 pm
So you're moving 3.3 million rows filtered down after the JOINs, etc., from 120 million rows. In short, you're moving close to 3% of the data. That's actually not usually...
"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
May 9, 2018 at 8:37 am
nothing has changed as far as I know, and it's always been uncompressed and local backup...
"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
May 9, 2018 at 8:16 am
Best of all, post the actual execution plan so we can understand how the optimizer is resolving your query and how well the statistics match your data.
One immediate...
"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
May 9, 2018 at 4:34 am
Capture the wait statistics during the backups to understand what your server is waiting on. That can very quickly narrow down what's going on. However, everyone has already pointed out...
"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
May 9, 2018 at 4:31 am
As everyone else has already said, it's almost impossible to tell you what to do without knowing the structures you're dealing with (beyond the fact that it's temp tables) and...
"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
May 9, 2018 at 4:30 am
Just verified it to be sure, the calling databases cardinality estimation is used in cross-database queries. So, yeah, when you change the database to the one that has a 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
May 8, 2018 at 12:22 pm
"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
May 8, 2018 at 11:52 am
"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
May 8, 2018 at 11:33 am
Also could be that the optimizer fixes are enabled/disabled on one of the databases and not the others. That would certainly lead to differences, especially if the query is already...
"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
May 8, 2018 at 4:58 am
"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
May 7, 2018 at 7:49 am
Ah, a restore won't move the logins. You'll need to script those out on the original server and move them over.
"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
May 4, 2018 at 9:49 am
Viewing 15 posts - 3,181 through 3,195 (of 22,224 total)