It appears the issue is resolved. Oracle support recommended deleting and re-adding the standby from the data guard screen in Enterprise Manager. I did that, and at first the issue appeared resolved. Soon, however, a new error, ORA-16778 began to appear. After a bit of tail-chasing, I realized that the Data Guard process had re-added the log transport service to the initialization parameters, creating a duplicate of the one I had already added. Removing the entry that I had created and leaving the DG added one has the problem in remission. Thanks for looking.
Oracles documentation states:
ORA-01041: internal error. hostdef extension doesn't exist
Cause: Pointer to hstdef extension in hstdef is null.
Action: Report as a bug
So, if you have support from them, I'd suggest that you contact them. Digging into errors in Oracle can really drive you mad sometimes.
But from what I have understood the error have to do with the connection between the databases (or the database and the client), so there are a few things you can check.
First of all, it could be that simple that the files just doesn't exists.
So verify that these files exists (and can be read by the database):
/home/u01/app/oracle/oradata/orcl/system01.dbf
/home/u01/app/oracle/oradata/orcl/sysaux01.dbf
Also verify that the ORACLE_HOME is set correctly, and that the tnsnames.ora contains the definition to both of the databases (it should since you are connected to both of them, but better verify it), and also check if you're using a different tnsnames than the database.
The listener could be a problem as well, perhaps the stdby never gets registered there, you can try to add it manually in the listener file instead of letting it register itself.
I have also had problems if the hostname used doesn't exist in the /etc/hosts file, even if using a dns, so that is something you could try as well.
If it still doesn't help. have a look in the alert log and trace files, perhaps they provide more information of the problem.
That's all the ideas I've got, hope it helps you a bit at least.
Update:
hmm, after checking a bit more, it looks to me that one issue could be that you actually don't specify the location of the db-files.
Try to add:
set db_file_name_convert='/home/u01/app/oracle/oradata/orcl/',
'/home/u01/app/oracle/oradata/stdby/'
after the spfile statement
You might also want to add parameter_value_convert 'orcl','stdby' not sure if it is neccessary, but it looks like it could be a good idea.
Best Answer
Physical Standby is typically DRP-oriented. Its main advantages are:
In 11g, you can easily utilize it for testing (snapshot standby). Also, if you license Active Data Guard option, you can use it for near real time reporting (under some limitations - the standby is readonly, but some workarounds are available - see Apendix B in the best practices paper). Active Data Guard also allows you to perform fast incremental backups on the DR site instead of the primary
Logical Standby was typically used to enable reporting on a standby. Its main advantages are:
So, for pure DRP, use physical. If you need read only access, decide based on these features. For example, check data type support, see if you need the faster apply performance, see if you are willing to license Active Data Guard (and upgrade to 11g if you are not there) etc.