Viewing 15 posts - 17,296 through 17,310 (of 22,226 total)
Lynn Pettis (6/5/2009)
Here is another OMG moment.
Oh wow. That's a first for me. He is right though. Almost any question can be answered by the suggestion to go and 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
June 5, 2009 at 2:52 pm
It's like said before. It could be so many things. Especially with the indexes you have. I suspect page splits are going to be pretty expensive. So some inserts will...
"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
June 5, 2009 at 2:50 pm
Oh, and the ID column doesn't need to be included with the covering index since it's the clustered key. The key values in a clustered index are always available within...
"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
June 5, 2009 at 1:14 pm
This index, IX_StudentServices_StID_R_DU_PID_SeID_L_GS_FD_D_SC, and this index, Indx_StudentID, are basically the same because the leading edge, the first column is the same. You really don't need the second index.
That's not getting...
"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
June 5, 2009 at 1:12 pm
Bob Hovious (6/5/2009)
A bit of humor for those of you who own dice with more than six sides.
Excellent. When they're funny, they're really funny.
"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
June 5, 2009 at 8:55 am
If it's just time, it could be contention, blocking, that made it run longer the second time than the third. It could be that the second time required a page...
"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
June 5, 2009 at 7:54 am
Adding an index will allow the COUNT process to find something with fewer pages than the entire table. Otherwise, you have to do a table scan, every time, no options.
"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
June 5, 2009 at 7:44 am
Please don't cross-post between the topics. Many of us read all the various groups and this just diffuses the conversation. Can I suggest that further comments go this thread:
http://www.sqlservercentral.com/Forums/Topic729538-357-1.aspx
"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
June 5, 2009 at 7:42 am
I'd suggest books. First off, all the Inside SQL Server 2005 (or 2008) books are worth reading. Ross Mistry's book on 2008 Administration is good. Joe Sack's book on Transact-SQL...
"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
June 5, 2009 at 6:54 am
It just sounds like a databse with two data files & two log files. Make sure, if you're restoring it to a new server, you get all four files into...
"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
June 5, 2009 at 6:47 am
First, if you can post the actual execution plan instead of the estimated, it'll make a huge difference in trying to figure out what's going on.
Next, I'm not sure...
"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
June 5, 2009 at 5:54 am
GSquared (6/4/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
June 4, 2009 at 1:37 pm
You can also use a CHAR(1). A little more flexibility than bit, but then it has a little more flexibility than bit.
"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
June 4, 2009 at 12:54 pm
ANSI_DEFAULTS
ANSI_NULLS
ANSI_PADDING
ANSI_WARNINGS
CONCAT_NULL_YIELDS_NULL
"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
June 4, 2009 at 9:03 am
How old is the backup? Has more data been added to either database? Has either one had statistics updated or indexes rebuilt? Are you using identical parameters inside the queries...
"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
June 4, 2009 at 7:57 am
Viewing 15 posts - 17,296 through 17,310 (of 22,226 total)