Has anyone seen an ORA-16796 (failed to import properties) in DGMGRL? - Data Guard

Hello brain trust,
I have an Oracle 11.1.0.7 primary and have setup an 11.1.0.7 standby. The config is based on our 10g recipe. The broker is up on both sides.
I go into DGMGRL to add the primary, no problem. But when I go to add the standby, I get ORA-16796 (failed to import properties). Digging into the trace logs, it mentions an ORA-01017 (invalid user/password). But I have no problem connecting as "conn sys/password#db_standby as sysdba".
I had this ORA-16796 once before in the distant past, and the problem was that someone had changed the SYS password on the primary without updating the standby's orapwd file. In this case, that is NOT the problem. I have put in a fresh orapwd on both sides (bounced the DBs afterwards), and I explicitly set the SYS password on primary before cloning it to the standby. And again, no problem doing a "CONN sys/****#db_standby as sysdba" from the primary. I can talk to the standby, look at its V$ tables, etc. tnsping, etc. all work fine. listener on both sides shows services. DG broker is up on both sides.
Tried the "shut down broker, delete all config, start db broker, try again" shuffle a few times with no luck.
I'm really scratching my head about what this could be. Opened an SR with Oracle but I'm wondering if anyone here has any other advice?
Has something radically changed from 10g->11g regarding DG? I confess this is our first 11g instance and I'm based its config on what we do for 10g.
Did something change in the security model regarding remote SYSDBA? Again, I have no problem connecting as SYSDBA from the primary so the ORA-01017 really has me confused. 

The config is based on our 10g recipe - Did you copy the password file from the Primary to the standby when you create the standby? 11g has different password file internals and just creating one for the standby with the same password will no longer work.
Larry

Related

ORA-01219 Monitoring physical standby database

Hello all
We are now using our standby database as primary database because of a hardware failure on the primary server. We also recreated the standby database with "duplicate target database for standby dorecover nofilenamecheck". Everything seems to work fine, except that we get lot of Collection Failure errors with "ORA-01219 Database not open" when monitoring our new physical standby database using grid control and sysdba (sys) as credentials. That's right because the db is Mounted, but not opened. Should be disable monitoring of the standby db ? Is there another solution ?
Pierrot 
Try as below
From the standby database Home Page, click on the link "Monitoring Configuration" under "Additional Links"
Change the user to a user with SYSDBA privilege
Select SYSDBA from the Drop Down list for Role.
Complete the configuration steps, test the connection then click OK 
The Monitor Username was already set to SYS, with SYSDBA role. If I change to anything else, the connection fails. On the DB server though, "sqlplus dbsnmp as sysdba" works fine. dbsnmp is used on the primary db for monitoring. 
This behaviour is reported as a bug, see on metalink:
Metric Collection Errors with ORA-1219 for Physical Standby Databases in Grid Control
Doc ID: Note:403223.1
The problem is fixed in agent version 10.2.0.4, a separate patch is also available.
Werner 
I am also facing the same problem with a 10.2.0.3 database . only difference is it used to work before I change the password file. 
As werner mentioned this is a known bug. And a patch is available for agents on all the major platforms.
Note*: Even after the patch is applied there will be alerts until a switchover is done.
So depending on the criticality of your standby environment you can plan it accordingly,
specially for the Production Databases. 
hi ,
I have also thes type problem.
I do not use Data broker but I have physical standby database.my agent listen the database but it gives also ORA-01219 errors.
How can I solve my problem? 
1) Create seperate monitoring templates with different metrics for monitoring Primary and Standby databases.
2) Apply the relevant patch
3) Do a switchover after applying the patch.
4) Apply the appropriate monitoring template after the switchover.

sys password management with Data Guard and RAC

When setting up a standby in 11g, the sys password must match between the primary and standby and the password file must actually be copied from the primary to the standby due to the strong authentication used. This much is fairly well documented in the manuals and support notes.
However, with a RAC primary configuration, apparently you also need to copy the password file from one RAC node to all other RAC nodes.
Looking for feedback of anyone running this configuration. (11g r1, RAC primary, single instance or rac standby, Data Guard Broker)
Are there any implications to RAC when copying the password file ?
Can the password file be copied without bouncing any of the instances?
Thanks. 
The only implication of which I am aware is that not doing it will allow you to waste time trying to debug a well documented issue. 
Hi,
In case of RAC, it is suggested to use the shared password file inplace of password in each node.
There is one metalink note on this also, I will recommend you to use the shared password file in RAC primary.
This way there will no confusion and error related to changing sys password in primary and standby.
Regards
Anudeep

Strange switchover Issue

