dbTalk Databases Forums  

[Materialized Views over DB links]HA Problem with ORA-02019

comp.databases.oracle.server comp.databases.oracle.server


Discuss [Materialized Views over DB links]HA Problem with ORA-02019 in the comp.databases.oracle.server forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
Jia Lu
 
Posts: n/a

Default [Materialized Views over DB links]HA Problem with ORA-02019 - 03-24-2010 , 03:29 AM






Hi all
I created 2 multi master DBs and using materialize views to
synchronize them.
The relation is Main - Sub, and when I insert/commit to either one ,
another site's table will be updated.

My problem is when DB link failed, I cannot insert data into the
normal DB it said ORA-02019.

That will be a high availability problem when one DB is down.

Is there a feature can let me to update to the table when another site
is down?
And can it be synchronized after the db link recovered ?

Thank you.
Best
Lau Lu.

Reply With Quote
  #2  
Old   
gazzag
 
Posts: n/a

Default Re: HA Problem with ORA-02019 - 03-24-2010 , 05:09 AM






On 24 Mar, 09:29, Jia Lu <roka... (AT) gmail (DOT) com> wrote:
Quote:
Hi all
*I created 2 multi master DBs and using materialize views to
synchronize them.
*The relation is Main - Sub, and when I insert/commit to either one ,
another site's table will be updated.

My problem is when DB link failed, I cannot insert data into the
normal DB it said ORA-02019.

That will be a high availability problem when one DB is down.

Is there a feature can let me to update to the table when another site
is down?
And can it be synchronized after the db link recovered ?

Thank you.
Best
Lau Lu.
I assume that you're on 10gR2 Standard Edition One as per your
previous thread?

If you're looking for a High Availabilty option, I doubt you should be
using Standard Edition One. Depending on your exact requirements and
budget, you might want to consider Enterprise Edition and Oracle's
DataGuard.

This document may also be worth a read:
http://www.oracle.com/technology/dep...R2_Roadmap.pdf

HTH
-g

Reply With Quote
  #3  
Old   
Jia Lu
 
Posts: n/a

Default Re: HA Problem with ORA-02019 - 03-24-2010 , 06:10 AM



On 3月24日, 午後8:09, gazzag <gar... (AT) jamms (DOT) org>wrote:
Quote:
I assume that you're on 10gR2 Standard Edition One as per your
previous thread?

If you're looking for a High Availabilty option, I doubt you should be
using Standard Edition One. *Depending on your exact requirements and
budget, you might want to consider Enterprise Edition and Oracle's
DataGuard.

Thanks for your answer.
Yes I want to use EE too.
but the budget is the problem and the boss donot know anything about
Oracle.
So I have to use SEO edition to implement it.


Wishes

Reply With Quote
  #4  
Old   
Mark D Powell
 
Posts: n/a

Default Re: HA Problem with ORA-02019 - 03-24-2010 , 07:06 AM



On Mar 24, 8:10*am, Jia Lu <roka... (AT) gmail (DOT) com> wrote:
Quote:
On 3月24日, 午後8:09, gazzag <gar... (AT) jamms (DOT) org> wrote:

I assume that you're on 10gR2 Standard Edition One as per your
previous thread?

If you're looking for a High Availabilty option, I doubt you should be
using Standard Edition One. *Depending on your exact requirements and
budget, you might want to consider Enterprise Edition and Oracle's
DataGuard.

Thanks for your answer.
Yes I want to use EE too.
but the budget is the problem and the boss donot know anything about
Oracle.
So I have to use SEO edition to implement it.


Wishes
If your exiting code only works when both databases are available and
you need each database and its associated applications when the other
is unavailable then depending on how many tables you need replicated
you might consider roll your own replication.

Define database table triggers on the tables. The triggers can either
capture all changes to a tracking table and then a batch process can
run and ship the rows over deleting them on successful shipment. If
the remote database is unavailable the next run picks up the data and
tries again.

You can also have the triggers attempt to directly insert/update/
delete the remote data and only capture the change via error handling
if the remote operation fails due to the remote database being
unavailable however the performance of repeated failed remote
operations is not good to say the least.

HTH -- Mark D Powell --

Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.