Password Files   «Prev  Next»

Lesson 1

Oracle Password File Management (orapwd, SYSDBA, and SYSOPER Explained)

This module is about Oracle password files. Password files provide a mechanism for authenticating database administrators who connect remotely over a network. Without a password file, Oracle cannot verify the identity of a DBA attempting to connect with SYSDBA or SYSOPER privileges through Oracle Net Services — the connection is rejected before it reaches the database.

When you have completed this module, you should be able to do the following:
  1. Create a new password file using the orapwd utility
  2. Connect to a database as SYSDBA or SYSOPER
  3. Grant SYSDBA and SYSOPER privileges to DBAs
  4. Configure a database to use a password file using REMOTE_LOGIN_PASSWORDFILE
  5. Rebuild a password file when it is corrupted or lost
  6. Select from V$PWFILE_USERS to see who has SYSDBA or SYSOPER privileges
  7. Grant SYSBACKUP privileges for RMAN backup operations (Oracle 12c+)
  8. Grant SYSDG privileges for Oracle Data Guard operations (Oracle 12c+)
  9. Grant SYSKM privileges for Transparent Data Encryption key management (Oracle 12c+)
  10. Grant SYSRAC privileges for Oracle RAC cluster operations (Oracle 12c+)
Password files play an important role in database security, especially when you are using tools such as Oracle Enterprise Manager Cloud Control to remotely manage a database over a network. This module covers password file creation, privilege management, error diagnosis, and the shared password file architecture introduced in Oracle 12.2 for Real Application Clusters environments.

What Is an Oracle Password File

An Oracle password file is a binary file stored on the database server that contains the encrypted credentials of users who have been granted SYSDBA or SYSOPER administrative privileges. It exists independently of the data dictionary — which means Oracle can authenticate these privileged users even when the database is not open, such as during startup, shutdown, or recovery operations when the data dictionary is unavailable.

This independence from the data dictionary is the defining characteristic of password file authentication. A DBA connecting as SYSDBA to start a closed database cannot be authenticated against the data dictionary because the data dictionary lives inside the database being started. The password file provides the authentication mechanism for exactly this scenario.

Password File Location by Platform

The default password file location depends on the operating system and Oracle version:
  • Linux and Unix: $ORACLE_HOME/dbs/orapw<SID> — for example, /u01/app/oracle/product/19.0.0/dbhome_1/dbs/orapwORCL
  • Windows: %ORACLE_HOME%\database\PWD<SID>.ora — for example, C:\app\oracle\product\19.0.0\dbhome_1\database\PWDORCL.ora
  • Oracle 12.2+ with ASM: The password file can be stored in an Oracle ASM disk group, enabling a single shared password file for all nodes in a Real Application Clusters environment. The ASM path takes the form +DATA/orapwORCL.
In Oracle 23ai, the password file remains supported in all three locations. The location is also configurable through the db_files and ASM configuration parameters when deploying on Oracle Cloud Infrastructure.

The REMOTE_LOGIN_PASSWORDFILE Initialization Parameter

The REMOTE_LOGIN_PASSWORDFILE initialization parameter controls how Oracle uses the password file. It accepts three values:
  • NONE — Oracle ignores any password file. Remote privileged connections are not permitted. Attempting to grant SYSDBA with this setting produces ORA-01994.
  • EXCLUSIVE — The password file is used exclusively by one database. Multiple users can be listed in the password file. This is the correct setting for most single-instance databases and for the primary database in a Data Guard configuration.
  • SHARED — The password file can be shared by multiple databases. Only the SYS password is stored. This value is deprecated in Oracle 12c in favor of the ASM-based shared password file approach.
To check the current setting:
SHOW PARAMETER REMOTE_LOGIN_PASSWORDFILE;
To set it in the SPFILE:
ALTER SYSTEM SET REMOTE_LOGIN_PASSWORDFILE = EXCLUSIVE SCOPE = SPFILE;
A restart is required for the parameter change to take effect. The recommended setting for a single-instance production database is EXCLUSIVE.

