The triggered action becomes part of the unit of work of the SQL statement that triggered the action. So, in your case, the process required to replicate the change to TableB will be part of the UOW that initially makes the change to TableA. In an environment with high transaction rates this scenario is not likely to perform very well for you.
How much of a delay can you incur between the change happening to TableA and it being replicated to TableB? If there can be a delay then I would recommend that you look into getting some type of replication or ETL tool so you can set up an asynchronous process having the modification to TableB get queued and then made in the background so that it does not impact the performance of the transactions changing TableA.
Here are some online resources for further reading:
TRIGGERS
DB2 Triggers
Object-Relational Programming with DB2
Are you Trigger Happy?
Fun with Triggers
REPLICATION
DB2 Replication
Replication Guide and Reference
Data Replication
Product Solutions
Editor's note: Do you agree with this expert's response? If you have more to share, post it in one of our discussion forums.
|
