By submitting my Email address I confirm that I have read and accepted the Terms of Use and Declaration of Consent.

By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.

You also agree that your personal information may be transferred and processed in the United States, and that you have read and agree to the Terms of Use and the Privacy Policy.

TableA is a high transaction table. TableB is essentially a copy of TableA with indexes for reporting. I want to create an insert/update trigger on TableA to replicate the change to TableB.

I?m worried about performance. Mainly, will TableA be locked up until the commit on TableB completes? Or, will DB2 spawn another process to handle TableB?

Maybe you could also direct me to information on this problem? Thank you very much for your time.

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.

0 comments

Register

Login

Forgot your password?

Your password has been sent to:

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy