New Topic
CommunityTopicQuestionAdministration
Properties
Category Administration
Product Version 7.3

Database replication

Nick shared this question 4 years ago
Answered

Hi team,

We have a customer that has set up their environment such that the SR DB (YF DB) is being replicated, however, some tables are not in sync and have left them out of replication. What we would like to know is in a disaster recovery situation, the following tables will not be in sync:

  • ORGREFERENCECODEDESC
  • REPORTFILTER
  • REPORTFORMAT
  • REPORTHEADER

In the case that the application was made to point to the DB where the above tables are not in sync with the previous one, would it cause any issues?

Based on what I know:

  • It shouldn't prevent the services from starting up, and the application will still work
  • Existing reports may not work

Can you help me confirm?

Regards,

Nick

1 The same question

Replies (4)

photo
1
Neal Dennis ● 4 years ago

Hi Nick,


Yes you are correct, the application would still start but existing reports would not work.


Given that, it begs the question of how effective this is as a disaster recovery solution? Is there a reason that they are choosing not to replicate tables that would, in event of needing this plan, see them manually re-creating their reports?


If space is a concern, perhaps there are other ways we could help them address this through reducing the size of other tables which are less impactful to a restore?


Cheers,

Neal

Reply
photo
1
Nick ● 4 years ago

Hi Neal,

Thanks for confirming.

Yes, I raised similar points to the user regarding the purpose of having a DR solution.

Referring to the 4 tables mentioned, do you know what sort of other impacts this might cause i.e if they contain old information or not in sync with the current environment?

Or if you have any information you can share about these tables, that would be great.

For your awareness, this relates to replication using oracle database guard in logical standby.

Thanks,

Nick

Reply
photo
1
Neal Dennis ● 4 years ago

Hi Nick,


Apologies for the delay, I wanted to try and pin down those answers for you. They are not lengthy, but hopefully it will give you a good idea.


  • ORGREFERENCECODEDESC - contains translation data for Ref Code (eg. AU to Australia) - If the RefCode is changed it may not complete translation in the report, if the descriptions are changed, the text it translates to will be altered
  • REPORTFILTER - maps individual filters to their reports/views and contains their metadata (eg Days BETWEEN 10/10/19 - 12/10/19, VIEW LEVEL). Changes/out of sync could break filters if they relate objects that don't exist or just provide incorrect data
  • REPORTFORMAT - contains filter metadata (type of filter, its parent filter, is it cached/on-demand). This could affect the function of the filters and in turn the report
  • REPORTHEADER - metadata about a report (ViewID, security settings, historical versions, published versions).

One suggestion that may be worth testing is that the client could create a test environment with a copy of their current YF and simply delete linked entries in those tables to see the impact for themselves to be able to better make a decision.


I will say that we do not support the plan to not include these table and it would be our recommendation to make sure they are part of the DR solution.


Cheers,

Neal

Reply
photo
1
Nick ● 4 years ago

Hi Neal,

Thanks for that. This answers my questions.

This post can be marked as closed.

Regards,

Nick

Reply
Leave a Comment
 
Attach a file