Operating System User and Group permit to allocate privileges.
The documentation talks about logical OS group (OSDBA, OSOPER, OSASM). Their implementation (their creation on the OS level) may be differ in function of:
- the type of installation (single database or grid/asm)
- the type OS (Windows or Linux)
The table below gives the “logical OS Group” by:
- os group for a database installation
|Logical OS Group||Privileges|| Database |
|OSDBA||SYSDBA||Oracle Database - Operating System Group||Oracle Database - Operating System Group|
|OSOPER||SYSOPER||Oracle Database - Operating System Group||Oracle Database - Operating System Group|
|OSASM||SYSASM||Oracle Database - Operating System Group|
The user who belongs to the OS group will get the privileges associated.
The link between OS Group and Logical OS Group is made during the installation.
Job role separation
You can also create custom configuration groups and users based on job role separation. A custom configuration is a configuration with groups and users that divide access privileges granted by membership in separate operating system groups and users. You can create a single user (for example, oracle) to own both Oracle database, and Oracle grid infrastructure installations. Alternatively, you can create a separate user (for example, grid) to own the Oracle grid infrastructure installation.
You can designate a unique group, separate from database administrator groups, or you can use the same group as the OSASM and OSDBA group, to grant system privileges to administer both the ASM instances and Oracle Database instances.
This group identifies operating system user accounts that have database administrative privileges (the SYSDBA privilege).
On Windows: ORA_DBA
The OSDBA group for Automatic Storage Management can be the same group used as the OSDBA group for the database (ie Oracle Database - Operating System Group), or you can create a separate OSDBA group for Automatic Storage Management (typically, asmdba) to provide administrative access to Automatic Storage Management instances.
The Oracle grid infrastructure software owner (typically, grid) must be a member of the OSDBA group. Membership in the OSDBA group allows access to the files managed by Automatic Storage Management. If you have a separate OSDBA group for Automatic Storage Management, then the Oracle Restart software owner must be a member of the OSDBA group for each database and the OSDBA group for Automatic Storage Management.
This is an optional group.
Create this group if you want a separate group of operating system users to have a limited set of database administrative privileges (the SYSOPER privilege). This group cannot directly connect as SYSOPER, unless explicitly granted. However, they will have the privileges granted by the SYSOPER privilege. |
On Windows: ORA_OPER
Create this group if you want a separate group of operating system users to have a limited set of Oracle instance administrative privileges (the SYSOPER for ASM privilege), including starting up and stopping the Oracle ASM instance. By default, members of the OSASM group also have all privileges granted by the SYSOPER for ASM privilege. If you want to have an OSOPER for ASM group, then the grid infrastructure owner must be a member of this group. |
SYSASM privileges for Automatic Storage Management files provide administrator privileges for storage file. In Oracle documentation, the operating system group whose members are granted SYSASM privileges is called the OSASM group, and in command lines, is referred to as asmadmin. Automatic Storage Management can support multiple databases. Members of the OSASM group can use SQL to connect to an Automatic Storage Management instance as SYSASM using operating system authentication. The SYSASM privileges permit mounting and dismounting disk groups, and other storage administration tasks. SYSASM privileges provide no access privileges on an RDBMS instance. If you do not designate a separate group as the OSASM group, then the OSDBA group you define is also by default the OSASM group. |