On the back of the recent patching polls I asked a couple of questions about separation of duties.
As always, the sample size is small and my followers have an Oracle bias, so you can decide how representative you think these number are…
Separation of Duties
Here was the first question.
This is exactly what I expected. For the vast majority of companies, the DBAs are responsible for the Grid Infrastructure (GI), Automatic Storage Manager (ASM) and the database (DB).
When Oracle first started floating the idea of separation of duties it kind-of surprised me, as I had never worked with a company that cared about it. Sure they have System Administrators that look after the OS, and maybe provision new disks on the server, but I have never experienced a situation where anyone other than the DBAs do anything with the Oracle side of things.
Don’t get me wrong, if that’s what a company wants to do, it’s good that Oracle make it possible, but I think the vast majority of people just don’t care! What’s more, I think it’s likely to cause more problems than it solves.
GI/DB Ownership
This was the second question, which was suggested by Aishwarya Kala.
It’s interesting that nearly 90% of people have the DBAs doing all the work on the servers, but nearly 50% still split the ownership of the Grid Infrastructure and the database software.
Back in the day nobody talked about separation of duties and the “oracle” OS user owned everything. When discussing separation of duties, Oracle suggested the Grid Infrastructure should be owned by a different OS user, maybe “grid”, and the database carries on as before, typically using the “oracle” OS user. Then the documentation started to push the separation of ownership. Next the installation started to warn you if you used a common user. So now it’s got to the point where people think it is wrong to use a single user as the owner of the GI and database.
I am one of those people that use the “oracle” user as the owner of both the Grid Infrastructure and the database. If you have no separation of duties, I see no point in splitting these between two users. Occasionally I get questions about this in relation to my Vagrant RAC builds, and my response is simple. I don’t work in an environment with separation of duties, so I think splitting the ownership of the GI and database is pointless.
Personally, I think Oracle should remove the warnings from the installer and be more balanced in the documentation. If the poll results of representative of the wider audience, clearly very few people care about separation of duties. It should be an option, not the default assumption.
Cheers
Tim…
Having run into some ‘quirks’ around upgrades and srvctl with split ownership when we’re one team managing it, I’d agree.
I prefer having separate GI (grid), RDBMS (oracle), and OEM Agent (oraoem) accounts. That way when logging into the OS account the appropriate environment is automatically sourced. One container/standalone database instance per VM…no exceptions. The separation somewhat prevents one account from screwing up the other during software patching/installs. (E.g., a mistake or bug during regular OEM agent installation/patching hopefully does not wipe out the critical production database home…)
That said, I do understand wanting to use a single “oracle” account. The separation does create headaches on occasion. Six of one, half a dozen of the other.
In the old days some shops would have 40+ databases on a single bare metal server. In that scenario I’d have a separate ora OS account for each database instance. Trying to fix orphaned chunks of shared memory can be a mess when more than one database shares the “oracle” account…and again, automatically sourcing the appropriate environment when logging into the OS account.