the only reason i've ever heard for different OS users would be security - doesn't sound like that applies in your case. also i'm not sure i've ever personally seen a production setup like that. i'm sure it's out there, but i have seen a lot of different environments and didn't come across it (worked with at least a couple dozen different companies in my consulting days and a few really big ones as an employee). strategy for oracle_home and database naming is a little more nuanced. besides the advantages, there are also drawbacks to indicating purpose in the database name. personally i prefer to stay away from that too. likewise with shared oracle_homes, though i think the drawbacks are fewer here and i tend to prefer shared homes. if the buck stops with them when it comes to managing the environments, then they definitely have a strong interest in uniform standards across all the environments they manage. speaking as an ops guy who manages a lot of databases myself, even if the standards aren't perfect it's better if all the systems match to those imperfect standards. i've made a lot of changes to the standards here over time where i am but it's a very slow, carefully managed process. you should keep a list of the issues and discuss them with your management. to the extent that they impact your business, management can discuss it with their counterparts at the managed services organization. -- http://about.me/jeremy_schneider On Tue, Jan 13, 2015 at 3:05 PM, Stephens, Chris <Chris.Stephens@xxxxxxx> wrote: > My employer went big with Oracle engineered systems in the last year and due > to lack of in-house experience, contracted with Oracle Managed Cloud > Services to assist in managing the environment which consists of Exalytics, > Exalogic, Exadata. > > > > I get the impression that it's not common for OMCS to manage systems that > reside in a customer's data centers vs at Oracle data centers but that's > what we have. > > > > At this point, all I care about are the Exadata machines which are currently > just two 1/4 racks. > > > > After recently managing to get some access to the dev/test Exadata machine, > I've discovered that they are doing a number of things which I believe will > become a maintenance nightmare down the road. ...probably about the same time > we bring administration of these machines back in house > > > > Each database (currently 9) is installed under a different OS user under a > unique Oracle home. They claim this is necessary so that each database can > be patched separately and maintained at different versions. I strongly > prefer the default to be all databases reside in a common home under a > common OS user (oracle) with case by case decisions being made to migrate > databases to a new home for legitimate business reasons. > > > > Actually, I would prefer more discretion in the decision to create a new > database for each new application but that's more my company's fault vs > OMCS. > > > > OMCS is also steamrolling us with their database naming conventions which > appear to start with P|D|T followed by my employers initials followed by > random numbers or letters with include upper case O's and zeros. This is > infuriating. They are doing this to make it easier for them to manage our > databases in their environment. These are our databases and we would like > names that give some indication of their purpose. The ending in a number is > a pain in the butt with RAC databases and the letter O vs number 0 is > killing me too. They say this isn't negotiable. > > > > I have several more complaints but I'll refrain from making this too long. > > > > What do you think of these standards? Is there anyone out there that uses > OMCS to manage their Exadata environment? Any comments on how that is > going? > > > > Any comments/input are appreciated. > > > > Chris > > > > > 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. > > -- //www.freelists.org/webpage/oracle-l