Database Reference
In-Depth Information
different teams for the management of the Oracle stack. In versions leading up to 12.1, the separation in broad terms
was between the storage team and DBA team: if so desired, separate accounts were used to install and own Grid
Infrastructure and the RDBMS binaries. In addition to the storage aspect, Oracle 12.1 introduced new responsibilities:
backup, Data Guard, and encryption key management.
Similar to previous releases, the responsibilities are implemented using internal groups such as OSDBA to
which operating system groups are mapped. Operating system accounts can then further be mapped to the groups,
inheriting the privileges associated with the role. The mapping between Oracle groups and operating system groups
can be found in Table
5-2
.
Table 5-2.
Internal groups, operating system groups, and users
Internal Group
Description
Typical operating
system group
OSDBA (RDBMS)
Members of the OSDBA group for the database are granted the
SYSDBA privilege. The user can log in using the “/ as sysdba”
command on the server and has full control over the database.
dba
OSOPER (optional)
This is an optional privilege. Members of the OSOPER group for
the database are allowed to connect to the system as SYSOPER.
The SYSOPER role has been used in the past to allow operators to
perform certain tasks such as instance management
(starting/stopping) and backup-related work without the ability
to look at user data. The role is probably superseded by the ones
shown below.
oper
OSBACKUPDBA
Allows members to connect using the new SYSBACKUP
privilege. The new group has been created to allow non-database
administrators to perform backup-related tasks.
backupdba
OSDGDBA
The new SYSDG privilege available to members of this group
allows them to perform Data Guard-related tasks.
dgdba
OSKMDBA
This new group is used for users dealing with encryption key
management such as for Transparent Data Encryption (TDE) and
Oracle wallet.
kmdba
OSASM
Members of the OSASM group are given the SYSASM privilege,
which has taken over from SYSDBA as the most elevated privilege
in ASM. This is quite often assigned to the owner of the Grid
Infrastructure installation.
asmadmin
OSDBA for ASM
Members of the OSDBA have read and write access to files within
ASM. If you are opting for a separate owner of Grid Infrastructure,
then the binary owner must be part of this group. The owner of
the RDBMS binaries must also be included.
asmdba
OSOPER for ASM
(optional)
Similar in nature to the OSOPER group for the database, the
members of this optional group have the rights to perform a
limited set of maintenance commands for the ASM instance.
Members of this group have the SYSOPER role granted.
asmoper
Search WWH ::
Custom Search