Viewing 15 posts - 8,311 through 8,325 (of 22,224 total)
According to the statistics you're moving 197 million rows with no where clause. Don't bother with an index. It won't do any good. As currently built out, there's almost nothing...
"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
April 30, 2014 at 2:30 am
Yeah, but that's index fragmentation. Shrinking and growing a database file fragments at the OS level. There's a decent little article about how to look at this over here at...
"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
April 29, 2014 at 3:47 pm
TheSQLGuru (4/29/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
April 29, 2014 at 3:42 pm
Try using the WAITFOR command in T-SQL. That'll pause the execution of the query and you should see a timeout.
"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
April 29, 2014 at 3:38 pm
You can get the plan_handle by querying sys.dm_exec_query_stats or sys.dm_exec_proc_stats if it's a stored procedure. If you need to use sys.dm_exec_query_stats, you can combine it with sys.dm_exec_sql_text in order to...
"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
April 29, 2014 at 3:37 pm
New Born DBA (4/29/2014)
And I also mentioned that we are shrinking the DB every week, so you guys don't think that's what's causing the problem right?
I'm not saying this...
"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
April 29, 2014 at 3:21 pm
The query times aren't terribly long at 200-800 milliseconds or so. But the fact that you're using sp_trace_getdata to collect information means you gathered this using the GUI. Don't do...
"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
April 29, 2014 at 11:54 am
I only go to the clouds for my demos if I'm actually demoing cloud stuff. Too much can go wrong in demos anyway. Adding in connectivity on top of it...
"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
April 29, 2014 at 11:46 am
scott_lotus (4/29/2014)
The "WAIT STATISICS" tab is currently showing 75% MISC WAITS.
I will check it again during the index creation and publish...
"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
April 29, 2014 at 11:34 am
Just in terms of management, loads and loads of databases is a bit of a nightmare. But, from the standpoint of separation of customers, it's not a bad idea. 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
April 29, 2014 at 11:30 am
If you go to options when setting up a compare, by default, it's supposed to check the identity seed, but you can turn it off.
"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
April 29, 2014 at 8:54 am
Wasn't trying to be critical of it, but that is the root of the problem. You have empty tables that are driving data without a correlation between the two that'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
April 29, 2014 at 8:09 am
Not really. It sounds like either data growth, or space used through fragmentation. Do you have a defrag running occasionally to ensure optimal use of the space? It sounds like...
"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
April 29, 2014 at 8:02 am
The documentation of the copy database is unclear as to exactly what it does. It says it moves meta-data about the objects, but I don't see details.
Basically, it creates...
"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
April 29, 2014 at 7:56 am
First off, there's a max of 32,767 databases per instance, so you're not getting to 50,000 any time soon.
In general, if you cluster a SQL Server instance, you move all...
"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
April 29, 2014 at 6:36 am
Viewing 15 posts - 8,311 through 8,325 (of 22,224 total)