Get out you flame retardant clothing.
See below.
--
Robert Fazio, Oracle DBA
rfazio_at_home.com
remove nospam from reply address
http://24.8.218.197/
"akolk - gelrevision.nl" <akolk_at_gelrevision.nl> wrote in message
news:393FAAB4.31366B14_at_gelrevision.nl...
> It is not wise to dedicate disks for certain functions. The best and
simplest thing
> to do is stripe over as many disks as you can .....
What? The idea is not to stripe over as many disks as you can. If anything
the goal is to distribute the I/O requests over
as many disks as you can. There is an exception though. In the case of
redo logs, the idea is to make those writes occur as quickly and efficiently
as possible. Because of the way that redo logs are written, the best
practice for performance is to actually give them their own disk, Period!
Any other I/O's to the disks dedicated to the redo logs, will cause the head
to move to accommodate the request. This will cause the head to have to
move back to finish the redo writes. If they are the only one on the disk,
the head moves slowly and only for the redo write requests. I realize this
is an expensive proposition, one disk or two if mirroring per redo log file,
but if you want performance you will get it here. Also with that approach
there is no need to stripe. If you choose not to do that, most likely for
the cost issues, then I agree stripe heavily. As far as where, I don't
really think redo's matter much, but I would most likely choose the same as
the data, and not the index. The only thing is that I would suggest that it
not be on a RAID 5 device, remember they are basically only writes.
Inserts into the data section will most likely be similar types of writes to
the redo's whereas the writes to the index are quite random.
>
> Point 2 is old and has never been true and can really hurt
performance/throughput
> of your database
Again What? I will address the second first. How in the world do you think
separating the indexes from the tables will hurt performance? A query will
make a request first on the index and second on the table, after it knows
where to look. The index read's although can be a full scan are often very
random. The scans on the data are more than likely not. The striping on
data tablespaces can be much less agressive than on the indexes. In a
heavily utilized oltp system, that starts to fade, but in a DSS it is more
than true. What will ultimately occur though is that the data area in a DSS
system will require, due to its size, to eventually be striped. As for it
being old and never true, what Oracle school did you go to, because I have
never before heard that statement made. Again the idea is to distribute the
number of I/O requests to the operating system to as many disks and
controllers as possible for the entire system, but not overload them all.
Heavy striping can cause most requests to go through almost all disks and
controllers for each request. You are trying to balance the load, not
saturate it.
>
> Also remember Databases is about disks/IOs not number of files ! (1 disk
with 10
> files or 1 file will perform as bad).
Ok, you do know something. 1 disk with 10 files MAY perform as poorly as 1
file on 1 disk. Indexes are the exception to this. Indexes can and will
get fragmented and require rebuilds since they don't actually delete keys of
deleted rows. The tables however will reuse that space. Due to the
previous statement, Indexes can and will really screw up the fragmentation
of a tablespace if indexes are in the same tablespace as the data, making
those tables that require full table scans to go all over the place. This
will also screw up the O/S that is trying to perform read ahead requests.
There will be a lot of misses, since it won't be able to anticipate where it
really needs to go next.
Even if you want to use one and only one disk/filesystem. At the very least
you need to separate the indexes from the data.
The number of files, as was stated, is to allow recovery to occur in a
timely fashion, and with as little disruption as possible to the entire user
community. If you have one tablespace with one datafile, a single
corruption will take down the entire database. A single datafile in a
single tablespace with many tablespaces and datafiles, may not even be
noticed during the entire recovery phase.
>
> Waiting for replies ;-)
>
> Anjo.
>
>
> Andreas Stephan wrote:
>
> > Hi Chuan,
> >
> > here are some rules I use when I install a database:
> >
> > 1) never put rollback segment tablespace on a drive containig data
(table) or
> > index tablespaces
> > 2) never put data and index tablespaces on the same drive if they
interact
> > 3) use a max of 2Gig Datafiles to keep maintenance simpler and to avoid
> > unnecessary recovery time
> > (it is easier and quicker to recover one 2 Gig Datafile than one of
20 Gig).
> > You can transport a
> > 2 Gig Datafile on an old dat tape but with 20 Gigs?? And copying
from tape
> > to disk or over the lan
> > will not cause any problems if you have only 2 Gig Datafiles.
> > 4) try to use partitioned tablespaces if possible. Split the data onto
the
> > partitions. Each partition should
> > reside on a separate drive to maximize performance
> >
> > putting datafile on different drives will only help if you have more
than one
> > tablespace and your objects are
> > well separated onto these tablespaces (index objects in index
tablespaces,
> > tables in data tablespaces, tables that
> > are often joined moved into separate tablespaces on separate disks or
> > implemented using clusters etc..)
> >
> > hth
> > Andy
> >
> > chuan zhang schrieb:
> >
> > > Hi, all,
> > >
> > > Could anyone tell me that which the following option is better in
terms of
> > > performance:
> > >
> > > 1) One tablespace with one big datafile, this datafile might increase
more
> > > if there are more storage.
> > >
> > > 2) One tablespace with many small or medium datafiles
> > > or
> > > 3) Splitting many datafiles into many tablespaces.
> > >
> > > Note, I have considered to put the datafiles into different drives in
order
> > > to increase the performance.
> > >
> > > Thanks
> > >
> > > Chuan Zhang
> > >
> > > Asiaonline Ltd Co.
>
>
>
>
>
>
>
Received on Thu Jun 08 2000 - 00:00:00 CDT
