RE: Exadata + OMCS
Date: Wed, 14 Jan 2015 09:06:30 -0600
Message-ID: <D95BD5AFADBB0F4E9BB6C53F14D3A0500A8E027A2C_at_JRCEXC1V1.research.na.admworld.com>
I forgot to mention a separate listener for each database as well. I haven’t managed to figure out how that plays into VIPs/Scan for RAC yet. I haven’t managed to get access to a RAC database.
“MORE SOFTWARE TO PATCH”
I guess that is my biggest fear when the default is to create a new database for everything and a new home for every database. Patching is easily my least favorite responsibility in my current role.
From: MARK BRINSMEAD [mailto:mark.brinsmead_at_gmail.com]
Sent: Tuesday, January 13, 2015 7:02 PM
To: oracledba.williams_at_gmail.com
Cc: dmarc-noreply_at_freelists.org; jeremy.schneider_at_ardentperf.com; Stephens, Chris; oracle-l_at_freelists.org
Subject: Re: Exadata + OMCS
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_at_gmail.com<mailto:oracledba.williams_at_gmail.com>> 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 :-)
CONFIDENTIALITY NOTICE:
This message is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by email reply.
--
http://www.freelists.org/webpage/oracle-l
Received on Wed Jan 14 2015 - 16:06:30 CET