Copy Password File from Primary to Standby ASM

 

Recently, while working on an Oracle 19c Data Guard environment, I came across a requirement where the password file from the Primary database needed to be copied to the Standby database. In this environment, the database password file was not located on the normal filesystem. Instead, it was stored inside ASM.

This is a common scenario in Oracle RAC and Data Guard environments where ASM is used for managing database files. For Data Guard to work properly, the SYS password and password file should be consistent between the Primary and Standby databases. If the password file is missing, outdated, or not properly registered in Clusterware, you may face issues with redo transport, managed recovery, or authentication between Primary and Standby.

In this post, I am documenting the steps I followed to copy the password file from Primary ASM to Standby ASM in Oracle 19c.

Environment Details

Primary Database : PROD
Standby Database : PRODSTBY
Primary ASM Diskgroup : +DATA
Standby ASM Diskgroup : +DATA
Temporary Location : /tmp

Please replace the database names and ASM paths according to your own environment.

 

Step 1: Check Password File Location on Primary Database

First, I checked the current password file location registered with Clusterware for the Primary database.

Run the following command as the oracle user on the Primary server:

srvctl config database -d <PRIMARY_DB> | grep -i Password

Example:

srvctl config database -d PROD | grep -i Password

This command shows the password file currently being used by the Primary database. In my case, the password file was located inside ASM, similar to the following:

+DATA/PROD/PASSWORD/pwdPROD.256.798458235

This confirmed that the password file was ASM-managed and needed to be copied using asmcmd.

 

Step 2: Copy Password File from Primary ASM to Filesystem

Since the password file was stored inside ASM, I first copied it from ASM to a temporary filesystem location on the Primary server.

Switch to the grid user:

su – grid

Set the ASM environment:

. oraenv

When prompted, set the Oracle SID as the ASM instance, for example:

+ASM1

Now start asmcmd:

asmcmd

Copy the password file from ASM to /tmp:

ASMCMD> pwcopy +DATA/PROD/PASSWORD/pwdPROD.256.798458235 /tmp/orapwPROD

Exit from asmcmd:

ASMCMD> exit

At this stage, the Primary database password file has been copied from ASM to the local filesystem under /tmp.

You can verify it using:

ls -ltr /tmp/orapwPROD

 

Step 3: Transfer Password File from Primary to Standby Server

After copying the password file to the filesystem, I transferred it to the Standby server using scp.

Run the following command from the Primary server:

scp /tmp/orapwPROD oracle@standby1:/tmp/orapwSTBY

Here:

/tmp/orapwPROD

is the password file copied from Primary ASM, and:

/tmp/orapwSTBY

is the destination file name on the Standby server.

You may use the actual standby hostname or IP address instead of standby1.

 

Step 4: Copy Password File into Standby ASM

Once the password file was available on the Standby server under /tmp, the next step was to copy it into ASM on the Standby side.

Login to the Standby server and switch to the grid user:

su – grid

Set the ASM environment:

. oraenv

Set the Oracle SID as the standby ASM instance, for example:

+ASM1

Start asmcmd:

asmcmd

Copy the password file from /tmp into Standby ASM:

ASMCMD> pwcopy /tmp/orapwSTBY +DATA/PRODSTBY/orapwSTBY

Verify the copied file:

ASMCMD> ls -l +DATA/PRODSTBY/orapwSTBY

Exit from asmcmd:

ASMCMD> exit

At this point, the password file has been successfully placed inside the Standby ASM diskgroup.

 

Step 5: Update Standby Database Resource in Clusterware

Copying the password file into ASM is not enough. The Standby database resource in Clusterware must also be updated so that it points to the correct password file location.

Switch to the oracle user on the Standby server:

su – oracle

Set the Standby database environment:

. oraenv

For example, set:

STANDBY1

Now update the Standby database configuration using srvctl:

srvctl modify database -d PRODSTBY -pwfile +DATA/PRODSTBY/orapwSTBY

After modifying the configuration, verify it:

srvctl config database -d PRODSTBY

You should now see the updated password file location in the Standby database configuration.

 

Step 6: Final Validation

After completing the password file copy and Clusterware update, I performed the following basic checks:

srvctl config database -d PRODSTBY | grep -i Password

Also, if the Standby database is running, verify the Data Guard status:

SELECT database_role, open_mode, protection_mode, switchover_status
FROM v$database;

You can also check managed recovery status:

SELECT process, status, thread#, sequence# FROM v$managed_standby;

If the password file was the cause of authentication or redo transport issues, they should be resolved after copying the correct file and updating the Clusterware configuration.

 

Important Notes

Before replacing or updating the password file, always make sure that the SYS password is consistent between Primary and Standby.

If this is a RAC environment, ensure that the password file is placed in ASM and registered through srvctl, instead of maintaining separate password files on individual nodes.

Also, avoid manually changing the password file location without updating Clusterware, because the database resource may still point to the old password file.