Yes, you need to copy the password file from the primary to the standby.
Query v$pwfile_users on both sides before and after the copy and draw your own conclusion ;-)
-Harald

I have two databases in dataguard setup, Oracle 10.2.0.4
I stumbled over your blog when looking for user management in a Data Guard environment.
At the primary side i added a user, and gave it sysdba rights. I was wondering if that user was also created at the secondary site.
Then i read your blog and looked at my passwrd files, in order to copy it from prim to secondary. But they are both with the same timestamp. Do i still need to copy them, i did not change any passwrds?

I like the way you describe the solutions to this password copying. Thanks a lot and hope to see more your article.

Yes, this is a possible solution but the chances of having a shared filesystem in a Data Guard environment are pretty low in my opinion. Especially if one is using Data Guard as a disaster recovery solution, but it might be quite possible if one uses Data Guard in an off-loading scenario. Or maybe there is an ACFS filesystem available with replication enabled. So yes, it is a possible solution, but it would be really nice if Data Guard would propagate password changes from the primary to its standby’s.
-Harald

If you have a shared filesystem, a possible solution might be to put the passwordfile over there and create a softlink in the $ORACLE_HOME/dbs directory. In that way the passwordfile is maintained at one location.

Regards,

Dirk

Thanx for your comment about the workaround you use and the reason behind it. You should not forget to re-create the password file(s) on your standby database(s) after changing the SYS password on the primary.

It is indeed documented that you should copy the password file on 11g while creating a standby database, but it is not documented (as far as I am aware) how to handle password file changes afterwarths. Hence my posting ;-)
-Harald

Since 11g, copying the passwordfile from the primary database to the standby database(s) is Oracle’s recommended and documented way to get an identical passwordfiles on all sites. In previous versions, 10g, the documented way to generate identical passwordfiles on all sites was doing it by orapwd.

Exactly this changed approach (with a reason) caused us some troubles when we updated our scripts to create standby databases including dataguard-configuration in an 11gR2-environment and did not read the documentation carefully enough in advance:
1) Create the standby using active database duplication
Result: All went fine, including configuring/enabling dataguard configuration, because as part of the duplicate Oracle copies the passwordfile to the standby environment.

2) Create the standby using an already existing backup, and generate the passwordfile on the standby via orapwd (the 10g-way)
Result: Adding the standby database to the dataguard configuration failed with “Error: ORA-01031: insufficient privileges”. Messages in the drc**.log pointed us to non-equal passwords for SYS, but they were according testing it with sqlplus. Actually, the passwordfiles were not identical due to the ‘salt’ added to the password when it was hashed as part of the encryption mechanism if case-sensitivity is turned on. And yes, this was the reason you should copy the passwordfile to the standby environment instead of generating it via orapwd.

For us scripting the copying of the passwordfile would mean introducing ssh-keys only for this purpose (not using RAC currently), so we decided to go for one of the two alternatives as described in Note 462219.1 (DATA GUARD LOG SHIPPING FAILS WITH ERROR ORA-16191 IN 11G ):
“Create password files on both servers using the same password and pass ignorecase=Y to orapwd”, to bypass the hashing and generate identical passwordfiles. This works for us, although it is not the most secure solution.

Kind regards,
Saskia

The names I use come from a well-known Dutch children’s TV series.

Good point on the RAC password files. It is basicly the same problem. I don’t think you have to disable case sensitivity as long as you keep them synchronized across all databases in your MAA configuration.
-Harald

I really like your instance names….

I also had some trouble in configuring DataGuard in a MAA environment with RAC primary and Physical Standby because of 11g case-senstive password management.

I made the experience that in 11gR2 the password files of both primary RAC instances need to be identical (copied!) in order to have data guard working. Manual remote connects from primary to standby and vice versa were working fine, but with RFS ist was only working for one RAC Primary Instance. If we copied the orapw file from the nonworking RAC primary to the standby, then they would swap: the connect problem was shifted to the other RAC primary. We then recreated the password file with ignorecase=Y in RAC1, copied it to RAC2 and Standby and from that point onwards, it was working fine.

Best regards,
Martin

If you immediatly copy the updated password file from the primary database to all its standby databases, there is no need to stop redo shipment. This is because the primary is already logged in on the standby databases and it will happily continue shipping redo. If for whatever reason the primary needs to re-login to one ora all of its standby databases this will succeed because the standby databases already have the updated password file.
However, if you don’t copy the updated password file you could be in deep trouble. And yes, if you stop redo shipment to all the standby databases in a maximum protected configuration your primary will fail. SO, just copy the password file after updating it and you are in good shape even in a maximun protection configuration.
-Harald

I don’t think there is anything specific to a Maximum Protection configuration as long as you immediatly copy the updated password file from the primary database to all standby databases.
-Harald