Re: Oracle on Linux ... Production Strength ???

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: jmorrow_at_warthog.com 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: jmorrow_at_warthog.com

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: ListGuru_at_fatcity.com (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).