Oracle Managed Files (OMF) — Brief Context

Oracle Managed Files (OMF) simplifies database file management by having Oracle handle all operating system operations and file naming automatically. While OMF is primarily a database file management feature rather than a password file feature, it is relevant to this module because password files created using OMF conventions benefit from the same automatic lifecycle management. Key advantages of OMF include:
  1. Automatic cleanup of the filesystem when database objects such as tablespaces and redo log members are dropped.
  2. Standardized, Oracle-controlled naming of database files, eliminating the need for DBAs to manage file naming conventions manually.
OMF is configured using the DB_CREATE_FILE_DEST initialization parameter and is fully compatible with Oracle ASM. The remainder of this module focuses on password file creation and privilege management.

Creating a Password File with orapwd

The orapwd command-line utility creates the Oracle password file and sets the initial password for the SYS user. It must be run from the operating system command prompt — not from within SQL*Plus — by a user with appropriate OS-level permissions, typically the oracle OS user on Linux or a member of the ORA_DBA Windows group.

By default, the user SYS is the only user that has SYSDBA and SYSOPER privileges stored in the password file. Creating a password file by means of orapwd enables remote users to connect with administrative privileges through Oracle Net Services (formerly known as SQL*Net in Oracle 7 and 8 environments).

Warning: Using orapwd and granting SYSDBA gives other users Oracle superuser privileges. The SYSDBA privilege provides unrestricted access to every object in every schema, the ability to start and stop the database, and the ability to perform all recovery operations. Grant it only to users who require full DBA authority.

orapwd Syntax and Parameters

The modernized syntax for Oracle 19c and later:
orapwd FILE=$ORACLE_HOME/dbs/orapwORCL \
       PASSWORD=<sys_password> \
       ENTRIES=10 \
       FORMAT=12
Key parameters:
  • FILE — the full path and filename of the password file to create.
  • PASSWORD — the password for the SYS user. In Oracle 19c+, this must meet the password complexity requirements defined by the database profile.
  • ENTRIES — the maximum number of privileged users the password file can contain. In Oracle 12c+, this parameter is largely advisory — the password file grows dynamically — but it sets the initial allocation.
  • FORMAT — specifies the password file format. FORMAT=12 is required for case-sensitive password support and for storing the additional Oracle 12c+ administrative privileges (SYSBACKUP, SYSDG, SYSKM, SYSRAC). The legacy format 11 does not support these privileges.
On Windows, replace the forward slash with a backslash and use the Windows path convention:
orapwd FILE=%ORACLE_HOME%\database\PWDORCL.ora PASSWORD=<sys_password> ENTRIES=10 FORMAT=12

Case-Sensitive Passwords and FORMAT=12

Prior to Oracle 12c, Oracle passwords were stored and compared in a case-insensitive manner — the password Tiger was treated identically to TIGER. From Oracle 12c onward, SEC_CASE_SENSITIVE_LOGON=TRUE is the default, and passwords are case-sensitive. The password file format must match this security posture.

Using FORMAT=12 when running orapwd creates a password file that stores case-sensitive hashed credentials. If you create a password file with the legacy format on an Oracle 19c or 23ai database, privileged users may be unable to authenticate remotely because the stored hash does not match the case-sensitive credential they provide. Always use FORMAT=12 on Oracle 12c and later databases.

Administrative Privileges — SYSDBA and SYSOPER

Oracle provides two traditional administrative privilege levels and four additional specialized administrative privileges introduced in Oracle 12c. All are stored in the password file when REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE.

SYSDBA Privileges

The SYSDBA privilege is the highest level of database authority. It was previously granted by connecting as CONNECT INTERNAL in Oracle 7 and 8 — that syntax was deprecated in Oracle 9i and removed in Oracle 10g. All operations that previously required CONNECT INTERNAL are now performed by connecting as / AS SYSDBA.

