estimating tempdb usage

Is there any way to estimate how much space will be needed by tempdb?
I have a user executing a simple query similar to:
select orders.customerid, sum(quantity*unitprice) as amount
from orders inner join [order details]
on orders.orderid=[order details].orderid
group by orders.customerid
In other words, two thin (not too many columns) tables, equi-join,
summarizing and a group by. The only trouble is her two tables have
28000 rows and nearly 800 million rows. Her query dies after a few
hours when tempdb autogrows and runs out of disk space at 17 gig. I
know tempdb is used for work tables, joins, sorts, group bys, etc.
But knowing the columns sizes and number of rows, is there a way to
estimate how much tempdb will be needed? She's basically the only
user on the system.
By the way, this is SQL Server 2000.
Thanks,
ScottI guess it would be better to Grow the tempdb first, then run oyur query.
I had the same problem on SQL Server 6.5 to 2000 migration with the log
files (we had big tables as well) , the Autogrowth didn´t work. So we had to
create the database and transaction logs big enough to support migration
process before initiate it.
HTH
"scott parmelee" <s_parmelee@.hotmail.com> escreveu na mensagem
news:e14a8116.0311130819.725c0a4@.posting.google.com...
> Is there any way to estimate how much space will be needed by tempdb?
> I have a user executing a simple query similar to:
> select orders.customerid, sum(quantity*unitprice) as amount
> from orders inner join [order details]
> on orders.orderid=[order details].orderid
> group by orders.customerid
> In other words, two thin (not too many columns) tables, equi-join,
> summarizing and a group by. The only trouble is her two tables have
> 28000 rows and nearly 800 million rows. Her query dies after a few
> hours when tempdb autogrows and runs out of disk space at 17 gig. I
> know tempdb is used for work tables, joins, sorts, group bys, etc.
> But knowing the columns sizes and number of rows, is there a way to
> estimate how much tempdb will be needed? She's basically the only
> user on the system.
> By the way, this is SQL Server 2000.
> Thanks,
> Scott

Estimate necessary hardware

I would like to ask some help for estimating necessary hardware for a database, I can tell you about usage profile the following:

- 2 tables, approximately 100.000 records, the tables joined in 1:1 relation, one record is approximately 500 bytes long
- typical scenario:
- select what returns 1 or zero record
- if it returned 1 record an update performed on this record
- the event logged in a third table (one insert)
- this typical scenario needs to run 100-300 times in every second

Can you tell me any advice on sizing of hardware for this? We can rely on a well designed database structure (proper indexes, etc...)

Thanx in advance

It is really a smallish database.

These are just minimal suggestions, and without more detail, they are just as good as visiting a seer.

A dual proc, dual core box, 64 bit

4GB memory -8GB would be better

64 Bit Win2003 Server

64 bit SQL Server

A SAN/NAS (or drive array) with the following LUNs/Drives: (I would go for 15K, 144GB or larger, drives.

Drive/LUN for TempDB

Drive/LUN for Log file

Drive/LUN for Database

(Separate local drive for OS and virtual memory file.)

By combining 64bit software with the fastest possible hardware you can afford, you will have planned ahead for scaling out.