Viewing 15 posts - 21,946 through 21,960 (of 22,219 total)
This is one well documented approach for performance tuning:
http://www.microsoft.com/technet/prodtechnol/sql/bestpractice/performance_tuning_waits_queues.mspx
"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 11, 2007 at 11:32 am
Try creating a user defined function that returns your next id and then you can call that function from the select statement.
CREATE Function fn_GetId ()
RETURNS INT
AS
BEGIN
...your code here
...
"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 11, 2007 at 10:25 am
If you can do it that way, then eliminate the temp table and simply batch the request
SELECT SUM()
FROM
(SELECT...
UNION
SELECT...)
GROUP BY WHATEVER
Eliminates the extra overhead of the temp table.
"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 11, 2007 at 9:40 am
You've got it. To add another table to the join is:
SELECT...
FROM Table1 t1
INNER JOIN Table2 t2
ON t1.Key=t2.Key
INNER JOIN Table3 t3
ON t2.Key2= t3.key2
The reason you can't simply...
"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 11, 2007 at 9:33 am
Ball park. As indexes degrade, performance tails off because retreiving the data just requires navigating across more pages. Then, as the statistics are more & more out of date 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
April 11, 2007 at 8:16 am
By default there's a button that looks like a scroll with a disk in front of it that is "Generate Change Script." Clicking on that button will show the script...
"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 10, 2007 at 8:18 am
It's a database mail error.
"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 10, 2007 at 7:00 am
There isn't a single answer to a question like this. I'd start by looking over the best practices as listed by Microsoft here: http://www.microsoft.com/technet/prodtechnol/sql/bestpractice/default.mspx
Specifically some information on storage: "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood" Author of:
- Theodore Roosevelt
SQL Server Execution Plans
SQL Server Query Performance Tuning
April 10, 2007 at 6:54 am
That sounds odd. That's a database mail error. According to BOL either the profile specified doesn't exist or the user running doesn't have permission to access the profile. You may...
"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 10, 2007 at 6:41 am
Ah, those wonderful 3rd party apps.
I really found next to nothing documented on that process. You may want to open a call with MS. I'd also contact the vendor 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
April 10, 2007 at 5:41 am
SP2 seems to introduce almost as many problems as it fixes. That said, if I were doing an install today and didn't face one of the specific issues that SP2...
"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 9, 2007 at 11:50 am
Since this posted in SQL Server 2005, why not use nvarchar(max)? No problems there, stores the same 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
April 9, 2007 at 11:45 am
What about using sp_msforeachdb along the lines of
'SELECT [TABLE_NAME]
FROM ?.INFORMATION_SCHEMA.TABLES'
Substitute where you need to. This works across all the database and eliminates the need for a cursor.
"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 9, 2007 at 9:34 am
I've mainly grown my best practices over time. We record them locally as we discover new ones that we didn't know we need. MS has some help in this area....
"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 5, 2007 at 1:43 pm
It must be a system proc. There's not only nothing BOL. There's nothing at MSDN. There's nothing at TechNet. There's precious little on a google search. What are you mucking...
"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 5, 2007 at 11:18 am
Viewing 15 posts - 21,946 through 21,960 (of 22,219 total)