SYSDBA provides:
  • Database startup and shutdown
  • CREATE DATABASE
  • ARCHIVELOG and NOARCHIVELOG mode changes
  • All RMAN backup and recovery operations
  • Unrestricted access to all data in all schemas
  • CREATE SPFILE
  • ALTER DATABASE OPEN, MOUNT, RESETLOGS, and FLASHBACK
When a user connects as SYSDBA, they connect into the SYS schema regardless of their own schema.

SYSOPER Privileges

The SYSOPER privilege allows a DBA to perform general database maintenance operations without the ability to view user data. This makes it appropriate for operators who need to start and stop the database or perform routine maintenance but should not have access to sensitive business data stored in user schemas.

SYSOPER provides:
  • Database startup and shutdown
  • ALTER DATABASE OPEN, MOUNT, BACKUP, and ARCHIVELOG
  • CREATE SPFILE
  • RESTRICTED SESSION
  • Recovery operations that do not require looking at user data
When a user connects as SYSOPER, they connect into the PUBLIC schema — not SYS — preventing access to the SYS-owned data dictionary tables.

Oracle 12c+ Administrative Privileges

Oracle 12c introduced four targeted administrative privileges that follow the principle of least privilege — granting only the authority needed for a specific administrative role rather than full SYSDBA access:
  • SYSBACKUP — grants the authority to perform RMAN backup and recovery operations. A backup operator can connect as SYSBACKUP and run all RMAN commands without having SYSDBA access to user data.
  • SYSDG — grants the authority to perform Oracle Data Guard operations including switchover, failover, and log transport management. The Oracle Data Guard Broker uses SYSDG for its administrative connections.
  • SYSKM — grants the authority to manage Transparent Data Encryption (TDE) keystores and master encryption keys. Separating key management authority from SYSDBA supports compliance requirements where the encryption key administrator must be distinct from the database administrator.
  • SYSRAC — grants the authority to perform Oracle Real Application Clusters management operations including instance registration and cluster interconnect configuration.
All four require FORMAT=12 in the password file. They are granted using the same GRANT syntax as SYSDBA and SYSOPER.

Granting Administrative Privileges

Granting SYSDBA and SYSOPER

Once the password file exists and REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE is set, you can grant SYSDBA and SYSOPER to database users. These grants must be issued by a user already connected as SYSDBA:
-- Grant SYSDBA to a DBA user
GRANT SYSDBA TO dba_user;

-- Grant SYSOPER to an operator user
GRANT SYSOPER TO ops_user;

-- Grant Oracle 12c+ targeted privileges
GRANT SYSBACKUP TO backup_operator;
GRANT SYSDG     TO dataguard_admin;
GRANT SYSKM     TO encryption_admin;
Each grant adds the user's credentials to the password file. The entries count set when orapwd was run controls the initial capacity, but in Oracle 12c+ the file grows dynamically as additional users are granted privileged access.

Viewing Privileged Users with V$PWFILE_USERS

The dynamic performance view V$PWFILE_USERS shows all users whose credentials are stored in the password file. It is valid in Oracle 19c, 21c, and 23ai. Query it as SYSDBA to audit which accounts hold administrative privileges:
SELECT USERNAME,
       SYSDBA,
       SYSOPER,
       SYSASM,
       SYSBACKUP,
       SYSDG,
       SYSKM,
       SYSRAC
FROM   V$PWFILE_USERS
ORDER  BY USERNAME;
Each column returns TRUE or FALSE indicating whether the user holds that specific privilege. SYS will always appear with SYSDBA=TRUE. Users granted SYSBACKUP or SYSDG will show TRUE in those columns only if the password file was created with FORMAT=12.

ORA-01994 — GRANT Failed

