Viewing 15 posts - 19,921 through 19,935 (of 22,226 total)
SSIS does do a great job. You can also run the script manually and output the results to a file through Management Studio. You can also use sqlcmd.exe to run...
"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
July 22, 2008 at 12:02 pm
But that assumes you're not worrying about extended character sets. Wouldn't that muck with international 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
July 22, 2008 at 11:53 am
CHAR or VARCHAR is one half the size of NCHAR or NVARCHAR.
The N designates the data type as unicode which stores at twice as much data for each character.
"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
July 22, 2008 at 11:53 am
Use good indexes, especially the clustered index. Look into partitioned tables where appropriate. Use partitioned views where appropriate. Only denormalize where you can guarantee a tested performance benefit. Test everything...
"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
July 22, 2008 at 8:43 am
OK. Well, that was useless.
Hmmm... If we were comparing reads of 10000 rows of VARCHAR to NVARCHAR, I wouldn't be surprised by a two-fold increase in speed. I'm a little...
"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
July 22, 2008 at 8:37 am
Oh, I've got one of those for the dog... it'll work.
"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
July 22, 2008 at 6:24 am
I'd be more interesting in seeing the execution plan from the query.
"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
July 22, 2008 at 6:23 am
Thanks. Great description of automatic statistic maintenance, although it's for SQL Server 2000. Here's the BOL entry for 2005. There are a few differences, but nothing major.
I guess I wasn't...
"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
July 22, 2008 at 6:19 am
Start here:
http://msdn.microsoft.com/en-us/library/ms191007.aspx
Move on to here:
http://msdn.microsoft.com/en-us/library/ms177499.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
July 22, 2008 at 6:00 am
You've got two options. Set up TRY/CATCH and then return the error message that you want the user to see:
BEGIN TRY
RAISERROR('Major error in TRY...
"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
July 22, 2008 at 5:57 am
And possibly introduced others.
You do know that NOLOCK can cause duplicate data to be displayed, not just data that's in flux? I think that after FAST 1, NOLOCK is...
"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
July 22, 2008 at 5:53 am
Maybe I'm dense (ok, I am, but humor me), but if you're the one creating the temporary tables, don't you know the column names already?
"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
July 22, 2008 at 5:49 am
Since you are new to this, please take a piece of advice.
Don't use dynamic SQL.
Especially since you're just getting started. Do the work to figure out how 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
July 22, 2008 at 5:47 am
The best thing you can do is set up regular monitoring of your data. You can get third party tools like Idera's Diagnostic Manager or the new one from 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
July 22, 2008 at 5:37 am
GilaMonster (7/22/2008)
Grant Fritchey
You can also need to update statistics on smaller tables where large percentages of the data changes regularly.Wouln't the auto update take care of that?
I've found that...
"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
July 22, 2008 at 5:32 am
Viewing 15 posts - 19,921 through 19,935 (of 22,226 total)