No, I'm afraid that won't work and is not supported. We do support use of READONLY and AWT cache groups in conjunction with Data Guard in the following configuration (documented in the TimesTen IMDB Cache Guide):
1. Data Guard is configured as synchronous physical standby
2. All TT caches run against the active Oracle DB
3. When a Data Guard failover occurs, TT caches can be migrated to run against the standby DB that has now beed promoted to active
This is the only supported setup.
thanks a lot for the clarification. Just another question: what about using logical Data Guard replication to replicate the user schema only, not the ttadmin schema, and creating the ttdadmin schemas locally in read-write mode, just like it's done on the master instance? Would this approach be viable / supported? It seems to me this would simplify our cache configuration as the TT agents would always synchronize with the site-local Oracle instance.
Thanks for your support,
Provided that logical Data Guard apply fires triggers then this approach ought to work okay (cache change tracking is based on triggers), though we have not explicitly tested tor certified it. If logical Data Guard apply does not fire triggers then this is a nonn-starter I'm afraid. I do not know if apply fires triggers; that is something I will need to check out.
thanks for that. Indeed the documentation seems to indicate that triggers will be applied to the standby database, but clearly this would need to be tested. I'll try to test this and post the results.
so after testing a little bit it appears that this approach works indeed, at least against a limited number of manual DML operations. What I needed to do on the slave instance to have it working is the following:
1 - Entirely exclude TTADMIN and TIMESTEN schemas from the Data Guard replication:
ALTER DATABASE STOP LOGICAL STANDBY APPLY; execute dbms_logstdby.skip(stmt => 'SCHEMA_DDL', schema_name => 'TTADMIN', object_name => '%'); execute dbms_logstdby.skip(stmt => 'SCHEMA_DDL', schema_name => 'TIMESTEN', object_name => '%'); execute dbms_logstdby.skip(stmt => 'DML', schema_name => 'TTADMIN', object_name => '%'); execute dbms_logstdby.skip(stmt => 'DML', schema_name => 'TIMESTEN', object_name => '%'); ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
2 - Erase both schemas from the local instance:
DROP USER TTADMIN CASCADE; DROP USER TIMESTEN CASCADE; CREATE USER TTADMIN etc
3 - Temporarily disable the database guard while creating the local ttCache structures, as the scripts seem to need to set a table-level lock on the source table:
ALTER DATABASE GUARD NONE; ttIsql> CREATE READONLY CACHE GROUP etc ALTER DATABASE GUARD STANDBY;
4 - Unset the "Fire_Once_Only" property for the local TTADMIN triggers:
execute dbms_ddl.set_trigger_firing_property(trig_owner=> 'TTADMIN', trig_name=> 'TT_06_70560_T', fire_once => FALSE);
At that point the cache seems to replicate properly in the most simple cases. I will try to test with some substantial load and against DG failovers to see how this behaves.