The most common error encountered when setting up password file authentication is ORA-01994. It occurs when orapwd has not yet been executed or when REMOTE_LOGIN_PASSWORDFILE is set to NONE:
SQL> GRANT SYSDBA TO scott;

ORA-01994: GRANT failed: cannot add users to public password file

Root Cause — REMOTE_LOGIN_PASSWORDFILE Misconfiguration

The specific root cause of ORA-01994 in the context of this module is that REMOTE_LOGIN_PASSWORDFILE is not set to EXCLUSIVE. Verify the current setting first:
SHOW PARAMETER REMOTE_LOGIN_PASSWORDFILE;
If the value is NONE or SHARED, or if no password file exists at the expected location, the GRANT SYSDBA statement will fail with ORA-01994.

Diagnosis and Resolution

The general causes of ORA-01994 and their resolution steps in order of likelihood:
  1. Password file does not exist: Run orapwd to create the password file at the correct location for your platform. Verify the file exists before attempting the grant.
  2. REMOTE_LOGIN_PASSWORDFILE=NONE: Change the parameter to EXCLUSIVE in the SPFILE and restart the database instance.
  3. Insufficient privileges: The user issuing the GRANT SYSDBA statement must themselves be connected as SYSDBA. A user with the standard DBA role cannot grant SYSDBA.
  4. Syntax errors: Review the GRANT statement. The correct syntax is GRANT SYSDBA TO <username> — not GRANT SYSDBA ON or other variations.
  5. Target user does not exist: Verify the grantee username exists in the database using SELECT USERNAME FROM DBA_USERS WHERE USERNAME = '<name>'.
  6. Password file format mismatch: If you are granting SYSBACKUP, SYSDG, SYSKM, or SYSRAC and receiving ORA-01994, the password file may have been created with the legacy format. Recreate it using FORMAT=12.
  7. Role hierarchy issues: Roles cannot be granted SYSDBA or SYSOPER — these privileges can only be granted directly to individual users. Attempting to grant them to a role produces ORA-01994.
  8. Resource limitations: In older Oracle versions, if the password file was created with a low ENTRIES value and that limit has been reached, ORA-01994 may occur. Recreate the password file with a higher ENTRIES value or rely on Oracle 12c+ dynamic growth behavior.
After resolving the root cause, review the Oracle alert log for additional diagnostic messages. Oracle logs all privilege grant failures with contextual information that supplements the error code:
-- View the alert log location
SELECT VALUE FROM V$DIAG_INFO WHERE NAME = 'Diag Trace';

Shared Password Files in Oracle RAC (12.2+)

In Oracle Real Application Clusters environments prior to Oracle 12.2, each node maintained its own copy of the password file. Keeping these files synchronized across nodes was a manual administrative task — if the files fell out of sync, privileged connections would succeed on some nodes and fail on others.

Oracle 12.2 introduced support for storing the password file in an Oracle ASM disk group, making it a single shared file accessible by all RAC nodes through the ASM infrastructure. The shared password file eliminates the synchronization problem entirely — any change to a privileged user's credentials or any new grant of SYSDBA is immediately visible across all nodes.

To migrate an existing password file to ASM:
-- Copy the existing password file to ASM using ASMCMD
ASMCMD> pwcopy --asm /u01/app/oracle/product/19.0.0/dbhome_1/dbs/orapwORCL +DATA/orapwORCL

-- Update the initialization parameter to reference the ASM location
ALTER SYSTEM SET REMOTE_LOGIN_PASSWORDFILE = EXCLUSIVE SCOPE = SPFILE;
The ASM-based shared password file requires FORMAT=12 and is the recommended configuration for all new Oracle RAC deployments on Oracle 12.2 and later, including Oracle 19c and 23ai.

In the next lesson, you will learn how to create a new Oracle password file using orapwd and configure the REMOTE_LOGIN_PASSWORDFILE parameter to enable privileged remote connections.
SEMrush Software 1 SEMrush Banner 1