With all this discussion on "Why RAC?", I thought I'd chime in with our
reasoning, at least as it stands before any testing.

We currently have a few "major" databases for our ERP/MRP system,
Engineering drawings, and "legacy" (I loathe that word) data.  These
databases are spread across three larger systems: Solaris, HP/UX, and
OpenVMS.  They are set up as any three independant systems with their own
disks, own CPUs, own memory, etc.  These relatively expensive systems are
under utilized, and finally, are beginning to show their age (up to six
years old).

By combining these systems under a single system, we will be saving money in
hardware cost (future upgrades and repair) as well as in service contracts,
not to mention the utimate savings -- computer room floorspace!  What I
don't want to do is have the consolidation negatively affect the DBs in
performance or downtime (perceived or real).  So, the idea right now is to
use "commodity" (read: "inexpensive") servers, dual Intel (AMD???) 1Us, with
a SAN, and 9iRAC.

The theory being that while we'll take an initial kick in the fiscal crotch
with the Oracle licensing, since we currently refuse to let go of our
Concurrent User, we'll come out ahead in the long run with the added
performance and unlimited user (per CPU) licensing.  Also, with the
commodity servers, we can switch out the server for faster CPUs without
incurring more licensing cost should the need arise (yes, Cary, I'm well
aware of the "CPU Upgrade Myth"!).

With our testing, I hope to see that we'll be able to provide better uptime
and performance with RAC than the total sum of the current boxes (save for
the uptime on the OpenVMS box, which has 10 minutes of total downtime in the
past 770+ days).

Any comments on this?  In the interest of bandwidth and brevity, I've been
way too brief here.  This should really be discussed over Guinness.

Thx!
Rich


Rich Jesse                        System/Database Administrator
[EMAIL PROTECTED]           Quad/Tech International, Sussex, WI USA
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Jesse, Rich
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
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).

Reply via email to