Jim,

My apologies -- I misunderstood what you wrote. yes, pretty good legwork. 
Eyal used to be in NY and part of our user group here. I,
for one, miss him!

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 13:06:11 -0800
>
>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).

_________________________________________________________________
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).

Reply via email to