Tasks that require ROOT for RAC DBA

Question

Our Networking Team and Applications Team are going through some growing pains. We are trying to resolve what permissions should be given to a RAC DBA. Our RAC DBA is responsible for Oracle Clusterware, Oracle Automatic Storage
Management and Oracle RDBMS software. The OS, Server and Storage Subsystem are the responsibility of the System Administrator. We have the following Environment:
Production and Test (RAC)
Oracle Enterprise Linux 5 update 2
Oracle Clusterware 11.2.0.2 -- Grid Infrastructure
Oracle ASM 11.2.0.2
Oracle Database 11.2.0.2 EE
Development (Single Instance)
Oracle Enterprise Linux 5 update 2
Oracle ASM 11.2.0.2 -- Grid Infrastructure
Oracle Database 11.2.0.2 EE
As the RAC DBA, I have identified the following areas that require ROOT for RAC and Single Instance DB's; however, I understand there may be more:
diagcollection.pl
- diagnostic tool for Oracle Clusterware and may be requested by Oracle Support
ocrconfig
- to repair ocr configuration issue (add, replace and remove requires root)
srvctl modify
- required root to change ip address
tar
- TAR Grid Infrastructure Directory structure preserving files with ROOT ownership
cluvfy
- cluvfy fix it scripts need to run as ROOT
- some cluvfy commands under 11gr1 would only run properly for -post cfs check as ROOT in our last installation
ASM Libraries
- ROOT required to install and configure ASM libraries
fdisk - l
- this is used to see disks attached which is relevant when ASM disks are not mounted
/etc/sysconfig/oracleasm
- oracleasm loading configuration file
/usr/sbin/oracleasm
- to make disks available to ASMLIB (scandisks etc.)
/usr/sbin/asmtool
- asm config tool due to bug
asm cluster file system
- some commands require ROOT (mounting etc.)
- acfsutil
/var/log/messages
- loading errors ohas and oracleasm would be logged here
cvuqdisk
- needs to be loaded for new install
root.sh
- script needed to run at install, upgrades and patching
oraInstRoot.sh
- script needed to run at install
rootupgrade.sh
- upgrade script
roothas.pl
- upgrade script
ocrcheck
- check for ocr corruption
- corrupt check portion requires ROOT
- oracle local registry
Grid Infrstructure
- .runInstaller from Grid Infrastructure
- includes upgrades
asm configuration assistant (asmca)
- configuration of asm diskgroups
- vol mgr for asm disks
ocrconfig
- ocr configuration tool
- ocr import
- ocr export
- oracle local registry
ocrdump
- used to check ocr backup file
- oracle local registry
opatch
- patching grid control requires ROOT
crsctl
- Startup and Shutdown Oracle Clusterware, Oracle ASM and Database/Instance
- restore voting disk
- restore ocr
- set log for dynamic debugging
- check install periodically
srvctl
- modify nodeapps (ex. ip address change)
- add filesystem (acfs)
What other items would a RAC DBA need to have ROOT access for?

Answer 1

I'd like to say at the outset that this is a scenario and I am NOT in anyway choosing who does what. A simple -- not so simple -- discussion of roles and responsibilities and associated privileges. If you say that the System Administrator is managing the Grid Infrastructure then this would include all Clusterware and Storage Management (ASM) activities. The System Administrator would manage the OCR and Voting Disks, backups, integrity checks etc. The DBA would then only be responsible for adding the storage within the database itself like assigning tablespaces that reference ASM Disk Groups. This doesn't mean that the DBA can't see the ASM information in the database. The major challenge seems to give your DBA access to the OS, networking and storage tools to preliminarily investigate what they believe to be a OS, networking or storage issue. Without this crossover, your System Administrator may be doing work that is unnecessary. A DBA should have clear understandings of what performance the storage system, cpu, memory and networking should be providing and access to the tools that allow them to understand what side of the fence an issue resides.
There seem to be choices for an organization.
1) Is there a position called RAC DBA or is the RAC portion managed by the System Administrator.
2) If a RAC DBA exists then what should the System Administrator be responsible for
3) What access is need for an existing RAC DBA?
4) How will access privileges be given to the RAC DBA?
5) other considerations regarding security?
I agree that there needs to be crossover regarding handling workload and issues. The agreements on roles and responsibilities shouldn't stop the crossover but they should help in understanding who is ultimately responsible for certain areas of the system and application.
If this isn't happening at organizations then how is it handled? or not handled?