We are over the hump and it's all downhill from here. From our previous image on Queues, we notice that we are now on the Target side of the Streams environment. On this side, we have a buffered queue and the Apply process. The queue on this side will be a secure queue that is the same kind as that on the Source. This secure queue (on the Target side) contains the LCRs sent over by the Propagation process.
At this point, the Apply process comes into the picture. The Apply process takes LCRs (or messages) from the secure queue and applies them to the Target database object, or hands it off to an Apply handler. An Apply handler is a user defined procedure that processes the LCR change. The user defined procedure takes a single LCR (or messages) as input. As with the Capture and Propagation, the Apply process uses rules to determine what LCR's to Apply.
The Apply process is made up of multiple parts. Those parts are as follows:
- Reader server: Takes the LCRs and converts it into transactions, preserving transactional order, and dependencies.
- Coordinator process: Takes the transactions from reader server and sends them to Apply server. This process also monitors the Apply server to ensure that the transactions are applied in the correct order.
- Apply server: Applies the LCR or message to the handler, either an Apply handler or message handler. Apply server also deals with placing the LCR or message into the appropriate error queue if it cannot be applied.
Keep in mind that there can be multiple Apply processes. The Apply reader and Apply server processes show up as background process on the host as ASnn. In addition, there can also be multiple Coordinator Processes (from above). The Apply coordinator background processes names appear as APnn. In both cases, nn is a number and letter combination (0 9 and a z).
The Apply process itself is pretty straightforward; dequeue the LCR, evaluate the LCR against the Apply rules, if the overall evaluation is true, apply it (if it evaluates to FALSE ignore it), if the Apply fails, put the LCR in the Apply error queue. Where things can get complicated is at conflict detection, resolution, transformations, and user defined Apply handlers. To really get your head around conflict detection and resolution, you need to understand the LCR structure. Therefore, we save this discussion for the LCR section. Additional understanding of conflict resolution, transformations, and Apply handlers requires a strong understanding of Rule structures. Thus, we save these discussions for Chapter 5, N-Way Replication, for configuring conflict resolution and Chapter 6 for rule-based transformations.
By default, Triggers do not fire when an Apply processes applies data to a table. This is intended behavior. This keeps changes to replicated tables that result from a trigger at the source site from being duplicated at destination sites. Case in point if we did not take this precaution. Tables A and B are replicated from source to target. Table A has a trigger that updates table B on commit. These two table updates are replicated as both tables A and B are replicated. However, when the change to table A is applied at the destination, it would kick off the trigger to update table B. But, we also have the change to table B that was sent from the source. Either this change will be overwritten by the trigger, or it will fail because the original values of both records, do not match (see our discussion on conflict detection and LCRs later in this chapter). This yields a high potential for data divergence, which is highly undesirable in a replicated environment.
"Well" you say, "What if I need the trigger to fire because I don't replicate table B?". That can be accomplished by setting the trigger's firing property to allow the Apply process to fire the trigger. The trigger firing property default is set to "once", so that it fires once when a normal change is made. However, when the change is accomplished by an Apply process, the trigger will not fire if its firing property is set to "once". The trigger firing property is managed by the DBMS_DDL. SET_TRIGGER_FIRING_PROPERTY procedure. Be careful as the parameter to set the trigger firing to allow the Apply process to fire the trigger is a Boolean and can cause some initial confusion. If the value for FIRE_ONCE is set to TRUE, then Apply will not be able to fire the trigger. If FIRE_ONCE is set to FALSE, then the Apply will be able to fire the trigger.
So, if you want a trigger to fire for applied LCRs you will have a call to DBMS_DDL that looks like this:
sql>exec DBMS_DDL.SET_TRIGGER_FIRING_PROPERTY ( trig_owner => '<schema>', trig_name => '<trigger_name>', fire_once => FALSE);
If you are not sure as to what the trigger firing property is set to, you can use the DBMS_DDL.IS_TRIGGER_FIRE_ONCE function. The function will return TRUE if the FIRE_ONCE property is set to TRUE (meaning the Apply process cannot fire the trigger), and FALSE if it is set to FALSE (meaning the Apply process can fire the trigger).
Note
For more information on the Trigger firing property and the Apply process, please refer to the Advanced Apply Process Concepts chapter in the Oracle Streams Concepts, and the Oracle PL/SQL Reference and Types manual.
The following lists Apply views that contain helpful information concerning your Apply processes:
DBA_APPLYDBA_APPLY_CONFLICT_COLUMNSDBA_APPLY_DML_HANDLERSDBA_APPLY_ENQUEUEDBA_APPLY_ERRORDBA_APPLY_EXECUTEDBA_APPLY_INSTANTIATED_GLOBALDBA_APPLY_INSTANTIATED_OBJECTSDBA_APPLY_INSTANTIATED_SCHEMASDBA_APPLY_KEY_COLUMNSDBA_APPLY_PARAMETERSDBA_APPLY_PROGRESSDBA_APPLY_SPILL_TXNDBA_APPLY_TABLE_COLUMNSDBA_HIST_STREAMS_APPLY_SUMV$STANDBY_APPLY_SNAPSHOTV$STREAMS_APPLY_COORDINATORV$STREAMS_APPLY_READERV$STREAMS_APPLY_SERVER