Re: Exadata + OMCS
- From: Seth Miller <sethmiller.sm@xxxxxxxxx>
- To: MARK BRINSMEAD <mark.brinsmead@xxxxxxxxx>
- Date: Wed, 14 Jan 2015 00:20:46 -0600
I wonder what would happen if we started telling our customers that our
service practices are non-negotiable. Oh, that's right, they would promptly
stop giving us money and give someone else money who would be happy to
negotiate.
It's unfortunate so many companies have to put up with nonsense like this.
Certainly, Oracle is not the only culprit. What's worse is that there are
probably dozens of people that work for reputable Oracle partners that have
read this post and would be happy to manage your Exadatas the way you want
them managed and for much, MUCH cheaper.
Mark's point about Platinum Services is a good one but keep in mind that
having Platinum Services does not mean they will patch all of your binaries
and databases. In fact, it is pretty unlikely they will do more than one of
each but of course, that depends on your agreement.
Assuming you have Premier Support and Platinum Services, you can't be more
than one quarterly patch level behind to be on a supported configuration
<http://www.oracle.com/us/support/library/certified-platinum-configs-1652888.pdf>
so I have to wonder if your system is even in compliance if OMCS is, in
fact, maintaining multiple patch levels.
Seth Miller
On Tue, Jan 13, 2015 at 7:01 PM, MARK BRINSMEAD <mark.brinsmead@xxxxxxxxx>
wrote:
> Well, of course, the multitenant features of 12c *are* an extra-cost
> option. (Right?) I doubt you'll be getting that for free just because you
> hired OMCS to manage the databases.
>
> On Exadata in particular its probably not an entirely bad idea to
> provision a separate Oracle_Home for each database, but -- as already
> pointed out -- using separate OS users is not necessary, except for
> security purposes. (People who are *that* security conscious will also
> often insist on independtent OS users for the TNS listener, and for Grid
> Control, and for ... The main idea being that if one of these services is
> compromised -- e.g. by a remotely exploitable bug -- the potential exposure
> is limited.)
>
> From my limited experience with Exadata, I have found that patching is
> extremely important. More often than not, you need to be on the very
> latest patch bundle at all times (with my last Exadata customer, it almost
> seemed that each newly released bundle was always fixing at least one
> critical problem we were encountering in production), however, some
> applications may not respond well to some patches.
>
> If all of your databases are running the same application (at the same
> release level), this probably won't matter a lot. But if I were hosting
> multiple diverse applications on the same Exadata, I would take some
> comfort in the knowledge that patches can be applied -- or rolled back --
> for any database completely independent of any other.
>
> Finicky patching aside, there is probably also some virtue to maintaining
> separate Oracle_Homes for change-control purposes. If you are running
> multiple diverse applications on your Exadata, you probably also have
> multiple diverse user communities. When this is the case, you may find it
> *very* challenging to get all of them to agree on a (any) particular
> maintenance window. I think you may find the hassle-free ability to patch
> Database-A at 3AM on Sunday, and Database-B at 4PM on Tuesday to be quite a
> blessing! There's a good chance that even if you started off with one
> Oracle_Home for all databases, you might well eventually devolve to a
> separate home for each database in a surprisingly short period of time.
>
> Of course, there is a downside. This method means MORE SOFTWARE TO
> PATCH. Of course, if you happen to be paid by the hour (or by the
> Oracle_Home, or even by the task) then this is not necessarily a bad
> thing. I have no idea how OMCS is paid, but there is a small chance that
> the motives behind this are not (quite) entirely without a profit motive.
> Still, the idea of separate Oracle_Homes is (to me, anyway) prudent and
> entirely defensible. The part about distinct OS users is not strictly
> necessary for most organizations, but for OMCS this may make sense, too.
> It allows OMCS to manage everybody's systems the same way, and that adds a
> lot of value -- at least for them. (It probably adds value for the
> customers, too, though. More consistency probably means fewer errors,
> after all.)
>
> ---------
>
> Managing patching on Exadata can be something of a headache, even with
> only one ORACLE_HOME. You might want to consider this when you make plans
> to in-source your database support. It might actually be worthwhile to
> purchase a "Platinum" support agreement, and continue to make patching the
> responsibility of Oracle Support. I think they're still offering that
> service, but I haven't really been keeping up.
>
> On Tue, Jan 13, 2015 at 5:32 PM, Dennis Williams <
> oracledba.williams@xxxxxxxxx> wrote:
>
>> Ironic. For 12c there is the multitenant database feature to allow many
>> organizations to share the same Oracle binaries and memory allocations in
>> security from each other. Obviously OMCS isn't using that feature :-)
>>
>>>
>
Other related posts:
