Mark Roberts wrote:
> 1. 2.5-3TB, several others that are of fractional sisize.
>
>
> ...
>
>
> 5. They do pretty well, actually. Our aggregate fact tables regularly
> join to metadata tables and we have an average query return time of
> 10-30s. We do make some usage of denormalized mviews for
> chained/hierarchical metadata tables.
>
>
Just out of curiosity, how do you replicate that amount of data?
> ...
>
> A few notes: our database really can be broken into a very typical ETL
> database: medium/high input (write) volume with low latency access
> required. I can provide a developer's view of what is necessary to keep
> a database of this size running, but I'm under no illusion that it's
> actually a "large" database.
>
> I'd go into more details, but I'd hate to be rambling. If anyone's
> actually interested about any specific parts, feel free to ask. :)
>
I'd be very interested in a developers view of running and maintaining a
database this size.
Mostly what choices is made during development that might have been
different on a smaller database.
I'm also curious about the maintenance needed to keep a database this
size healthy over time.
Regards,
/roppert
> Also, if you feel that we're doing "something wrong", feel free to
> comment there too. :)
>
> -Mark
>
>
>