Re: Is 60M rows a lot?

On Sun, 20 Mar 2005 20:49:13 +0000, Niall Litchfield wrote:

> I'd consider a 30gb TABLE, which seems to be what the OP is asking about
> to be worthy of techniques such as partitioning etc which apply to large
> databases. We aren't told if this is OLTP or not (i.e a mail server) but
> if it is 2 million+ transactions per working day seems to me not to be
> insignificant. Now admittedly back on the last coure I did, I got told
> by a fellow attendee that *everyone* was a 24*7 global multi-billion
> dollar business, but that isn't my world.

I'd extend your comment as follows:

regardless of the size of the database, it is rarely wrong to at least briefly consider all available techniques, such as partitioning, that are available.

In this case, partitioning could have other benefits such as simpler management or administration, as the OP did mention keeping the data for only 30 days. Depending on the use of the data, it might also help in query performance through partition pruning, etc. However, it is an option only to Enterprise Edition, and might therefore not be suitable, simply on price.

I'd also consider RAC - if my calc's are right this will require a continuous feed of roughly 23 records per second, and RAC (even the one with Standard Edition in 10g) could help keep feed from falling behind.

So, while a moderately small database from a physical point of view, it certainly encourages critical thinking to keep it operational.

/FGB Received on Sun Mar 20 2005 - 15:28:46 CST