Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Re[2]:Your views on Quest - Shareplex

RE: Re[2]:Your views on Quest - Shareplex

From: Hawkins Family <jhawkins_at_primary.net>
Date: Tue, 29 May 2001 15:06:11 -0700
Message-ID: <F001.00312CE8.20010529151110@fatcity.com> 






Just being honest and throwing all the information out there ;)



Jim



-----Original Message-----



dgoulet_at_vicr.com


Sent: Tuesday, May 29, 2001 4:06 PM


To: Multiple recipients of list ORACLE-L




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: Hawkins Family
  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).


Received on Tue May 29 2001 - 17:06:11 CDT












Original text of this message













  HOME |
  ASK QUESTION |
  ADD INFO |
  SEARCH |
  E-MAIL US