Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> Re: Choosing data file size for a multi TB database? (just the bit about 90% utilization)

Re: Choosing data file size for a multi TB database? (just the bit about 90% utilization)

From: <tboss_at_bossconsulting.com>
Date: Tue, 30 Aug 2005 11:26:18 -0400 (EDT)
Message-Id: <200508301526.j7UFQIec031572@vegeta.p6m7g8.net>


Moving large files around is a difficult situation, yes, but if you plan ahead that need should be minimized.

Can you imagine the nightmare you'd bestow upon the operational DBA if you sized files at 2gb and your database was 10tb? I'd hunt you down and throttle you. Plus, there's a limit to the number of files an Oracle database can handle (65534, which in reality isn't approachable even in a 10tb environment but you never know).

Plan ahead, get the archetecture straightened out and then make the datafiles as large as you can make them. A datafile's maximum size is 4096*1024-1 blocks, so in an 8k server the biggest you can make a datafile is 32gb. IN a 32k block size server the limit is considerably bigger (128gb).

Things to keep in mind: with data sizes this big, you're probably looking at storage on a SAN with multiple file systems. Look into partitioning (especially composite partitioning, with a hash subpartitioning scheme to automatically load balance your data so you don't spend hours doing it by hand) and parallel operations. Keep in mind the i/o controllers on the SAN and the file systems they control. Map out your data on disparate i/o devices to avoid contention. If you do hash partition, remember the number of hash partitions must be a power of 2 (2, 4, 8, 16 etc) else you'll get skewed partitions (with no easy way to clean them up).

Don't be afraid to use RAW either. Unless you've got Veritas or somesort of high-end cooked file system product to speed things up.

You're also probably looking at a huge raid question on the SAN with this much space. If you've got unlimited funds and can help direct the SAN purchase, you can go raid 0/1 on the whole enterprise. More likely you'll be forced to accept Raid-5 segments; just make sure you put read-only stuff on raid5 and never put undo, redo, or temp on raid5. Look into the SAN company and see if they can do a "raid 3" config instead, which gives you the best of both worlds between raid0/1 and raid5.

my 2 cents.
Todd

>
> How would you approach task of sizing data files for a project that will
> start with
> a 1TB database but may relatively quickly grow to stabilize at around 10TB
> mark?

--
http://www.freelists.org/webpage/oracle-l
Received on Tue Aug 30 2005 - 10:28:32 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US