Re: Distribution of datafiles over disks vs. striped volume
Date: 1996/02/13
Message-ID: <4fr7qn$2e9_at_cherokee.advtech.uswest.com>#1/1
I have been managing databases that use stripping at the system level and that are not stripped. If you are looking at many random reads and writes (OLTP, etc..), the system stripping will be faster. If you are looking to perform many table scans, then you might want the non-stripped tablespaces. This eliminates much of the head movement that the drives would have to perform if stripped.
As far as backup and recovery is concerned, oracle will not know the difference between a partition on one physical drive or a partition on 3 physical drives. The database file is a database file to oracle. Although, with one large partition, system backups may be a problem depending on the backup stragedy that is in place.
Also, with stripping, you have the option to use raid 5 or similar disk arrangement and further protect yourself against database failure. The downside of raid is the slight degradadion in write and update times.
Lawrence is correct in saying that tablespace stripping at the database level is faster then non stripped at the database level for oltp, but the same restriction still occurs when large index scanns or table scans.
Steve
>
>The problem with making one single large volume is in backup and recovery.
>You're going to have problems particularly if you want to be able to recover
>to the point of failure. You really should look at your backup/recovery
>requirements and how you'll use Oracle to meet them before working on
>performance.
>
>If you're willing to do some administration you can still stripe the data by
>using tablespace datafiles on each disk and allowing the table to span the
>disks that way. You should stripe the indexes also.
>
>I have done benchmarking using manually striped data and indexes and for OLTP
>it will out perform schemes like putting tables on one disk and indexes on
>another. Takes a lot of administration in practice because you have to keep
>the data volume balanced.
>
>Lawrence.......
Received on Tue Feb 13 1996 - 00:00:00 CET