Good morning all
Hope you guys/gals can help.
I have a strange issue when I switchover my data guard configuration.
I have a primary (prim) and standby (stby) database on separate servers.
When I switchover using dgmgrl from prim to stby everything is happy.
When I switchover from stby to prim and stby restarts the DGB service stops and dgmgrl loses connectivity.
Both servers have a static DGMGRL service set up on the listener and is registered. And it goes from prim to stby without losing connectivity.
I have checked listener drc and alert logs and there are no errors.
Show database verbose on both database's shows a static connect identifier as prim/stby_dgmgrl.
I have set loads of these up and they all work fine. My test kit is also working fine.
In fact this configuration was working fine a couple of weeks ago but now for some reason it has stopped.
Linux admin and networks sit opposite me and both say nothing has changed.
So why when the database restarts and the DGB service go does the dgmgrl loose it's connectivity?
I also have a 2nd standby I was going to add into the configuration which has the same issues but this one is a bit weirder as when the 2nd standby starts up it does not start a DGB service. Although te statics dgmgrl service is there and it exhibits the same switchover pattern as prim and stby. So I can switch from prim to stby2 but going from stby2 to prim loses the connection again.
Although the primary is brought up correctly and all I have to do is startup mount the standby and dgmgrl is all happy and success again.
Any ideas?
I am sure it is something simple but can't see wood for tree.
Sorry if this is a bit garbled. Having to use iPhone as our network can't log into oracle forums at the moment for some reason.
Cheers
Steve 
Steve;
I would double check the listener on both servers. Make sure your _DGMGRL does not have a typo or something else wrong.
If you are using a NET_TIMEOUT make sure it is set to at least 20 seconds.
Any chance you created the broker configuration and later changed the listener ?
This oracle note may also help :
Diagnosing Connection Problems with an active Data Guard Broker Configuration [ID 745201.1]
Best Regards
mseberg 
Thanks mseberg.
Will have a look. Might be a change to the listener. Might strip out the dg config and start again. Will run through the metalink article first.
Am I the only one having trouble with the forums? Just get an oracle holding page on my laptop saying network issues. But it's fine on my iphone

Data Guard - ORA-17627: ORA-01017: invalid username/password

Hi, I have a strange behavior with a Data Guard environment on Linux and Oracle 11.2.0.2. Since a couple of days, I have the following error in the alertlog of the standby database: Errors in file /u00/app/oracle/diag/rdbms/SID_site2/SID/trace/SID_pr0f_22728.trc:ORA-17627: ORA-01017: invalid username/password; logon deniedORA-17629: Cannot connect to the remote database server First I restarted the Apply on the standby without any changes. So I tried to connect to the primary database from the standby server with Oracle .Net with success. In the other way, it's also working.I also tried to copy the password file from the primary server to the standby server and I restarted both the transport and the apply.The error is still happening on the standby but the most surprising is that the Data Guard is still fully synchronized. Why I get that error and what is the function of the process pr0f?How can I resolve that issue?
Hello; Check this thread out: ORA-17629: Cannot connect to the remote database server When in doubt check the password file. Move a copy to the Standby, rename it and restart the database on the new password file. Also make sure this parameter is set like this on both servers :   remote_login_passwordfile='EXCLUSIVE' Best Regards mseberg
process pr0f are only Started Parallel Media Recovery processes
Thanks for your answer.As mentioned, I've already copied the password file from the primary to the standby and then I restarted both transport and apply without success.On both servers I have checked that remote_login_passwordfile is set to 'EXCLUSIVE' I had a look on the other thread but it seems related to RMAN and RMAN is not involved in my case.It's just when apply is started
Ok thanks. Does this mean I have several prXf processes started?Only one is failing because all errors concern pr0f process
Hello again; The password file must be renamed and the database restarted on the new password file. It's not clear if you have done if these pieces, just the apply. Example on mine :    So this /u01/app/oracle/product/11.2.0.3/dbs/orapwPRIMARY   Move here and is renamed as follows :   /u01/app/oracle/product/11.2.0.3/dbs/orapwSTANDBY   Perform the Standby bounce and restart recovery. I would also try a connect as sys from both sides. Best Regards mseberg
The databases have the same name on both servers so there is no need to rename the password file.The password file is located in $ORACLE_HOME/dbs as it should I restarted again the database and restarted apply process but same error again, when the first redo is applied the error happens.I already tried to connect as sys through the network with the password in both ways sqlplus sys#SID_SITE1 as sysdba works well if I use the correct password and does not work with a wrong password.sqlplus sys#SID_SITE1 does not work whatever password I use sqlplus sys#SID_SITE2 as sysdba works normally (with the right password it's fine)sqlplus sys#SID_SITE2 does not work because the database is in mount state
You show this error:  ORA-17627 ORA-01017  invalid username/password  Generally errors like this are fairly clear. I would check my SYS user: SELECT   USERNAME, ACCOUNT_STATUSFROM   DBA_USERSWHERE   USERNAME = 'SYS'; Best Regards mseberg
I agree that the error seems clear but i'm not very sure that I have password issue.The SYS account is not locked on primary SQL> select username, account_status from dba_users where username = 'SYS';  USERNAME                       ACCOUNT_STATUS------------------------------ --------------------------------SYS                            OPEN As already tested I can connect as sysdba on the primary from the standby and the other way is also working.
Hello again; This is key:"As already tested I can connect as sysdba on the primary from the standby and the other way is also working." Because it probably won't bite you later. Generally this are errors seen with RMAN and RMAN duplicate. If they keep occurring I would consider chasing with Oracle support. The connect test from both sides is important. Until you can do that something is not right. Best Regards mseberg 
Hi, Could you please check whether db_unique_name is specified in the log_archive_dest_2 parameter in primary. I had the same sort of problem where primary couldn't connect to the standby but once after specifying db_unique_name, the problem solved.  Thank you!!
Sorry, I did't had much time and as Data Guard is success it is not urgent. I really tested connections in all possible ways.I'm sure that it's not a password issue. I checked the trace file and I have the following strange message:Logged on to standby successfullykrsd_get_primary_connect_string: found pcs 'SID_SITE1' by FAL_SERVER lookupThe standby is trying to connect to the primary database
Hi,     Check the below Bug  in MOS, I found it with the function name "krsd_get_primary_connect_string"    Bug 11809377 : AUTO BLOCK MEDIA RECOVERY IS CAUSING PASSWORD ERRORS ON PHYSICAL STANDBY   It appears you have corrupted blocks in your standby database.RegardsHervé
Hi Hervé, thank you. I found a corrupted block in the standby database with RMAN command validate backup check logical.I disabled the apply and made a block recover. When I restarted the apply the error did't come back. Best Regards, Nicolas

