Viewing 15 posts - 19,891 through 19,905 (of 22,219 total)
I haven't tried that yet. I suppose it will work if documentation says so. It's not one of these places I like to take chances with.
"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 24, 2008 at 7:50 am
Then you have to restore to a new location, either a new database or a new server, and then move the data you need to recover from that new location...
"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 24, 2008 at 7:47 am
The answer to that really depends on the query in question. Here's an example where each results in the same data
SELECT a.*
FROM TableA a
WHERE a.ColA IN (SELECT ColA FROM TableB)
SELECT...
"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 24, 2008 at 7:45 am
Please don't cross-post.
Answering over here: http://www.sqlservercentral.com/Forums/Topic540018-149-1.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 24, 2008 at 7:41 am
As long as you don't have conditional execution of the procedures, you can really go either way. You should get identical plans. This becomes a problem when people put IF...
"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 24, 2008 at 7:38 am
If you're creating the SSIS packages in 2008, you won't be able to deploy them to 2005. I also strongly recommend you DO NOT install 2008 alongside 2005 just yet....
"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 24, 2008 at 7:16 am
Interesting Jack, thanks for the info. I was under the impression that it was possible to lose data, regardless of the mechanisms...
So, if I start the service on the server...
"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 24, 2008 at 7:05 am
Statement complete should have choked you out with information, especially if you're running cursors. So you went into TSQL and turned on SQL:StmtCompleted and into Stored Procedures and enabled SP:StmtCompleted?...
"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 23, 2008 at 1:37 pm
That's either one of two things, your statistics are out of date or, the estimated plan is far off from the actual. It does happen. Try updating your statistics (or...
"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 23, 2008 at 1:03 pm
Make sure you're using exactly the same parameters against exactly the same data set (always compare apples to apples).
Get the statistics IO for the set of queries and 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
July 23, 2008 at 11:17 am
That query lists the rows & columns & stuff for the tables in a db, but I think what the OP is asking for is a way to determine 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
July 23, 2008 at 11:10 am
to answer that, look at the execution plan.
It really depends on which tables you add, but adding anything can make the optimizer choose different options in its attempts 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
July 23, 2008 at 10:30 am
Just a point of detail... You can overflow the buffer even when capturing to file. It just takes a heck of lot more to do that since writing out 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 23, 2008 at 10:22 am
I agree with Jack. It's been my experience that you're better off loading external data into a temp table and then processing it with everything else. I also agree 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 23, 2008 at 9:37 am
Getting an estimated execution plan is no big deal. There's a button right there in the query window in Management Studio.
No, what you need is something more. The estimated plan...
"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 23, 2008 at 9:28 am
Viewing 15 posts - 19,891 through 19,905 (of 22,219 total)