Viewing 15 posts - 15,046 through 15,060 (of 22,219 total)
Robert Frasca (5/11/2010)
"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, 2010 at 8:05 am
I said query hint and I meant procedure hint. I wasn't aware of that 2005 issue though.
"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, 2010 at 7:54 am
That counter is a cumulative count of recompiles. It's probably worth looking at in your situation. To see the affect of recompiles, I'd set up a server side trace 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 11, 2010 at 7:46 am
Gianluca Sartori (5/11/2010)
"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, 2010 at 7:27 am
Without the things that Gail asked for the only suggestion I can make is, reduce the size of the query. Any query 2000 lines long is probably going about stuff...
"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, 2010 at 6:56 am
paul.goldstraw (5/11/2010)
We did look a long time ago at what plans existed for the procedure. There were two and one was always called by the...
"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, 2010 at 6:51 am
Robert Frasca (5/10/2010)
"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, 2010 at 5:42 am
Jeff Moden (5/10/2010)
dbowlin (5/10/2010)
The more tools you have in your toolbelt the better off you will be.
There is such a thing as carrying too many tools on your "toolbelt" 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 11, 2010 at 5:37 am
Several of those queries are loading data into temporary tables and then loading the same data into permanent tables. Why? Can't they just run the query to move 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
May 11, 2010 at 5:36 am
ankur.hooda (5/11/2010)
For backup and recovery stratergy,
Consider following
1) how heavily are your db updated--> helps to decide log file size
2) size of db
3)how much db size increase on daily --->basis helps...
"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, 2010 at 5:33 am
I'd dive in, but Gail's done a better job of keeping things clear than I would have.
The original post sounds like an issue around parameter sniffing and your issue sounds...
"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, 2010 at 5:29 am
kastros.george (5/10/2010)
option keepplan
or somthing like that
i think the problem is that sql server tries to generate an execution plan, aby trying to estimate row size and row count
Use...
"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, 2010 at 12:54 pm
It's hard to know for sure, but I'd check the default ANSI settings on your connections. If they're different that could affect how that procedure is processed.
My next guess...
"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, 2010 at 12:53 pm
I would suggest you get the execution plan for the query and take a look at it. You're probably getting a table/clustered index scan, or possibly and index scan, instead...
"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, 2010 at 12:49 pm
What you described is blocking. Deadlocks occur when two processes attempt to generate locks on resources that the other process has locks on, usually in opposite order, so session_id =1...
"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, 2010 at 12:36 pm
Viewing 15 posts - 15,046 through 15,060 (of 22,219 total)