Re: standby databases for tightly coupled databases question

  • From: kathryn axelrod <kat.axe@xxxxxxxxx>
  • To: ChrisDavid.Taylor@xxxxxxxxxxxxxxx
  • Date: Wed, 12 May 2010 09:37:35 -0700

Based on your example:

DB1 – performs a log switch and logwr ships the data to DB1 standby
DB2 – is reading the data from DB1 and manipulating data but no log switch
when a failure occurs.

If DB2's standby is called DB2S:
You're want to know how to make sure that DB2S will have the proper/needed
information such that after DB2 fails, DB2S will continue to implement the
proper data manipulation based on DB1's changes, correct?




On Wed, May 12, 2010 at 7:42 AM, Taylor, Chris David <
ChrisDavid.Taylor@xxxxxxxxxxxxxxx> wrote:

>  For those of you running standby databases AND have tightly coupled
> databases (databases that share data between them via dblinks etc), how do
> you manage the potential for data synchronization issues?
>
>
>
> For example:
>
>
>
> DB1 (PeopleSoft) has transactions applied
>
> DB2 (Legacy Apps) has multiple database jobs that pull data from DB1 and
> manipulates data in DB2 based on the changes that occurred in DB1
>
>
>
> What is your strategy for making sure the data is in the “right places”
> after a failover?  I’m assuming that in some cases data could be in the REDO
> area of the Primary at the time a failure occurs and thus not shipped to the
> standby, whereas in the other database, some of that data might have already
> been shipped over because of a log switch.
>
>
>
> Example:
>
>
>
> DB1 – performs a log switch and logwr ships the data to DB1 standby
>
> DB2 – is reading the data from DB1 and manipulating data but no log switch
> when a failure occurs.
>
>
>
>
>
>
> Thanks,
>
> Chris
>

Other related posts: