| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Datfiles/logfiles layout
Two little bits more. I managed to type "through" where I meant "throw" (as
in throw them away), and another useful way to mitigate the contention of
"lgwr" and "arch" is to use plenty of on line logs. Most systems now have
plenty of acreage and limited spindle bandwidth mitigated by cache. You do
"ok" as long as you don't overrun the cache. Likewise on line logs. Other
than space, there is no significant penalty for having quite a few of them.
(I'm a fan of 12, which is divisible by 2, 3, and 4 for potential
ping-ponging.) You do not actually have to wait for "arch" to complete until
"lgwr" wraps all the way around and wants to switch to the on line log
you're still archiving. (You'll still get potentially delaying interference
between "arch" reading and "lgwr" writing the same array unless you
"ping-pong" them.)
-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]On Behalf Of Mark W. Farnham
Sent: Friday, July 02, 2004 10:57 AM
To: oracle-l_at_freelists.org
Subject: RE: Datfiles/logfiles layout
With only two arrays useful separation is a challenge.
You didn't mention where your archived logs go. If you're testing for throughput without archiving and you plan archiving for production, you will probably get a pretty big surprise when you turn on archiving. So even if you don't care about recovery, write the logs and through them away if you want meaningful measurements. Use the same level of block checking and all that stuff that you plan to use in production, or else you're not really testing.
Once you get everything else out of the way and you actually drive an i/o challenge to disk for inserts, it is usually useful to ping-pong the online redo logs so that "arch" is reading a different drive than "lgwr" is writing. While multi-user considerations may mute the advantage, this can make a big difference if a batch insert is dominating performance considerations. You need to use a multiple of logs that is divisible by the available number of locations that have independent throughput (it seems as if this is two in your case), and you need to create them in order to they alternate. If the archive destination is one of these arrays, it still may be okay, since arch will alternate pretty big slugs of read and write when it is operating on the same array or "stripe set."
You apparently have all your control files on the same array, which is probably not a good idea. Are you going with a single control file and relying on multiplexed disks (aka mirrors) when you get to production? Even in test I would not go with a single control file.
Finally, you *may* find that at steady state there is an imbalance in i/o signatures between tables and indexes, so you may want a table tablespace and an index tablespace on each array with the indexes of a given table counterposed with the indexes for that table. If your total production layout is as simple as your test, then it looks pretty good otherwise.
mwf
-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]On Behalf Of Harvinder Singh
Sent: Friday, July 02, 2004 10:24 AM
To: oracle-l_at_freelists.org
Subject: Datfiles/logfiles layout
Hi,
We are setting up the oracle database machine and layout the files as
following.=20
Env 10g on Win2k
2 cpu xeon processor box
2 raid array (raid 0, since this is testing) of 14 36G each and
controller for each
Current layout:
Oracle software, control file, Rollback tablespace, temp tablespace,
index tablespace(100GB file with extent sixe of 512MB) on 1 raid array
(H:)
Table tablespace (100GB file with extent size of 1GB), redo logs on
another array (I:)
We are testing insert performance where we are selecting from IOT table (on H:) and inserting into another table (on (I:) and its indexes on (H:)
Is this configuration looks ok or what are the changes that we can try?
Thanks
--Harvinder
 |
 |