0

In the production environment, we have set a HADR solution for the whole database. Now, we would like to exclude some tables from this solution (HADR) and not sync with the secondary database.

my version is db2 luw 10.1.

What are some possible steps to exclude some tables from the HADR?

7
  • Please clarify your specific problem or provide additional details to highlight exactly what you need. As it's currently written, it's hard to tell exactly what you're asking.
    – Community Bot
    Mar 27 at 8:22
  • @Community i guess now it's better! Mar 27 at 8:42
  • 1
    I don't think you can since it ships all tx logs over to the HADR server and replays them there. What problem are you trying to solve? Mar 27 at 12:09
  • @Lennart-SlavaUkraini i have a stored procedure that before setting up the HADR run for 1 hours and eventually over the months, raied its time to 27 hours. in test environment, after rebinding the procedure, it went back to one hour as it was but in production this didn't happen. all the indexes are OK plans are OK. this is one of the things that i want to test. if this HADR affects this proc. Mar 27 at 12:27
  • 1
    You can "invalidate" some tables on HADR Standby by running, say, non-recoverable "load insert" (from /dev/null) on them. You must place these tables to some distinct set of tablespaces to not affect other tables. You must recreate these tables on Standby when it becomes Primary, since these tables will be in the "drop pending" state there. Please, test this approach carefully before running it in production. Mar 27 at 13:39

1 Answer 1

0

What are some possible steps to exclude some tables from the HADR?

Move those tables to a separate database and don't configure HADR for that database.

3
  • this is not good for my case, as these tables are getting some data from time to time. they are not main tables i wanted to state. Mar 27 at 12:28
  • 1
    The answer is technically correct. All logged transactions get replayed on the standby, there is no ability to selectively choose which tables are highly available, except by arranging that those tables are not in your Db2 database. Your peformance problems with a stored procedure are caused most likely by either or both poor coding or poor access-plans and sub-optimal configs.
    – mao
    Mar 27 at 12:55
  • this is now more clear @mao. Mar 27 at 13:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.