Re: Raw partitions on HPUX 10 and Oracle 7.3.2

Bolen Coogler wrote:
>
> Marvin Suther <marvin_suther_at_jhuapl.edu> wrote:
>
> >We are in the process of setting up Oracle 7.3.2 on an HP 9000 Model 821
> >running HP-UX 10.2. We are trying to figure out any
> >advantages/disadvantages as to the use of raw partitions. Are there any
> >whitepapers that deal with this? Any experineces, either good or bad? You
> >can email me at marvin_suther_at_jhuapl.edu.
 

> >Thanks.
>
> I have seen an aging white paper that basicly slams the use of raw
> partitions, except when you can demonstrate your database is I/O
> bound. I disagree with it. I think most of its arguments against raw
> partitions are outdated. It was written without consideration of LVM,
> or backup products that make backing up a raw logical volume as easy
> as backing up a file system. Plus, if you first build your database
> using filesystems, think how much more trouble it will be to later
> convert a production database to raw LV's, than to build it raw in the
> first place. Why wait until you ARE I/O bound just to prove a point?
>
> Advantages:
> 1. Faster I/O performance (although some argue the improvement is
> marginal).
> 2. You can implement dbwr async I/O (the asyncdsk kernel driver).
> 3. Some Oracle options (Parallel Server) require raw.
>
> To me, the biggest advantage is #2 above. Sure, you can run multiple
> dbwr's, but using real async I/O is more efficient than simulating it.
>
> Disadvantages:
> 1. Using raw logical volumes does require close cooperation from
> your system administrator. Therefore, you will probably need to do a
> little more up front planning (not a bad thing, IMHO). In my case, I
> began life in the UNIX world as a UNIX system administrator before I
> became an Oracle DBA. I've got root access whenever I need it. So,
> as long as I don't get into an argument with myself.... :-)
>
> I have built all of our databases on HP systems exclusively using raw
> partitions via LVM (except for the control files and init<sid>.ora of
> course!). We've had no trouble at all going "raw". LVM eliminates
> the raw partition management headaches.
>
> 2. BEFORE you go raw, you will definitely need a good backup
> product (like Omniback) that can backup raw LV's. Otherwise, the only
> native UNIX method of copying a raw partition is "dd". You do NOT
> want to use dd to backup your database.
>
> Other thoughts on raw logical volumes....
>
> On systems running HPUX 10.xx, I create, where possible, volume groups
> with 8 drives each across as many controllers as possible (8 would be
> ideal). Then I create the logical volumes striped across all 8
> devices. Note that the order in which you name your devices in the
> vgcreate command has a direct impact on logical volume striping. Part
> of that planning in advance.
>
> Don't let HPUX name your LV's for you, or you'll have creative names
> like lvol1, lvol2, lvol3, etc. My convention is to use a pattern of
> <sid name>_<tblspace name><number>. For example, if I have a database
> sid of "demo", the system tablespace LV name will be "demo_system01".
> You will need to reference the LV via the character device name. So
> if this LV is in a VG named "vgora01", the full path name will be
> '/dev/vgora01/rdemo_system01'.
>
> You will need to change the ownership of the character devices names
> to oracle. After I create all the LV's, I can change ownership with a
> single command, e.g. # chown oracle:dba /dev/vgora*/rdemo_*
>
> The maximum size you can define your datafile is the LV size minus 1
> db_block. For example, if you use 8K db block size, and you create
> the demo_system01 LV at 64M, then (64*1024-8 = 65528). Thus:
> create database demo
> .....
> datafile '/dev/vgora01/rdemo_system01' size 65528k reuse;
>
> ---
> Bolen Coogler
> DBA, BellSouth Information Systems

-- 
All good stuff.  No Proof.  Just blind assertions - real scientists these folks.

contact gil asherie at quest software - his partner 
Eyal Aronoff has the proof.  gil_at_quests.com


______________________________________________________________________________
Michael J. Hillanbrand II                                        Dulcian, Inc.
                          Oracle Data Base Administration
Voice: 215-773-7307                                     Fax:    610-277-2966
                              mailto://mjhii_at_erols.com  
Delaware Valley Oracle Users Group              http://www.oug.com/OUG/DEVOUG/
SALTS A104, U.S. Naval Reserve     http://www_salts.icpphil.navy.mil/reserves/