Viewing 15 posts - 17,881 through 17,895 (of 22,226 total)
You could run DBCC UPDATEUSAGE. It's possible the allocation information is messed up because of dropped objects, large scale data changes, etc.
"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
March 30, 2009 at 12:42 pm
I would start on a problem like this down one of two paths. Either I feel like I know the query & indexes well enough that I'm going to look...
"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
March 30, 2009 at 12:33 pm
First, if you can define them, get foreign key constraints in place. As the last post said, you're looking at a loss of data integrity. That's worse than any performance...
"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
March 30, 2009 at 12:26 pm
I'd use the method of creating a new copy of the table with all the right structures, migrate the data over, then drop the other table and it's FK's,...
"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
March 30, 2009 at 12:23 pm
My memories of 6.5 are fuzzy (and painful) but I think you could backup directly to disk even then, but I could be wrong.
The one reason I can think 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
March 30, 2009 at 12:10 pm
First disable the automatic affinity in the check box below.
"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
March 30, 2009 at 9:27 am
Did you run the Database Tuning Advisor against that system? That looks like artifacts from there. Statistics usually have look something like _WA_SYS_0000003_0425A276.
"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
March 30, 2009 at 9:24 am
To your first question, neither of those tables looks terribly fragmented. When the logical fragmentation breaks 30%, you might want to consider reorganizing the index. As it gets more fragmented...
"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
March 30, 2009 at 9:20 am
Is it possible the statistics are out of date? Maybe it's working harder to gather information on some servers compared to others because of the status of the statistics.
"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
March 30, 2009 at 9:10 am
Yep, that was it. I was just curious what your thought processes were. I do agree.
"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
March 30, 2009 at 7:47 am
GilaMonster (3/30/2009)
"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
March 30, 2009 at 7:44 am
Interesting experiment.
The only way I know to affect compile time is to modify the query itself. The more complicated it is, the longer the compile time, the simpler, the quicker....
"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
March 30, 2009 at 7:30 am
Impossible to say without more information, but probably you're getting table scans.
"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
March 30, 2009 at 7:08 am
To do this in TSQL, you would need to use ad hoc queries and build your query as a string. SP_EXECUTESQL would be the best use.
Generally, something like this might...
"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
March 30, 2009 at 7:05 am
Steve Jones - Editor (3/29/2009)
mohit is correct.Expiration is for overwriting backups, like if you had multiple ones in a file. (which is a bad idea)
I'm not saying you're wrong, in...
"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
March 30, 2009 at 6:55 am
Viewing 15 posts - 17,881 through 17,895 (of 22,226 total)