ora-01031 unsufficient privileges when attempting duplicate database

Hello all.... I am having a problem with creating a standby database using the duplicate target from active standby command and am at my wits end.... My environment is linux x86. I've got the listener and tnsnames configured on both servers and can connect to the standby database using the network service from both the primary and standby when it is open and when it is mounted with no problems.  When the standby database is not mounted, I can connect from the command line using sql*plus.  Once in sql*plus, when I try to 'connect sys#<svcname> as sysdba' I get ora-01031 unsufficient privileges.  This results in the same errorwhen I attempt the duplicate command. I know I'm missing something and for the life of me can not figure out what it is.  I don't understand why I'm only having this problem when the standby database is not mounted. Help??? Thanks in advance... Beth
Hi Beth, properly copy password file from the primary to standby DB and rename it. or use orapwd to create password file on standby DB.see http://docs.oracle.com/cd/B19306_01/server.102/b14239/create_ps.htm#i69583and ORACLE-BASE - Data Guard Physical Standby Setup in Oracle Database 11g Release 2 HTHTobi
Beth; Here are my notes: http://www.visi.com/~mseberg/data_guard/standby_creation_from_active_database_using_rman.html Check out step 2 and the "Keys to success" at the very end. This is a great thing to master as you can use it to recreate a standby too. Best Regards mseberg 
Thanks for the response.  I had verified the password file before but will address it again.  I'll let you know. Thanks! Beth
I will look at this.  See my response to mseberg.  I'll let you know. Thanks!
Hi, Well, I checked the password file on both servers and everything looked good.  I verified the user account in v$pwfile_users (sys with sysdba and sysoper).  Everything looked good but just to maintain my sanity, I went aheadand recreated the password file on both servers.  Everything looks good there but I'm still unable to connect as sys when the standby is not mounted. I'm going to start everything from scratch.  It's the only thing I can think of at this point just to make sure everything was done correctly.
Before you fix things that might not be broker can you post the results of this from both databases? show parameter login  Also can you post the value of sqlnet.authentication_services from sqlnet.ora? Best Regards mseberg 
Hi.   Well, I haven't rebuilt anything...  still trying to see the error of my ways... remote_login_passwordfile is set to exclusive on both servers. sqlnet.authentication_services is not set (none) Thanks!
Can you post the locations and names of the password file on both servers? Your other settings I asked about are correct. Best Regards mseberg 
Hi, sorry for the hold up on this reply.  I've been working on other tasks today.  The password file location on both servers is $ORACLE_HOME/dbs.  The name on both servers is orapw<SID>.  The SID is the same on both servers. Thx! Beth
Hi, - Copy password file from primary to standby .- Restart the standby to make sure the new passwordfile read is taking place- Compare the checksums on the passwordfile in the primary and the standby, for example by using the sum command as inhttps://mosemp.us.oracle.com/epmos/faces/ui/km/DocumentDisplay.jspx?id=298986.1Doc ID 298986.1Thanks,Renu

Categories

Resources