Exclude Tables from HADR in DB2

Question

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?

• Community: 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.
• Vasileios G: @Community i guess now it's better!
• Lennart - Slava Ukraini: 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?
• Vasileios G: @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.
• Mark Barinstein: 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.

Answer 1

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.

• Vasileios G: 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.
• mao: 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.
• Vasileios G: this is now more clear @mao.