| 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
Bear in mind, Oralce is not always 100% accurate, specially when something competes with their product.
"Walking on water and developing software from a specification are easy if both are frozen."
Christopher R. Spence
Oracle DBA
Fuelspot
-----Original Message-----
Sent: Tuesday, May 29, 2001 5: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.
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
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
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: Christopher Spence INET: cspence_at_FuelSpot.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 May 31 2001 - 10:22:43 CDT
 |
 |