RE: replication

From: Nick Wagner <Nick.Wagner_at_quest.com>
Date: Thu, 10 Jan 2002 16:25:42 -0800
Message-ID: <F001.003ED35A.20020110152521@fatcity.com>

uh oh... with that said, I guess I better jump in.

and follow suit with your format...

SharePlex for Oracle by Quest Software
(www.quest.com/shareplex)

Pros: Extremely fast (50+GB of data per day) Low overhead (3-7% overall.)
Messages are applied via standard SQL on the target, so target database(s) are completely open and available. Additional indexes can be made to the reporting instance to speed up reports.

        Can replicate most datatypes (longs, long raw, LOB's, varchar, char, date, numbers, etc...)
        Tables do not need PK or UK's.
        peer to peer replication possible for load balancing
        installation in 20 minutes, and can be replicating tables 5 minutes after that. (Implementation into production will take longer... 3-10 days depending on environment)

can replicate sequences for HA/DR

cons: cost (as John points out)

        does not replicate all DDL (i.e. users, packages, procedures)
        no transformation or ETL capabilities (this is coming end of Q1)
        replicates entire table only (logical partitioning of data is also coming end of Q1)

If you would like more information about it, please send me an email, and I can answer any questions you have.

Nick

-----Original Message-----
From: John Kanagaraj [mailto:john.kanagaraj_at_hds.com] Sent: Thursday, January 10, 2002 1:35 PM To: Multiple recipients of list ORACLE-L Subject: RE: replication

Bill,

If you have the $$, then you should look at Quest's Shareplex. Nick Wagner from this list is the Product Manager and I am sure he can provide more details.

John Kanagaraj
Oracle Applications DBA
DBSoft Inc
(W): 408-970-7002

Fear is the darkroom where Evil develops your negatives. Wanna break free of fear? Click on 'http://www.needhim.org'

The opinions and statements above are entirely my own and not those of my employer or clients **

> -----Original Message-----
> From: Bill Becker [mailto:beckerb_at_mfldclin.edu]
> Sent: Thursday, January 10, 2002 12:56 PM
> To: Multiple recipients of list ORACLE-L
> Subject: replication
>
>
> Greetings,
>
> I am looking for advice regarding Oracle replication. We are on
> 8.1.6 EE, and will be upgrading to Oracle9 later this year. At that
> time, we also plan to establish another Oracle instance on a
> separate sun machine; 1 instance will serve as a staging area, the
> second will be a production reporting database. We need a way
> to quickly
> move processed data from the stage instance to the production instance
> on a daily basis.
>
> Methods we have discussed, pros and cons (please feel free to
> comment):
>
> Export/Import and flat file transfers have been ruled out due
> to speed.
>
> Transportable Tablespaces:
> Pros: fastest method of moving large amounts of data
> Cons: Constraints - our tables are very integrated, lots of
> foreign keys,

>       just about every tablespace set would have to include a

> core set of

>       reference tables, or the entire thing (500GB) would

> need to be in the

>       same tablespace set; not including constraints means

> re-building them

>       in the production instance, including indexes for PKs

> and UKs (I think)

>       and probably other problems. How do others handle these

> problems?

>       Also, this transfers all data, when only a very small

> percentage of

>       rows (< 1% of total rows) has actually changed that

> day. Seems inefficient.
>
> Oracle Replication:
> Pros: The documentation seems to address our situation,
> replicating a small

>       (relative to total db size) batched amount of data

> daily. (2-4 GB)
> Cons: Looks complex, 2 books (~760 pgs, ~360 pages in
> Oracle9), 13 packages.

>       No experience with this - How well does it work? Is it

> difficult to

>       set up? Any comments regarding speed? Can replication

> be set up for existing

>       tables, or do they need to be re-created and re-loaded

> as a materialized view?
>
> We are also considering another solution, basically borrowing many of
> the ideas from Oracle replication and writing it ourselves.
> This would be
> a home-grown solution involving table triggers, additional
> tables to store
> the daily changes, and scripts to propagate the changes over
> database links.
> But before we decide, I wanted to hear what others had to say
> regarding Oracle replication.
>
> Thanks for any advice.
>
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Bill Becker

>   INET: beckerb_at_mfldclin.edu

>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: John Kanagaraj
  INET: john.kanagaraj_at_hds.com


Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

Received on Thu Jan 10 2002 - 18:25:42 CST