Re: Managing Large tablespaces

The database is relatively static, growth of about 10 - 20% annually mostly during predictable batching operations. Up to 500 users, mostly inquiry. The customer will do hot backups using the ARCServe Oracle backup agent. The plan is to run the database on a hardware based RAID 5 with 4 or 5 spindles (36GB 15k RPM drives).

Steve

> To answer your question, you will need to see what kind of transactions
> you are doing and how much data will be continually added. The answer
> will also have a lot to do with your back and recovery methods.
> Exp/Imp? HotBackup? ColdBackup? Backupto tape? backup to disk? How many
> spindles (disks) are being used.
>
> Although 50G is NOT a big database by any stretch of the imagination, if
> tablespace size is a concern, you can also look at partitioning. This
> is where the table data is stored across multiple tablespaces that can
> use multiple datafiles.
>
> COLA has values AAAAA through ZZZZZ
> store AAAAA-GZZZZ in tablespace1 that has 10 data files 1G in size.
> store HAAAA-LZZZZ in tablespace2 that has 10 data files 1G in size.
> ...... You get the picture (I hope)
>
> Let's also say that your system has 10 logical disks (raid 0+1 or 5**),
> spread the datafiles for each tablespace over all 10 spindles for
> improved I/O performance. Should you loose a disk, media revovery of
> all data files stored on that disk would need to be done. While all of
> this would be possible, you are going to have to sit down and work
> through all the possible failure scenarios and what it would take to do
> a recovery. Several very large data files, a bunch of smaller data
> files, partitioning. Each postition has it's own
> advantages/disadvantages.
>
> ** (raid 0+1,5) most small systems won't notice any difference. Unless
> you are trying to do 200+ TPS with a very large number of users, then it
> might begin to show.
Received on Mon Jul 15 2002 - 17:32:28 CDT