topic RAID for Oracle File Systems in Operating System - HP-UX

RAID for Oracle File Systems

Fernando Boza — Thu, 18 Oct 2007 13:26:50 GMT

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?

Re: RAID for Oracle File Systems

John Guster — Thu, 18 Oct 2007 14:09:02 GMT

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.

Re: RAID for Oracle File Systems

Steven E. Protter — Thu, 18 Oct 2007 14:18:40 GMT

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

Re: RAID for Oracle File Systems

TwoProc — Tue, 18 May 2021 12:47:09 GMT

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

Re: RAID for Oracle File Systems

Yogeeraj_1 — Fri, 19 Oct 2007 01:51:02 GMT

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

Re: RAID for Oracle File Systems

Fernando Boza — Fri, 19 Oct 2007 08:30:00 GMT

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?

Re: RAID for Oracle File Systems

TwoProc — Fri, 19 Oct 2007 13:24:10 GMT

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.

Re: RAID for Oracle File Systems

Hein van den Heuvel — Fri, 19 Oct 2007 13:40:29 GMT

>> 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

Re: RAID for Oracle File Systems

Hein van den Heuvel — Fri, 19 Oct 2007 13:51:50 GMT

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.

Re: RAID for Oracle File Systems

Yogeeraj_1 — Sat, 20 Oct 2007 01:00:55 GMT

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

Re: RAID for Oracle File Systems

Yogeeraj_1 — Sat, 20 Oct 2007 01:10:36 GMT

hi again,

If your database is not that big and you can afford a resonable amount of disks, i would recommend that you implement ASM - Automatic Storage Management.

ASM does the redundancy, the disks are arrayed and either inexpensive (think backup area, staging area, dmp area) or expensive (faster disk....) but they are always independent, hence you have RAID. You can have double or triple mirroring of your data with ASM. It uses a mirror and strip (sort of just like RAID 10 -- mirrored stripes)

For more information please read:
http://download-west.oracle.com/docs/cd/B14117_01/server.101/b10743/mgmt_db.htm#sthref2256

E.g. A simple example on how you create a tablespace:
CREATE TABLESPACE PFS_BLOB01
DATAFILE '+DG_DATA01(DATAFILE)'
SIZE 200M
AUTOEXTEND ON NEXT 1M
MAXSIZE UNLIMITED
LOGGING
EXTENT MANAGEMENT LOCAL
UNIFORM SIZE 1024K
SEGMENT SPACE MANAGEMENT AUTO;

Similarly, you have templates for creating for creating any of the following:
PARAMETERFILE
DUMPSET
CONTROLFILE
ARCHIVELOG
ONLINELOG
DATAFILE
DATAGUARDCONFIG
BACKUPSET
AUTOBACKUP
XTRANSPORT
CHANGETRACKING
FLASHBACK
TEMPFILE

Hope this helps too!
kind regards
yogeeraj