Copy Password File From Primary to Standby ASM

 

     If you’ve worked with Oracle Real Application Clusters (RAC) or Data Guard, you know that because the password file lives inside the ASM (Automatic Storage Management) disk group, you can’t simply use a standard ‘cp’ command to move it.

Here is a detailed walkthrough of how I resolved this by extracting, transferring, and re-registering the password file.

 

Challenges 

The password file was locked away inside the ASM disk group on the Primary site (‘+DATA’), and I needed to get it to the Standby site’s ASM disk group. The process involves four distinct stages:

1. Extracting the file from Primary ASM to a local filesystem.
2. Transferring the file to the Standby server.
3. Loading the file from the Standby filesystem into Standby ASM.
4. Registering the new location with Oracle Clusterware.

 

Step 1: Extract the Password File from Primary ASM

First, I needed to identify exactly where the password file was living on the Primary database. I used the `srvctl` command to find the path.

srvctl config database -d <primary_db_name> | grep Password

Once I had the path (e.g., ‘+DATA/PRODDB/PASSWORD/proddbpwd…), I had to switch to the Grid user. This is crucial because the standard Oracle user often doesn’t have direct access to manipulate ASM files via `asmcmd`.

I logged in as ‘grid’, set my environment to the ASM instance, and used ‘pwcopy’ to extract the file to a temporary location on the filesystem (‘/tmp’).

Primary Site:

[oracle@node1 dbs]$su – grid
Password:
[grid@node1 ~]$. oraenv
ORACLE_SID = [grid] ?+ASM1
The Oracle base has been set to /u01/app/grid

[grid@node1 ~]$ asmcmd
ASMCMD> pwcopy +DATA/PRODDB/PASSWORD/proddbpwd.256.867607273 /tmp/oraprodpwd
copying +DATA/PRODDB/PASSWORD/proddbpwd.256.867607273 -> /tmp/oraprodpwd
ASMCMD>exit

 

Step 2: Transfer to the Standby Node

With the file now sitting in ‘/tmp/oraprodpwd‘ on the Primary node, I simply used ‘scp’ (Secure Copy) to move it to the ‘/tmp’ directory of one of the Standby RAC nodes.

Primary Site:

[oracle@node1 dbs]$ scp /tmp/oraprodpwd oracle@node2-standby:/tmp/oraprodpwd_stb

*(Note: I renamed the destination file slightly to avoid confusion, but keeping the name consistent is fine too.)*

 

Step 3: Import the File into Standby ASM

Now, moving to the Standby site. I needed to put this file back into the ASM disk group so the Standby database could use it.

Just like in Step 1, I had to act as the Grid user here. I accessed ‘asmcmd’ and used ‘pwcopy’ again—but this time, I was copying from the filesystem to the ASM disk group.

I made sure to place it in the correct disk group and subdirectory defined by the standby’s db_unique_name (in my case, ‘+DATA/PRODDBSTB’).

Standby Site:

$ su – grid
Password:
[grid@node1 ~]$ . oraenv
ORACLE_SID = [grid] ? +ASM1
The Oracle base has been set to /u01/app/grid

[grid@node1~]$ asmcmd
ASMCMD> pwcopy /tmp/oraprodpwd_stb +DATA/PRODDBSTB/oraprodpwd
copying /tmp/oraprodpwd_stb -> +DATA/PRODDBSTB/oraprodpwd

# Verify the copy
ASMCMD> ls -l +DATA/PRODDBSTB/oraprodpwd
Type Redund Striped Time Sys Name
PASSWORD UNPROT COARSE JAN 11 11:00:00 N oraprodpwd => +DATA/ASM/PASSWORD/pwdasm.279.658236185

 

 

Step 4: Update Clusterware

The file was physically in the right place, but the Oracle Clusterware (GI) didn’t know about it yet. If I didn’t update this, the database might still try to look for the old, missing, or corrupt password file.

I switched back to the Oracle user (the RDBMS software owner) and used ‘srvctl modify database’ to point the configuration to the new password file location.

Standby Site:

$ su – oracle
Password:
[oracle@node1~]$ . oraenv
ORACLE_SID = [oracle] ? proddb

# Point Clusterware to the new password file
[oracle@node1~]$ srvctl modify database -d proddbstb -pwfile +DATA/PRODDBSTB/oraprodpwd

# Final Verification
[oracle@node1~]$ srvctl config database -d proddbstb
…
Database unique name: proddbstb
Password file: +DATA/PRODDBSTB/oraprodpwd
…
Database role: PHYSICAL_STANDBY

 

Conclusion

After updating the Clusterware configuration, my Standby database was able to authenticate correctly with the Primary, and log shipping/apply resumed without issues.

The key takeaway here is remembering that ASM files are opaque to the OS, you must use the ‘asmcmd’ tool as the Grid user to bridge the gap between the filesystem and the disk groups.