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