Christopher Royce wrote:
>
> Need Input:
>
> I would like to solicit real life experiences, educated opinions, accolades
> and criticisms from those of you who have implemented or are considering
> implementing Oracle on Linux in a business critical production environment.
>
> We are considering both Red Hat and Suse distributions. We have discovered
> that regardless of the Linux distribution .... support is generally
> expensive. That is not a particularly 'deal breaker' determining factor ..
> BUT .. I question the quality of support, the expediency of response and the
> 'sense of urgency' experienced in the event of a critical application being
> down. I am familiar with limited Oracle-Linux implementations but not to the
> 'industrial strength' degree that has been proposed (but already
> implemented) by our requesting user community.
>
> Is there a preferred distribution ???? We already have Red Hat and Suse
> implementations and will choose one of them as the standard .... 'should we
> chose to accept this mission'. I believe that both claim to be the preferred
> distribution by Oracle and that they are 'tier one ports' ????
As for Linux distributions? While Linux is Linux (mostly), you will probably
have fewer problems listening to Oracle's recommendation than trying to "go it
alone" using another distro. The reason I say that is, when Oracle tells you
that "Oracle 8.X or 9.X is certified on RedHat 7.X" they mean that, for the most
part, if you install *THAT* distro of Linux, you should be able to successfully
install Oracle on it.
You shouldn't have to worry about tracking down a specific Kernel version to
patch your particular favorite distro. And, you shouldn't have to worry about
*which* version of the glibc libraries you have to track down and install.
Obviously, newer versions may require you to upgrade those things to be
"certified", but, you shouldn't need to worry so much about them "out the door".
By thw way, my preferred Distro is Mandrake. (Bear in mind that RedHat was [and
may still be] compiled to run on an 80386. Most modern CPU's have additional
features that you have to compile your software to use. Mandrake, on the other
hand, is pre-compiled for a Pentium.) [NOTE: you can always re-compile the
operating system binaries to run on a different type of CPU with either Distro.]
> My initial implementation is Suse 7.2 Enterprise on an IBM NetFinity, 4 cpu,
> 2 Gbyte (memory) server using a Net Appliance Filer. There are six instances
> currently up and running. Thus far there have been no occurrences of
> swapping or i/o bottlenecks .... but then the system has yet to be fully
> 'stressed' and there are scalability concerns. The USER also wants to put
> Oracle 9iAS on the same box - I have managed to delay that for now, pending
> further research. I have had a couple of worrying episodes where a file
> system 'filled up' (on the Filer) that completely 'hung' the system ....
> requiring a full system re-boot. Incidentally the aforementioned NetFinity
> implementation is 'a given' as the six instances have already been migrated
> from an aged and de-commissioned HP system. I have inherited the results and
> there is no going back at this juncture.
Bear in mind that if you are using a NetApp Filer, you are actually using NFS to
access your filesystems. While Oracle's stance on this has changed somewhat
(used to be a "never, but never, do that", now [thanks to much goading by NetApp
and others] it is a 'compatible' solution). In my understanding, the previous
position was taken because not all NFS servers start nfslockd and nfsstatd by
default. Namely, some version of HP/UX. (They were there, and could be
started, but you had to know that you needed them).
Personally, accessing my datafiles (or any other Oracle component) via NFS is
sub-optimal in my book. NFS is a hideously inefficient protocol and an Oracle
Database can create quite a bit of NFS traffic (in the regular world, this would
be just disk I/O). Additionally NFS doesn't necessarily handle some things
quite as "gently" as a local filesystem would. (As you noticed, the
"unavailability" of the filesystem can cause the machine to "hang").
I would recommend investigating several things:
1. Look into your NFS mount options (and any other options you can set
with your NFS client). You may be able to change the NFS client's behavior,
somewhat,
when conditions like a full filesystem occur.
2. Turn off tablespace autoextend. This way, with the exception of archivelogs,
your
chances of "filling up a filesystem" are dramatically decreased. You (as a
DBA) will
actually have to *manage* the growth. (In case you haven't guessed,
"tablespace
autoextend" is a bad feature, in my book).
3. Consider disabling the NetApp's "snapshot" feature. I believe that this is
on
by default. (And, I'm told, allows some nice point-in-time recoverability.
However,
I'm not sure how well this works with Oracle datafiles). If you're not
actively
using this feature, then "changes" will get logged and that will tend to
encroach on
your usable space on the filesystem.
4. As you move towards "production". Consider using a completely PRIVATE LAN
connection
between your Database Server and the NetApp Filer. (Ideally, directly wire
using
crossover cable, the 100BaseT interface on the Filer to a 100BaseT interface
in your
Database server. Have a seperate interface for both devices [db server &
filer] on
the public net for regular access. Run *ALL* of the NFS traffic over the
PRIVATE network). This way, your [relatively inefficient] NFS traffic won't
have
to compete with other traffic and the high amount of traffic generated by NFS
won't
impede your public network. I'd caution against saying "well, we're on a
switched
network anyway" because, regardless, the switch will incur additional workload
handling that NFS traffic. Extra nics and crossover cable are, in the long
run,
cheap.
Unfortunately, NetApp tries very hard to sell their product into the Oracle
space. (sometimes too hard). While their product is amazing at things that NFS
(or an NT "file server") is good for, personally, I'll take locally-attached
disk any day for my Oracle databases.
But hey... When the only tool in your toolbox is a hammer, suddenly everything
starts to look like a nail.
-- James
----------------------------------------------------------------------------
James J. Morrow E-Mail: [EMAIL PROTECTED]
Senior Principal Consultant
Tenure Systems, Inc.
McKinney, TX, USA
"The reasonable man adapts himself to the world: the unreasonable man
persists in trying to adapt the world to himself. Therefore all progress
depends on the unreasonable man." -- George Bernard Shaw
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: James J. Morrow
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
