Re: Oracle RPM Question - Please Help Me Answer This Question

From: Jeremy Schneider <jeremy.schneider_at_ardentperf.com>
Date: Fri, 13 Nov 2015 14:11:56 -0600
Message-ID: <CA+fnDAaan3+jaLWuei5zczmrDmT1KM=qhCAL-2bP+EvXR8=JaQ_at_mail.gmail.com>



On Fri, Nov 13, 2015 at 10:09 AM, Michael Cunningham <napacunningham_at_gmail.com> wrote:
> Our admins have explained to the executives that Oracle is their biggest
> technical debt because there is no standard. They feel there should be an
> RPM that is used for the install instead of the normal install process.
>
> Can you please help me provide a response of why Oracle does not have an RPM
> and why it is, or is not, a good idea to create a custom RPM?

Hey Michael -

It is possible to package Oracle binaries in OS packages like RPMs - I've done it in the past for at least one major Oracle customer. Not unheard of and actually I personally like many aspects of this approach.

However it's far more complex of an issue than just throwing the binaries into an RPM package. The biggest problem is that if you really want to use OS package management, then you need to commit to *always* use OS package management or you've caused more problems than you solved. That means (1) you need to come up with your own internal naming scheme and versioning scheme and database to track which RPM contains which combinations of one-off patches and (2) you can never run opatch directly on a server anymore. Otherwise, the output of "rpm -q" actually becomes misleading when you're trying to track what versions of software are installed where.

Any time you need a new one-off patch, you should technically create a new build/rpm and then push that rpm to the server. This process should ideally be automated (one-click rpm builds). The next big challenge becomes size. Every single one of these RPMs will now be multiple GBs. Multi-GB rpms are frankly a little unwieldy and very uncommon.

You'll always be using out-of-place patching in order to retain the integrity of the rpm database. This will significantly increase disk space usage across all of your servers. Frankly, shouldn't be an issue in most modern data centers - but worth noting. Downtime is decreased with out-of-place patching but total deployment time is increased since you need to build a multi-GB rpm and push it to a server rather than a simple in-place (or even online) opatch operation.

Conclusion: you *can* repackage oracle binaries as RPMs. However there are a few important costs to factor in, and IMO these are likely some of the reasons Oracle doesn't use this approach by default.

-Jeremy

--
http://about.me/jeremy_schneider
--
http://www.freelists.org/webpage/oracle-l
Received on Fri Nov 13 2015 - 21:11:56 CET

Original text of this message