Changing System Passwords in Oracle AI Database 26ai

Two accounts exist in every Oracle AI Database as soon as the database is created: SYS and SYSTEM. Both are Oracle-supplied administrative accounts, and both start out with well-known default passwords if the database was created manually. Anyone who has ever installed Oracle knows those defaults, which means an unchanged SYS or SYSTEM password is not a minor oversight — it is an open door. This lesson covers how to change both passwords correctly, and, just as importantly, why the two accounts do not behave identically when you do it.

Before changing either password, it helps to understand what kind of accounts SYS and SYSTEM actually are. In a multitenant Oracle AI Database, every user account is either a local user, whose identity exists in exactly one pluggable database (PDB), or a common user, whose identity is known across the whole container database (CDB).

SYS and SYSTEM fall into the second category. Per Oracle's Security Guide: "All Oracle-supplied administrative user accounts, such as SYS and SYSTEM, are CDB common users and can navigate across the system container." A CDB common user has a single identity and a single password that is recognized in the CDB root and in every existing and future PDB — not a password scoped to whichever container you happen to be connected to.

The practical consequence for this lesson: when you change the SYS or SYSTEM password, you are not changing a password for "the database you're currently connected to." You are changing it for the entire CDB, root and all PDBs, at once. There is no separate SYS password per PDB to keep track of. This is different from how you might reflexively think about user accounts if you're coming from a single-instance, non-CDB background — and it's worth pausing on, because Oracle AI Database 26ai requires the multitenant architecture for every database, so this behavior is not optional or version-dependent. It's simply how these two accounts work.

SYS and SYSTEM belong to a broader family of predefined administrative accounts that Oracle AI Database creates automatically to manage things like auditing, XML DB, and text indexing. These accounts reside in the CDB root, and most of them are locked and expired by default as a security measure — you, as the DBA, are responsible for unlocking and resetting the ones you actually need.

SYS and SYSTEM are exceptions to the locked-by-default pattern, since the database cannot function administratively without them being usable. That makes their passwords especially sensitive, which is the whole reason this lesson exists.

One standing rule is worth stating plainly here, even though it's about dropping accounts rather than changing passwords: never attempt to drop the SYS or SYSTEM user. Oracle's documentation is direct about the consequence — doing so corrupts your database. Nothing in this lesson involves dropping either account, but since you'll be working closely with both, it's the kind of warning worth having in the back of your mind.

When you create a database manually with the CREATE DATABASE statement, Oracle assigns default passwords to SYS and SYSTEM: CHANGE_ON_INSTALL for SYS and MANAGER for SYSTEM. These defaults have been publicly known for decades — they show up in nearly every Oracle tutorial and reference ever written, this one included. If you provision a database through the Database Configuration Assistant (DBCA) instead of a manual script, you'll typically be prompted to set real passwords for these accounts during creation, so this particular exposure doesn't apply. But manual creation, which is what this module has been walking through, leaves you with the defaults until you change them.

In practice, it's common to leave the default passwords in place temporarily while working through the rest of a database's initial setup tasks, and on a throwaway experimental database, some people never change them at all. That's not a defensible habit for anything beyond a scratch environment. Anyone who knows the defaults — and everyone who has used Oracle for more than a week does — can connect with full administrative privileges to any database still running them. Exactly when you change these passwords during setup matters less than making sure you do it; the sooner you do, the smaller your exposure window.

SYSTEM is the simpler of the two accounts to handle, because its password is changed the same way any ordinary user's password is changed: with the ALTER USER statement and an IDENTIFIED BY clause. There's no password file dependency and no special utility involved.

Connect as SYSDBA and issue:

ALTER USER SYSTEM IDENTIFIED BY new_password;

Replace new_password with a value that meets your organization's password complexity policy. That's the entire procedure for SYSTEM. The reason it's this straightforward, despite SYSTEM being a CDB common user with database-wide reach, is that SYSTEM's authentication doesn't route through the external password file mechanism that SYS depends on — which is exactly the distinction covered next.

SYS is not just another administrative account with elevated privileges — it is the account Oracle itself uses for operations that happen before the database is fully open, including startup, shutdown, and recovery. To support authentication at those moments, SYS credentials can also live in an external password file, separate from the data dictionary. Whether you can use a simple ALTER USER to change the SYS password, or whether you need a dedicated utility instead, depends entirely on how that password file is configured.

The controlling setting is the initialization parameter REMOTE_LOGIN_PASSWORDFILE, which can be set to EXCLUSIVE, SHARED, or NONE. Oracle AI Database sets this to EXCLUSIVE by default, which is also the recommended value. Three methods are available for changing the SYS password, and which ones work depends on that setting.

