After several weeks of testing, I am finally ready to update this thread again. Below are my findings:Physical Standby databases are, by very nature according to Oracle, read-only databases that are exact copies of their respective primary databases. They receive information via Oracle's Redo Apply (or optionally, Real Time Apply) log shipping mechanism at the block level and are always started in Mount mode. I have found them to be very robust; edits to geometric networks, compress operations, and rec & post operations all make it over to the standby when performed on the primary, as expected. After switching over to the standby, the same behavior occurs the other way just as well. In other words, transactions (all DDL and DML) are shipped the other way since switching over results in the primary and standby swapping roles. I have been able to perform versioned editing without issue on both sides only to find that the standby redo logs are shipped and applied without issue on the opposite side. If you want to verify that the STATES, VERSIONS, and STATE_LINEAGES tables (or any others for that matter) in the standby show the same information as the primary, you can query the standby the standby using a non-Esri application such as SQL*plus, DB Artisan, or SQL Developer. Just make sure that Real-Time SQL (not the same as the aforementioned "Real Time Apply") is enabled on the primary database (offered at 11g and later); it then allows read-only connections. As far as I can see, Physical Standby databases do NOT allow connections from an ArcGIS client because connecting with an ArcGIS client is actually NOT a read-only connection. When an ArcGIS client connects, there are write operations that occur by default... it's just how the software works. To connect to the physical standby, you MUST perform a switchover or failover which will change the role of the standby to become primary; thus starting it up in read-write mode. Logical Standby databases are inherently different; they use Oracle's SQL Apply log shipping mechanism and are always started in read-write mode. However, there are major issues with these databases when it comes to storing and accessing GEOdatabases. Despite logical standby databases being "editable", they only allow DML changes, not DDL. While it is one thing to replicate changes from primary to standby, it is another thing to replicate complex changes and it is yet another thing to allow ArcGIS client connections to the standby. ArcGIS clients instantiate DDL when connecting with the database, so logical standby databases will yield an error; in other words, they write values to the database and they apply schema changes upon connecting. To get around this, there are 24 exclusions that need to be inputted into the logical standby database before an ArcGIS client can connect. Those are listed below. When setting up a logical standby via Oracle Enterprise Manager (OEM) / Cloud Control, you are notified that certain objects in the database are not supported for replication with logical standby databases. That is why exclusions like these need to be made; otherwise replication won't just "not work for some objects", it will actually break entirely and the standby redo logs won't get applied to the standby whatsoever. (Note: the exclusions below can be run as the SYS user and have been tested against 10.2.1 geodatabases using the SDELOB spatial data type):EXECUTE DBMS_LOGSTDBY.SKIP(stmt => 'SCHEMA_DDL', -
schema_name => '%', -
object_name => 'SDE_LOGFILES');
EXECUTE DBMS_LOGSTDBY.SKIP(stmt => 'SCHEMA_DDL', -
schema_name => '%', -
object_name => 'SDE_LOGFILE_DATA');
EXECUTE DBMS_LOGSTDBY.SKIP(stmt => 'SCHEMA_DDL', -
schema_name => '%', -
object_name => 'SDE_EXCEPTIONS');
EXECUTE DBMS_LOGSTDBY.SKIP(stmt => 'SCHEMA_DDL', -
schema_name => 'SDE', -
object_name => 'PROCESS_INFORMATION');
EXECUTE DBMS_LOGSTDBY.SKIP(stmt => 'DML', -
schema_name => 'SDE', -
object_name => 'PROCESS_INFORMATION');
EXECUTE DBMS_LOGSTDBY.SKIP(stmt => 'SCHEMA_DDL', -
schema_name => 'SDE', -
object_name => 'OBJECT_LOCKS');
EXECUTE DBMS_LOGSTDBY.SKIP(stmt => 'DML', -
schema_name => 'SDE', -
object_name => 'OBJECT_LOCKS');
EXECUTE DBMS_LOGSTDBY.SKIP(stmt => 'SCHEMA_DDL', -
schema_name => 'SDE', -
object_name => 'STATE_LOCKS');
EXECUTE DBMS_LOGSTDBY.SKIP(stmt => 'DML', -
schema_name => 'SDE', -
object_name => 'STATE_LOCKS');
EXECUTE DBMS_LOGSTDBY.SKIP(stmt => 'SCHEMA_DDL', -
schema_name => 'SDE', -
object_name => 'TABLE_LOCKS');
EXECUTE DBMS_LOGSTDBY.SKIP(stmt => 'DML', -
schema_name => 'SDE', -
object_name => 'TABLE_LOCKS');
EXECUTE DBMS_LOGSTDBY.SKIP(stmt => 'SCHEMA_DDL', -
schema_name => 'SDE', -
object_name => 'LAYER_LOCKS');
EXECUTE DBMS_LOGSTDBY.SKIP(stmt => 'DML', -
schema_name => 'SDE', -
object_name => 'LAYER_LOCKS');
EXECUTE DBMS_LOGSTDBY.SKIP(stmt => 'DML', -
schema_name => '%', -
object_name => 'SDE_LOGFILE_LID_GEN');
EXECUTE DBMS_LOGSTDBY.SKIP(stmt => 'SCHEMA_DDL', -
schema_name => '%', -
object_name => 'SDE_LOGFILE_POOL');
EXECUTE DBMS_LOGSTDBY.SKIP(stmt => 'DML', -
schema_name => '%', -
object_name => 'SDE_LOGFILE_POOL');
EXECUTE DBMS_LOGSTDBY.SKIP(stmt => 'SCHEMA_DDL', -
schema_name => '%', -
object_name => 'SDE_LOGFILE_LID_GEN');
EXECUTE DBMS_LOGSTDBY.SKIP(stmt => 'SCHEMA_DDL', -
schema_name => 'SDE', -
object_name => 'CONNECTION_ID_GENERATOR');
EXECUTE DBMS_LOGSTDBY.SKIP(stmt => 'DML', -
schema_name => 'SDE', -
object_name => 'CONNECTION_ID_GENE RATOR');
EXECUTE DBMS_LOGSTDBY.SKIP(stmt => 'DML', -
schema_name => '%', -
object_name => 'SDE_LOGFILES');
EXECUTE DBMS_LOGSTDBY.SKIP(stmt => 'DML', -
schema_name => '%', -
object_name => 'SDE_LOGFILE_DATA');
EXECUTE DBMS_LOGSTDBY.SKIP(stmt => 'DML', -
schema_name => '%', -
object_name => 'SDE_EXCEPTIONS');
EXECUTE DBMS_LOGSTDBY.SKIP(stmt => 'SCHEMA_DDL', -
schema_name => '%', -
object_name => 'SDE_LOGFILE%');
EXECUTE DBMS_LOGSTDBY.SKIP(stmt => 'DML', -
schema_name => '%', -
object_name => 'SDE_LOGFILE%');
One thing to note is that the SQL Apply mechanism of logical standby databases does not work with ST_Geometry. Even if you are using another data type like SDELOB, you should know that the SDE.GDB_ITEMS table at 10.2.1 (actually, probably at 10.1 and later) has a SHAPE field which stores the spatial envelope of all spatial data in the geodatabase. This SHAPE field is of ST_Geometry type, which as I mentioned does not work with logical standby replication. It cannot be changed; I asked Esri's PSSG this question. What I think this implies is that 10.1 and later geodatabases will not work whatsoever with logical standby technology from Oracle. At 9.3.1 (and possibly 10.0), I believe it could work as far as updating values and geometries (just not schema changes); but because of the ST_Geometry data type introduced for the GDB_ITEMS SHAPE field, I have found that logical standby databases won't work if you have any sort of schema change because those changes touch the GDB_ITEMS table. You'll still be able to make a connection, but DDL and DML replication will fail. On a side note, I have found that Oracle Streams uses much of the same underlying technology as logical standby databases. Although I did not perform exhaustive testing with Streams, I was not able to successfully get replication to behave correctly. Instead, I saw similar results to what I saw with logical standby databases. While Oracle replication has been announced by Esri as "officially supported", I did not hear from Esri that Oracle replication using physical standby database is unsupported either. It is my impression that physical standby databases are more robust and behave much better with Esri technology than logical standby databases. Several Esri clients are using this configuration and have been successful with physical standby databases from a DR perspective. Just remember that you cannot connect to the physical standby even with Real-Time SQL enabled because Oracle sets it to read-only. To do so would mean that you would need to perform a failover or switchover. Connecting to the physical standby would be great for reporting and query offloading purposes, and this is possible with non-Esri clients. But for ArcGIS connections, it is not possible. I hope this is helpful to others who have been interested in using Oracle's Active Data Guard Technology. If and when I learn more, I will update this thread.