RAW tables vs. HDR Replication
Posted in 2014
Topics: High Availability & Replication, Triggers, Constraints & Referential Integrity, Logging & Checkpoints
Hello everybody, I use RAW tables in my transaccional database to overcome concurrent updates on the same row. (f.e.: counters tables). Im planning to implement HDR replication on my database server. Raw tables do not replicate their data into secondary HDR server since DML sentences do not log in the logical logs. So, How can I replicate RAW table data? Would it be a good approach using triggers? Any help will be much appreciated, Best Regards,
Juan You do not mention O/S or IDS Version. I would suggest that using RAW tables in an OLTP database is far from best practise, potentially dangerous and a fudge to get around poor db design or programming logic. However, it is not possible to perform any updates on an HDR secondary, by its very nature it should be immutable except by the HDR log-shipping process. You therefore cannot use triggers to update tables on the secondary from the primary. Your only option is to make these tables STANDARD and change your design/program logic to be correct. Keith On 23 May 2014 09:34, JUAN ROCA <jluis.roca@hotmail.com> wrote: > Hello everybody, > I use RAW tables in my transaccional database to overcome concurrent > updates > on the same row. (f.e.: counters tables). > Im planning to implement HDR replication on my database server. > Raw tables do not replicate their data into secondary HDR server since DML > sentences do not log in the logical logs. > So, > How can I replicate RAW table data? Would it be a good approach using > triggers? > Any help will be much appreciated, > Best Regards, > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --047d7b3a9b74562ed304fa0e209a
I am going to go out on a limb and say that you SHOULD NOT BE USING RAW TABLES in a transactional system. Sorry, but it is my considered opinion that you chose the wrong solution to the concurrency issue and now you are paying the price for that. Yes, triggers will work if the secondary is a standalone server or ER secondary, but you will not be able to replicate a single raw table using triggers to an HDR or RSS secondary. Post the details of the concurrency issues that led you to make this choice and we will try to steer you in the right direction. Or you can hire me to come in and help you redesign your applications or to retrain your developers. Art Art S. Kagel, Principal Consultant ASK Database Management Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Fri, May 23, 2014 at 4:34 AM, JUAN ROCA <jluis.roca@hotmail.com> wrote: > Hello everybody, > I use RAW tables in my transaccional database to overcome concurrent > updates > on the same row. (f.e.: counters tables). > Im planning to implement HDR replication on my database server. > Raw tables do not replicate their data into secondary HDR server since DML > sentences do not log in the logical logs. > So, > How can I replicate RAW table data? Would it be a good approach using > triggers? > Any help will be much appreciated, > Best Regards, > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --089e0158b6c6f611d804fa0fe58c