Date: Tue, 24 Aug 1999 15:12:56 PDT
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Hi all,
I got 4 really good responses after I posted my summary, so I'm posting
their responses in the hopes that it might be useful to someone else.
My thanks to all the 4 respondents!
Rasana
---------
Mark Noel <Mark_Noel@cch.com>
Sorry about the late response, but since you are running 2.6, I
would create a filesystem and mount it using forceio which treats a
filesystem like a raw partition.
-mark
robsonk@ebrd.com
---------
Hi Rasana,
[snip]
>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.
[snip]
I'm not sure if this is correct. The Veritas file system is a
standard journalled file system. The only big difference (which is
also available in latter UFS implementations) is that you can tell the
O/S not to bother with caching. The major reason for using Journalled
file system, is to due recovery time, as the meta-data from the file
system is journalled and therefore can be played back, just the same
as Oracle transactions. If you are using UFS file systems (with
logging from ODS) the journalling will improve recovery time, and can
also improve updates as the meta-information in the file system is
written to a an optimised log file, thereby minimising head movement
and improving I/O. This claim may have been based on the fact that
usually if you are using VXFS you are also using Veritas Volume
Manager, this (hopefully) means that the underlying volumes were in a
RAID 0+1 configuration. Now if this was the situation, imagine the
performance improvement if you ditched the file system and used the
raw meta-devices provided by Veritas Volume Manager, common sense
say's this must be fastest, as there is absolutely no file system
overhead.
If you have Veritas Volume Manager you also have its HA elements, as
well. You can resize your raw partitions, etc, on the fly, it uses
three way mirroring to achieve this (if memory serves me right). So
my recommendation would be to use Veritas Volume Manager, Raw Devices,
a bunch of symlinks and Legato Networker with the Oracle plug-in, but
maybe money is a consideration!
Sorry I would have dealt with Veritas in my previous replies but you
said you already had decided on ODS 2.6 in your original message.
Thanks,
Ken.
----------
"Kris Briscoe" <r8465c@email.sps.mot.com>
There is one major NO NO here:
>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.
You should not mess with the permissions at the fs level. Use the
vxedit command and set the user=<desired user>, group=<group>, perms=<perms>
Whatever values you use there will be place in the config for that
volume. These will be set at boot time. This is the proper and SUN
recommended way of doing the permission/owner changes. This is the
route I took at my client site.
Best of luck,
Kris
-----
"Timothy Lindgren" <Timothy_Lindgren@enron.com>
>To do failover, you require parallel oracle, a shared differential
>SCSI array and some HA software like Sun Cluster or Veritas >FirstWatch.
You can't "failover" raw devices. You can only failover mounted Veritas
Volumes. When a fault is detected (in both Sun and Firstwatch) one of the
first things the system does is export and import the Veritas VM diskgroup,
then remount the volumes to mountpoints, then (try) to bring up the
databases. I would strongly suggest VxFS with the Quick-i/o option. It
provides about a 120% boost in Oracle
performace over UFS, and about 50% more then raw. (Veritas claims 180% but I
have challenged that many times!)
Also, You can failover without parallel server if you are afforded some time
for the failover to occur. WIthout PDB, a failover could take anywhere from
10 to 30 minutes, depending on how indepth you run intergrity checks. PDB is
faster and preferable, but it's not "required".
Tim
_______________________________________________________________
Get Free Email and Do More On The Web. Visit http://www.msn.com
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:13:25 CDT