| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> Re: Replication or Database Link ?
Check out SharePlex by Quest Software, log based replication for Oracle
article <37B19E18.715D5C10_at_us.oracle.com>,
Pete Sharman <psharman_at_us.oracle.com> wrote:
> This is a multi-part message in MIME format.
> --------------14B030D85C968D165FF473D8
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
> Timo
>
> First question I'd have to ask is why do you need two databases?
>
> If you really need two separate databases, are they in the same
network? If
> so, what's the network speed and how reliable is it? I wouldn't use
> synchronous replication unless the two databases are on the same very
> reliable LAN.
>
> HTH.
>
> Pete
>
> tsalzsie_at_hotmail.com wrote:
>
> > I would like to ask you for your advice regarding the following
> > scenario:
> > We have two databases where database CALLDB is accessed by call
center
> > agents during normal office hours. The second database WEBDB is
accessed
> > by internet users. Both parties basically work on the same table
MEMBER
> > where they change data like addresses, phone-numbers, etc.
> > During night, we run a large batch job and load up to 5 million
rows via
> > sqlldr into the table MEMBER. In other words, at night the data is
> > not accessed by the call center, but internet folks obviously still
> > work with the database (performance!!). This whole scenario applies
not
> > only to the specified MEMBER table, but also to some other tables.
> >
> > Now, the question. How do we achieve the requirements that
> > - the data must be synchronized instantially (call center must
access
> > basically the same data as the web user, thus real-time
synchronization
> > between WEBDB and CALLDB)
> > - security
> > - performance (limit network traffic)
> >
> > We were thinking about two possible solutions.
> > A. Synchronous Replication
> > - almost real-time
> > - high network traffic, performance might be a bottleneck
> > - high effort to implement (setup, conflict resolution, etc.)
> > - handling of large batch job imports still a open issue
> > B. Database link
> > - high availiablity of either one of the solutions is not guaranteed
> > - simple to implement
> > - handling of large batch job import also an open issue
> >
> > We would appreciate any comments, experience reports,
recommendations.
> >
> > Thanks in advance, Timo.
> >
> > Sent via Deja.com http://www.deja.com/
> > Share what you know. Learn what you don't.
>
> --
> Regards
>
> Pete
>
> --------------14B030D85C968D165FF473D8
> Content-Type: text/x-vcard; charset=us-ascii;
> name="psharman.vcf"
> Content-Transfer-Encoding: 7bit
> Content-Description: Card for Pete Sharman
> Content-Disposition: attachment;
> filename="psharman.vcf"
>
> begin:vcard
> n:Sharman;Peter
> tel;cell:+1.650.868.9969
> tel;fax:+1.650.633.1669
> tel;work:+1.650.607.0109
> x-mozilla-html:FALSE
> url:http://www.oracle.com
> org:Oracle University, Consulting and Vertical Education;Oracle
Corporation
> adr:;;500 Oracle Parkway M/S OPL-B1024;Redwood
Shores;California;94065;USA
> version:2.1
> email;internet:psharman_at_us.oracle.com
> title:Project Manager
> note;quoted-printable:=0D=0A=0D=0A **** The statements and opinions
expressed here are my **** =0D=0A **** own and do not necessarily
represent those of **** =0D=0A **** Oracle Corporation. =20****=0D=0A=0D=0A"Controlling application developers is like herding cats." =0D=0AKevin Loney, ORACLE DBA Handbook =0D=0A=0D=0A"Oh no it's not! It's much harder than that!" =0D=0ABruce Pihlamae, long term ORACLE DBA
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Received on Sun Aug 29 1999 - 00:52:02 CDT
 |
 |