Rachel,
Sorry for the confusion - I meant that my sales rep got Eyal to reply to
this, and then sent me the informative email. I did not, however, know
that I was getting it from the VP for Technology! I guess I should have
been really impressed with my sales reps leg-work!
Jim
> Jim,
>
> Um, if that is the Eyal I know, it's Eyal Aronoff and he's not exactly a
> "sales rep" for Quest but instead is the Senior VP for Technology and the
> person who developed Shareplex.
>
> Which means you got the best possible answer from the best possible
source.
> He's brilliant.
>
> Rachel
>
>
> >From: "Jim Hawkins" <[EMAIL PROTECTED]>
> >Reply-To: [EMAIL PROTECTED]
> >To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
> >Subject: Re:Your views on Quest - Shareplex
> >Date: Tue, 29 May 2001 11:01:21 -0800
> >
> >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
> >[EMAIL PROTECTED] (work)
> >[EMAIL PROTECTED] (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" <[EMAIL PROTECTED]>
> > > 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: [EMAIL PROTECTED]
> > >
> > > 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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED]
> > >
> > > 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: [EMAIL PROTECTED] (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
> >[EMAIL PROTECTED] (work)
> >[EMAIL PROTECTED] (home)
> >
> >--
> >Please see the official ORACLE-L FAQ: http://www.orafaq.com
> >--
> >Author: Jim Hawkins
> > INET: [EMAIL PROTECTED]
> >
> >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: [EMAIL PROTECTED] (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).
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Rachel Carmichael
> INET: [EMAIL PROTECTED]
>
> 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: [EMAIL PROTECTED] (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
[EMAIL PROTECTED] (work)
[EMAIL PROTECTED] (home)
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Jim Hawkins
INET: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] (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).
