Volume Manager 2.6 and Oracle
2007-12-25 10:51:00
My original post (marked with "|") and the responses (marked with ">")
follow. My responses are the unmarked statements.:
| I have Volume Manager 2.6 with Solaris 2.6 on two UE450s. Both
| these are connected to a StorEdge A5000 which has 5 9gig disks.
| I've setup RAID0+1 as follows:
|
| Disk01 has 300 MB space allocated for redo log volume (vol01),
| rest for striped data volume (vol03).
|
| Disk02 has 300 MB space allocated for redo log volume (vol02),
| rest for striped data volume (vol03).
|
| Disk03 used to mirror vol01, vol03
|
| Disk04 used to mirror vol02, vol03
|
| Disk05 designated spare disk for hot-relocation.
|
| The dba would like to put Oracle 8.0.5 database onto the array.
|
| When setting up the striped volume, I chose not to have
| filesystem created. My questions are:
People seem to think not having a file system will cause me a lot of
inconvenience in the future:
>If you do perform a newfs in the future, you will loose all the
>data. I don't know if there is a way to backup the data from a
>raw partition and replace it to a regular partition, so you will
>be stuck using raw for all future stuff.
>Almost all the unix tools and utilities are designed for regular
>partitions. In talking to other admins, the small performance
>increase, is not worth the hassle of dealing with the raw partitions.
Here's another response:
>The key to this is how you view raw devices. Oracle requires files to
>create tables, etc in, and to this end you would usually (in a file system
>based set-up) provide the path name of the file you were giving the DBA. A
>raw device is simply a 'file' that makes the partition look like a file. So
>you give the DBA the path name of the raw device and he uses this instead
>of the pathname in the file system.
| - If I chose to create a filesystem later, can I just
| "newfs /dev/vx/rdsk/vol3" ?
>Yes, this can be done.
|
| - If I do not want filesystems, how do I tell the Oracle dba
| access the raw device - as "/dev/vx/rdsk/vol3"?
Response:
>yes, or you can set up symlinks for easier to remember names,
>keep in mind though that at boot, the permissions on these
>devices will be reset to default (accessible only by root),
>if you want oracle to be able to access it, change the
>permissions with a startup script. My dba's generally
>prefer filesystems for easier maintenance.
|
| - How will Oracle access the "redo log" I setup (as vol1 and
| vol2, each mirrored separately)? As /dev/vx/dsk/vol1?
Same as above. It has to access separate volumes.
|
| - The dba is going to setup failover with Oracle with this
| setup.
| I was under the assumption that I needed failover software in
| addition to Oracle, since the failover will be across 2
| UE450s. Am I mistaken? Is there anything else I need to do to
| facilitate this?
To do failover, you require parallel oracle, a shared differential
SCSI array and some HA software like Sun Cluster or Veritas FirstWatch.
| - Any thoughts on my setup?
>You might want to check with your DBA as to how the drives
>should be used, the way you have it right now, any activity
>would hit all drives. Granted that you don't have a whole
>lot of options with only 4 drives available.
Our local dba tells me that raw partition performance over regular
filesystems can be as much as 25-50%, and the performance to be gained with
a Veritas filesystem is as much as 100%, with the added bonus of ease of
maintainance.
Other tips:
| What would I need to check with the dba, the percentage of reads vs.
| writes? What should I be looking to minimize?
>You need to avoid i/o contention, there are several data
>streams used by oracle and if you can separate them
>on different drive/controller, you can have better
>performance. It has to be a joint effort between the
>sa and the dba. Generally, dba's want to keep index files
>away from data files because they're used simultaneously.
>Control files have to spread out on different drives
>for reliability, redo log files should be on their own drives
>because they're written sequentially and loop back,
>system temp space need to be separate because of high
>i/o activities... There are a lot more that your dba
>should be able to tell you but what's feasible depends
>on what you have.
| I thought that RAID0+1 is better with databases as compared to
| RAID5s for upto 30% writes (of the total I/O activity).
>true in that regard but i/o contention is a different issue
| If I did have options (we're looking into getting more disks), how
| could I do this differently?
>Again, it has to be worked out with your dba and it has to evolve
>too depending on i/o patterns, both can watch for i/o hot spots
>and try to minimize them. At times you'll have to compromise:
>everyone wants raid1 when they can get it but raid5 may be used
>for low-write data files to reduce cost, ...
My thanks to:
"Arthur J. Byrnes" <abyrnes@stetson.edu>
Special thanks to the following for going back and forth with me to clarify
a couple of things:
Viet_Q_Hoang <vhoang@lucent.com>
Regards,
Rasana
_______________________________________________________________
Get Free Email and Do More On The Web. Visit http://www.msn.com
Comments
Got something to say?
You must be logged in to post a comment.
