Re: standby databases for tightly coupled databases question
- From: kathryn axelrod <kat.axe@xxxxxxxxx>
- To: ChrisDavid.Taylor@xxxxxxxxxxxxxxx
- Date: Wed, 12 May 2010 09:42:59 -0700
You want to know..not you're...
Sheesh!!! :)
On Wed, May 12, 2010 at 9:37 AM, kathryn axelrod <kat.axe@xxxxxxxxx> wrote:
> 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:
