| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: Re[2]:Your views on Quest - Shareplex
I would guess that Oracle is just covering their collective arses, by putting that stuff out. So some junior wannabe coder (like me) doesn't start writing his own log-based replication software - then suing Oracle when they change something. I believe that Oracle actually works with Quest as a partner (thought I read that somewhere, maybe www.quest.com).
Anyway, we use Shareplex quite a bit. For simple, one-way, DR replicaction (no users in the target) it's very robust. For a reporting scenario (off-loading reporting processes to a seperate schema, one-way replication) it's still pretty good as long as you can *keep users from changing the data on the target instance*. As you get into more complicated implementations (bi-directional, etc.) you need to think things out more carefully, and have more DBA resources available for monitoring, conflict resolution procedures, etc.
Quest's support is very good, in my opinion. They've written patches for us a few times with very short turnaround...
Just my 2 cents...
Have a good one!
> Jim,
>
> Thanks, just assures me that it is NOT a product that I want around.
>
> Dick Goulet
>
> ____________________Reply Separator____________________
> Author: "Jim Hawkins" <jhawkins_at_primary.net>
> Date: 5/29/2001 11:01 AM
>
> All,
>
> We are currently as customer of Quest Software using LiveReorg and
> Spotlight. For those who don't know, LiveReorg is a combination of two
> existing Quest products, Space Manager and SharePlex. I asked the exact
> same question regarding the mining of redo logs of our Quest sales rep. I
> thought all would be interested in the reply. It is a in-line reply to an
> Oracle MetaLink document.
>
> Jim Hawkins
> Lead SAPR/3 Oracle Database Administrator
> MEMC Electronic Materials, Inc.
> 600 Pearl Drive
> St. Louis, MO 633376
> 9636) 474-7832
> jhawkins_at_memc.com (work)
> jhawkins_at_primary.net (home)
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Doc ID:
> Note:97080.1
> Subject:
> Extracting Data from Redo Logs Is Not A Supported Interface
> Type:
> BULLETIN
> Status:
> PUBLISHED
>
> Content Type: TEXT/PLAIN
> Creation Date: 22-JAN-2000
> Last Revision Date: 17-FEB-2000
> Language: USAENG
>
> PURPOSE
> -------
>
> To explain why any extraction of data from redo logs is not supported.
>
> SCOPE & APPLICATION
> -------------------
>
> Customers who are considering using Quest SharePlex for disaster
> recovery.
>
>
> Extracting Data from Redo Logs Is Not A Supported Interface
> ----------------------------------------------------------------------
>
> Quest SharePlex for Oracle replicates data to one or more other Oracle
> instances. It attempts to use the information in the redo log to
> replicate transactions remotely.
>
> 1) There is not sufficient information in the logs to logically
> replicate transactions, so the data applied to the destination system
> may be different from the primary, and therefore inaccurate.
>
> Eyal: That is correct. A part of the SharePlex product goes back to the
> source database and completes the missing information. This is done only
> for certain types of Update statements but is not nessasery for Inserts
and
> Deletes.
>
> 2) Reading the redo log is not a supported interface. From the very
> beginning, Oracle has changed redo log formats to support functional
> enhancements. We must therefore reserve the right to continue to make
> needed log format changes. For this reason, certification of any third
> party product using this interface is not possible. Since this is an
> unsupported interface, the accuracy or completeness of the data in the
> destination database can not be assured.
>
> Eyal: The power of the product is the direct result from reading the raw
> log data. It is our core competency in Quest to understand and support the
> changing nature of the Oracle log. The reality is that between version 7.0
> until 8.1.6 there where only minor changes to the log. Since we are a
close
> partner with Oracle we get early releases of the software and we have the
> chance to update the product as needed. So far this has never been an
issue
> since most large production sites are running Oracle versions that are
> atleast 6 months to a year old.
>
> Regarding assurance to the completeness of the data, we do not expect
> Oracle to provide any assurance. Quest is the one that assures the content
> of the destination. Quest support has some of the best support experts in
> the business. Any problem with the database content should be directed to
> our support organization and not Oracle World Wide Support.
>
> Likelihood of Occurrence
> ~~~~~~~~~~~~~~~~~
> Unknown. However, even a low likelihood is a concern for disaster
> recovery (DR). In disaster failovers, the remote server's database may
> be
> the only viable copy.
>
> Eyal: Since Oracle uses the data in the log to perform database recovery,
> all the information necessary to create a point in time image of the
> database exists in the log. However, we believe that SharePlex has a
better
> chance to survive a disaster than even a database recovery. This is
> because SharePlex only needs the data to recover a transaction while
Oracle
> needs all changes present in the log, including index and rollback
changes,
> to successfully recover a database. An index block corruption may render
> the recovered database useless. History indicates that SharePlex can
> withstand most log corruptions and data block corruptions, while
> maintaining a viable live standby site.
>
> If the client is not a 100% sure, SharePlex provides a variety of
> mechanisms to periodically resync the standby database, including the
> ability to use a hot backup and 3rd party disk mirroring technologies -
all
> of this without interruption to the main production site and without the
> need to reactivate the replication.
>
> Possible Symptoms
> ~~~~~~~~~~~~~
> The logs are applied logically, with most correctness checking
performed
> within the SQL generated by SharePlex, So SharePlex itself must alert
the
> user to any correctness problems. Absent SharePlex notification, the
> destination database likely will continue to work, leaving the user to
> discover any incorrect data.
>
>
> Eyal: Conclusion, Oracle is still obligated to support the Oracle database
> on both the source and the destination. Quest will provide support for the
> content. (I am still waiting for the Oracle Sales rep to stand in front of
> a client and tell them that they do not need to pay for Support on that
> secondary database :-)
>
> I hope this helps.
>
> Eyal
>
>
> > Rao,
> >
> > Somewhere on this list there is a fellow from Quest, I've seen his
e-
> mail,
> > but can't remember who it is. Therefore If I'm leading down a wrong
path
> he can
> > correct. Anyway, as I understand SharePlex it extracts the transactions
> from
> > the archived redo logs to replicate those transactions in another DB.
> Pretty
> > slick, but redo logs are an Oracle company secret and therefore subject
to
> > change by them at will with no forewarning to anyone. Where can that
> leave you,
> > out in the cold with a corrupt staging area? Very possibly. I know of
> another
> > product that is suppose to help you analyze performance problems, but it
> > connects directly to the SGA bypassing the kernel. Problem, it works as
> long as
> > you don't change the starting address of the SGA and/or start paging it
> out of
> > memory. Also, I had a demo copy of a product that supposedly re-
> organized the
> > internals of the database files, while Oracle was shut down. Problem: A
> VERY
> > big warning that if the DB would not restart after they finished,
sorry!!
> >
> > Conclusion, any product that attaches to Oracle or it's files by other
> than the
> > normal methods will not make it through the door.
> >
> > Dick Goulet
> >
> > ____________________Reply Separator____________________
> > Author: "Rao; Maheswara" <Maheswara.Rao_at_Sungardp3.com>
> > Date: 5/29/2001 9:16 AM
> >
> > List,
> >
> > My company is considering Quest - Shareplex.
> >
> > We are considering to use this in our dataware house. Basically, this
> will
> > pull all the transactions from OLTP database and populate staging area
in
> > the dataware house.
> >
> > Could you please give your experiences and the pros and cons of this
> > Shareplex product.
> >
> > Thanks,
> >
> > Rao
> > --
> > Please see the official ORACLE-L FAQ: http://www.orafaq.com
> > --
> > Author: Rao, Maheswara
> > INET: Maheswara.Rao_at_Sungardp3.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).
> > --
> > Please see the official ORACLE-L FAQ: http://www.orafaq.com
> > --
> > Author:
> > INET: dgoulet_at_vicr.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).
> >
> >
>
>
> --
> Jim Hawkins
> Lead SAPR/3 Oracle Database Administrator
> MEMC Electronic Materials, Inc.
> 600 Pearl Drive
> St. Louis, MO 633376
> 9636) 474-7832
> jhawkins_at_memc.com (work)
> jhawkins_at_primary.net (home)
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Jim Hawkins
> INET: jhawkins_at_primary.net
>
> 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:
> INET: dgoulet_at_vicr.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).
-- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jerry C INET: usidba_at_yahoo.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 Tue May 29 2001 - 16:45:22 CDT
 |
 |