If REMOTE_LOGIN_PASSWORDFILE is set to EXCLUSIVE, you can change the SYS password from inside the database, the same way you'd change SYSTEM's:

ALTER USER SYS IDENTIFIED BY new_password;

This is the preferred method when it's available, for two reasons: it works entirely from within the database instance, and in an Oracle Data Guard configuration it automatically propagates the password change to the standby instances.

It will not always work, though. If REMOTE_LOGIN_PASSWORDFILE is set to NONE, the statement fails with ORA-01994: Password file missing or disabled. If it's set to SHARED, it fails with ORA-01999: password file cannot be updated in SHARED mode. In either of those cases, you need Method 3 instead.

SQL*Plus also offers a PASSWORD command, which prompts you interactively rather than accepting the new password as visible text:

SQL> PASSWORD SYS
Changing password for SYS
Old password:
New password:
Retype new password:
Password changed

The advantage here matters most for remote connections: PASSWORD never displays the new password on screen, and it encrypts the password in transit over the network. ALTER USER, by contrast, sends the password in clear text as part of the SQL statement — acceptable for a local session that never leaves the machine, but a real exposure over an unencrypted network connection. As a general rule, prefer PASSWORD for anything remote.

When REMOTE_LOGIN_PASSWORDFILE is SHARED, or when it's unset entirely, neither of the above methods will work, and you must use the ORAPWD command-line utility instead. Before you can change the SYS password this way, a password file has to already exist for the account.

To set a new SYS password with ORAPWD, supply the current password file as input, write the result to a (typically identical) output path, and force the overwrite:

orapwd INPUT_FILE=$ORACLE_HOME/dbs/orapw$ORACLE_SID \
       FILE=$ORACLE_HOME/dbs/orapw$ORACLE_SID \
       SYS=Y FORCE=Y
Enter password for SYS: new_password

FORCE=Y is required because the new password file is replacing the existing one in place. If you're also standardizing on a newer password file format, ORAPWD's FORMAT option lets you migrate that at the same time; if you leave it unspecified, ORAPWD defaults to the 12.2 format.

In an Oracle Real Application Clusters (RAC) environment, the standard setup uses a single cluster-wide password file, ideally stored in an ASM disk group so every instance sees the same file automatically. If your password file instead lives on non-shared storage, you're responsible for copying the updated file out to every node in the cluster after making this change — otherwise some instances will still be authenticating against the old password.

Once you've changed both passwords, confirm they took effect by reconnecting with the new credentials:

sqlplus sys/new_password@<TNS_ALIAS> as sysdba

sqlplus system/new_password@<TNS_ALIAS>

If either connection fails, double-check which method you used against the account's requirements above — a failed SYS connection after using ALTER USER is often a sign that REMOTE_LOGIN_PASSWORDFILE wasn't actually set to EXCLUSIVE, and ORAPWD was the method you needed instead.

A few related points worth keeping in mind as you set these passwords:

• Password complexity: whatever values you choose for SYS and SYSTEM should meet your organization's complexity policy, not just Oracle's minimums. These are the two most powerful accounts in the database; treat them accordingly.
• PASSWORD_LIFE_TIME: if the default profile enforces password expiration and you don't want SYS or SYSTEM subject to it, adjust the limit explicitly:

  ALTER PROFILE DEFAULT LIMIT PASSWORD_LIFE_TIME UNLIMITED;

  Use this deliberately, not as a default habit — expiring administrative passwords periodically is generally good practice outside of automated environments that can't handle an unexpected expiry.
• Auditing: password changes on SYS and SYSTEM are exactly the kind of event worth capturing under Oracle Unified Auditing, so you have a record of who changed what and when.
• Never drop these accounts. As covered above, dropping SYS or SYSTEM corrupts the database. Changing their passwords is routine maintenance; dropping them is not a recoverable mistake.

After running CREATE DATABASE for your COIN database earlier in this module, SYS and SYSTEM are still sitting on their default passwords. Connect as SYSDBA and change both now, choosing two passwords of your own — not the examples used in this lesson:

ALTER USER sys IDENTIFIED BY your_sys_password;
ALTER USER system IDENTIFIED BY your_system_password;

Since REMOTE_LOGIN_PASSWORDFILE is set to EXCLUSIVE by default on a newly created Oracle AI Database, ALTER USER should work for both accounts without needing ORAPWD. Confirm you can reconnect with the new SYS and SYSTEM passwords before moving on to the next lesson.