Re: LARGE DATABASES-UNIX SUN SOLARIS 2.4

In article <4f8497$j4p_at_maverick.tad.eds.com> bob_at_latcost1.alaao.ats.eds.com (Bob Stewart) writes:
>David Bellamy (bellamy_at_commerce.uq.edu.au) wrote:
>
>: Raw partitions are supported, but are not really recommended unless you
>: know what you are doing. They provide slight (10-30%) performance
>: improvement but are much harder to manage, backups etc. They also look
>
>10-30% performance improvement may not look like much, until you have
>a sizeable database to manage. I have an application where the dataload
>takes 5 hours a day to update the database. A 30% performance improvement
>here is significant!

Some people have seen 5% improvement, some have seen negative improvement, some claim 300%. Very few have done an honest benchmark.

>
>: like unused partitions on partition maps. Do you really want to go on
>: holiday and some junior sys prog looking for some spare space decides to
>: .... :-)
>
>I suggest that root password be severely restricted just on general
>principals. If you have a shop where the junior programmers have
>root access, you're eventually going to have a disaster, anyway.

It doesn't have to be a junior person. It can be a quite experienced person, new to the site. Also, some sites split management of db's and management of systems, so the new systems guy comes in and says, "Oh goody, look at this unused space!" The classic case is, "root password? Oh, we have severely restricted that. That person is no longer with us. Oh, you can't bring down the system, people need to work on it."

From what I've seen posted about MTS, IMO Oracle is not entirely as good at debugging filesystems as millions of unix users.

>
>: If you need large tablespaces, then just use multiple files per
>: tablespace. Each file can be 2GB. The filesystem restriction is
>: somewhere about 4TB.
>
>Be sure to use a clean disk for Oracle tablespaces/datafiles. Just
>adding a tablespace to an in-use disk is asking for a performance hit.
>The amount would depend on the usage patterns for the disk, and how
>many "holes" were filled when creating the datafile. It's best to just
>reserve a complete partition/slice for Oracle datafiles, and use it up
>completely if you use it at all. However, in some applications, where I/O
>wait time is unacceptable, you might even want to have disks with relatively
>large areas of unused space to help improve average seek times.

You seem to have a very static view of databases. Have you only worked on new systems? How do you deal with a system successful beyond all projections?

jg

>
>In cases where your database is very small, or response/process time is
>not important, it's OK to share a disk between Oracle and other applications.
>However, in general, if a disk has a tablespace on it, nothing else should
>be on the disk. Even if a large percentage of the disk is left unused.
>
>Later.
>--
>Bob Stewart ASE
>(310) 335-7152 Air Transportation Division
>bob_at_latcost1.alaao.ats.eds.com
>
>I am definitely NOT speaking for EDS.

-- 
Joel Garry               joelga_at_rossinc.com               Compuserve 70661,1534
These are my opinions, not necessarily those of Ross Systems, Inc.   <> <>
%DCL-W-SOFTONEDGEDONTPUSH, Software On Edge - Don't Push.            \ V /
panic: ifree: freeing free inodes...                                   O