The correlated subquery actually performs better when NOT is involved.  Try looking at the execution times for each.

SELECT *

FROM T1

WHERE NOT EXISTS

(SELECT *

 FROM T2

 WHERE CustNo = T1.CustNo AND OrderNo = T1.OrderNo)

CREATE TABLE BadWords(Word varchar(4) PRIMARY KEY)

INSERT BadWords

SELECT 'bad'

UNION ALL SELECT 'word'

UNION ALL SELECT '#$!*'

CREATE TABLE Contacts(Id smallint IDENTITY PRIMARY KEY, Email varchar(80))

INSERT Contacts(Email)

SELECT 'sbad@opus.com'

UNION ALL SELECT 'good@egad.com'

UNION ALL SELECT '#$!*@cupro.net'

UNION ALL SELECT 'hiram@jpvh.net'

DELETE c

FROM Contacts c CROSS...

Rather than putting your list in a variable, put it into a temporary table as one row per value.  Then just use a join to that temporary table in your...

You should obviously increase the initial size of tempdb; one doesn't want autogrowth ocurring for any database, of course.  You cannot truncate tempdb's log file because tempdb uses the simple...

I think this article is more relevant to the thread; it recommends 64KB blocks and RAID 0+1 over RAID5:

http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/sqlops6.mspx

A quote:

"The only advantage the older [sic] RAID 5 has is...

That's a bigger "it depends."  The optimum stripe size (which is the block size of each drive in the set) depends upon the RAID level, databse type, and, most importantly,...

> Defrag isn't capable to deal with 64K blocks or why do you say this about the third party tool/win2003?

Yes, Windows 2000 Server defrag utility cannot deal with blocks larger...

As you put the word in quotes, you know that the correct answer is "it depends."  64K is usually a much better starting point than 4K, though.  Just be aware...

Thanks, Frank.    I hadn't seen that Baarf site, but I just signed up as a member.

Now that it's nearly impossible to find drives...

Given these constraints, you will most likely have the best compromise of performance, disaster recoverablity, and capacity by using your idea of a RAID 1 pair for data and executables...

Sounds like an inefficient query plan (probably a table scan) got cached.  This usually happens when the query is first run (after the server is restarted) with atypical (e.g. NULL)...

Your boss is wrong on every point.  If this server will have OLAP databases, a good strategy would be to add a sixth drive, use a RAID 1 pair for...

Although it's easy enough to write a trigger to enforce this, I prefer to use an indexed view for this in SQL Server 2000.

Yes.  You need to upgrade to SQL Server 2000.  SQL Server 7 did not allow computed columns in keys.