Operating System - HP-UX
1748170 Members
3989 Online
108758 Solutions
New Discussion юеВ

Re: RAID for Oracle File Systems

 
SOLVED
Go to solution
Fernando Boza
Regular Advisor

RAID for Oracle File Systems

I have a data base Oracle in HP-UX... all the base is in a single LUN.
There is some recommendation to separate the file systems of archives, data and indices in individual discs.?
Wht it would be the recommended RAID?
10 REPLIES 10
John Guster
Trusted Contributor

Re: RAID for Oracle File Systems

RAID 1 is best for control file, redo log and archive log file, is goog for database file if you can offor storage space. Many cases RAID 5(3+1) is used for systems.
Steven E. Protter
Exalted Contributor

Re: RAID for Oracle File Systems

Shalom,

The answer depends on how the data is used.

If the data is mostly read data like a data warehouse, Raid 5 for everything will do just fine.

Otherwise, heavy write areas, data, index and redo should be on raid 1 or raid 10. Archive logs can still sit on Raid 5 because the writes are sequential.

These are the latest Oracle guidelines as I remember them.

SEP
Steven E Protter
Owner of ISN Corporation
http://isnamerica.com
http://hpuxconsulting.com
Sponsor: http://hpux.ws
Twitter: http://twitter.com/hpuxlinux
Founder http://newdatacloud.com
TwoProc
Honored Contributor
Solution

Re: RAID for Oracle File Systems

I'll give you my "grey" paper on Oracle disk layout, etc. Use of it what you may.

We are the people our parents warned us about --Jimmy Buffett
Yogeeraj_1
Honored Contributor

Re: RAID for Oracle File Systems

hi,

Consider the S.A.M.E. concept -- stripe and mirror everything.

Also a few more hints that you can consider:

RAID 5 for writes = slow.
log = lots of writes.
RAID 5 + logs = not a good thing.

You may wish to rollback on the raid 5, writes to it are deferred and done by dbwr.

Cheap and but fast disks can be used for temp (it needs no protection and would cause
contention for log).

hope this helps too!
kind regards
yogeeraj
No person was ever honoured for what he received. Honour has been the reward for what he gave (clavin coolidge)
Fernando Boza
Regular Advisor

Re: RAID for Oracle File Systems

let us suppose that by price I can create a small additional RAID1 to the RAID5 that already I have.
what file system is opcionado to move?
Is good idea move "archive logs" and "redo logs" to same disk?
TwoProc
Honored Contributor

Re: RAID for Oracle File Systems

Depending on where you've got the heaviest write activity. My guess is rollback areas, but it might be temp, or, you might consider the redo logs. All three are good candidates, and should help.

Re: Yogeeraj's statement that the area for temp needs no protection (any form of raid). I hate to disagree with such an expert DBA (in fact, very much an expert) but...

That's true, you don't need protection from a data retention standpoint for TEMP tablespace(s),

*BUT* you should STILL Raid temp file directories because if your temp drives fail during the day, you've now got downtime.

So, you've no choice but to protect those areas from failure.
We are the people our parents warned us about --Jimmy Buffett
Hein van den Heuvel
Honored Contributor

Re: RAID for Oracle File Systems

>> Is good idea move "archive logs" and "redo logs" to same disk?

No, not in general.
But it is more critical to alternate redo-logs between spindles, than to get the archives out of the way. By alternating you will ensure that the large archive reads will not disturb the current transaction writes.

But if you managed to get away with a single disk for all this time, then there is really no reason to go 'all out' on the re-tune!

For OLTP style applications the redo write speed defines the response time to a large portion.

The data writes, and the archive writes, are not waited on by the end users. The redo write are waited for.

So you don't want anyting to disturb the redo writes for the highest possible speed, but that really only starts to become important for tansaction speeds at 100 tps and above. For lower rates the controller caches will easily keep up, and even a regular disk with no write-back caches can keep up.

Since the archive log writes are done in large blocks it is ok to write that to raid-5 storage. Any self-respecting raid-5 implemenation with optimize full track writes to avoid the reads normally required.

Hope this helps some,
Hein van den Heuvel (at gmail dot com)
HvdH Performance Consulting

Hein van den Heuvel
Honored Contributor

Re: RAID for Oracle File Systems

So if you can get only get a 1 small raid then I would put all my redo there.

But I would pressure the powers that be to get me two of those and alternate say 4 active logs over those two and archive to the larger, existing, raid-5.

Only if I could get still more raid-1 then I would move the archive there, considering it is very high write (typically 50% :-) like the redo but I don't think it is critical at all, because those large sequential writes are normally handled just fine by raid-5.

Still more raid-1?
Maybe for TEMP first and RBS next fro earlier stated reasons.
Not for the long term resiliance but to protect Oracle from shutting down on a single disk error.

hth,
Hein.
Yogeeraj_1
Honored Contributor

Re: RAID for Oracle File Systems

hi again,

Thank you John for disagreeing when i wrote "needs no protection". In fact, what i meant to say was you can use "cheaper" disk for that. Anyway, with Oracle 10g you can create "temporary tablespace groups". By grouping temporary tablespaces within a single group, we enable a user to consume
temporary space from muliple tablespaces.

e.g.
create temporary tablespace LMTEMP1 tempfile '/u01/oracle/datafiles/mydb/lmtemp1_01.dbf' size 50M tablespace group GROUP1;

or if you already have temporary tablespaces:
alter tablespace LMTEMP2 tablespace group GROUP1 ;

SQL> select * from dba_tablespace_groups;

GROUP_NAME TABLESPACE_NAME
------------------------------ ------------------------------
GROUP1 LMTEMP1
GROUP1 LMTEMP2

You can thus have more redundancy in case you encounter any problem with a tempfile.

Note that you can check the temporary tablespace utilisation using the following query:
select username, session_num, tablespace from v$sort_usage;

Hope this helps!

kind regards
yogeeraj
No person was ever honoured for what he received. Honour has been the reward for what he gave (clavin coolidge)