Viewing 15 posts - 8,521 through 8,535 (of 22,224 total)
In general, I suggest putting the clustered index on the most commonly used path to access the data. This is because the data is stored on the clustered index.
"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 28, 2014 at 7:02 am
yuvipoy (3/28/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
March 28, 2014 at 7:00 am
Yeah, it's pretty likely that FKs are checking each constraint. You can look at the execution plan to confirm this, but I'm sure it's accurate. If you are doing very...
"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 28, 2014 at 6:31 am
Another thought, are there assumptions built into the code that the next value will always be one greater, because starting in SQL Server 2012, there can be large gaps 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 28, 2014 at 6:16 am
It's the MOVE option you need. The RESTORE statement will attempt to restore the files defined in the backup. So, in order to restore to a new database, you 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
March 28, 2014 at 6:13 am
The issue of Data Definition Language statements. CREATE TABLE, ALTER PROCEDURE, etc. Here's the entry in Books Online with a lot more details.
What exactly are you looking for specifically?
"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 28, 2014 at 6:11 am
free_mascot (3/28/2014)
Check the option of Extended event.
Sorry? What?
Do you mean set up an extended event session to capture sql batches and rpc calls? That's a good idea. 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
March 28, 2014 at 6:08 am
It really is down to a unique setting for each alert, sometimes a unique setting for each server for each alert. There's no single answer to any of these. As...
"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 28, 2014 at 6:06 am
You can use ORDER BY along with TOP 1 to get the row that has the highest value.
"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 28, 2014 at 6:04 am
ShowPlan and StmtComplete are extremely resource intensive events to capture. Be very cautious doing this on a production system.
"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 28, 2014 at 6:03 am
Just remember that a clustered index is the table, so it may look very large, but that's because it's storing all 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
March 28, 2014 at 5:57 am
You're posting in the 2008 forum.
Not sure what you mean by batch delete. SET ROWCOUNT just limits the rows returned, but the query plan and the access of 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
March 28, 2014 at 5:39 am
The key is to make your queries run as fast as possible and keep the transactions as short as possible. So, if you're running an UPDATE statement, make sure it'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 28, 2014 at 4:37 am
Instead of using SET ROWCOUNT, actually filter the data using some other criteria. SET ROWCOUNT is deprecated anyway and removed from the product in SQL Server 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
March 28, 2014 at 4:33 am
You've restarted the server, which rebuilds tempdb, and you're still seeing this? I strongly suspect hardware issues then.
"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 28, 2014 at 4:31 am
Viewing 15 posts - 8,521 through 8,535 (of 22,224 total)