CDC using LogMiner in RAC environment

From: Jeffery Thomas <jeffthomas24_at_gmail.com>
Date: Mon, 29 Sep 2008 11:14:43 -0400
Message-ID: <22131320809290814gb567e25sbe2c2ec87050750e@mail.gmail.com>


Currently, we are using an Informatica product to perform CDC in a 10.2.0.4, two-node RAC environment.
The product has a listener that receives results from an ad-hoc query against V$LOGMNR_CONTENTS in
continuous mining mode, then ships relevant transactions to a different database.

The process seems somewhat fragile. If we take down one instance for maintenance (or if it crashes) the
LogMiner session ends due to the disabled thread. A mining session can also sporadically terminate as a
result of a hot backup, apparently due to the alter system archive log issued by RMAN. There is a known
bug in 10.2.0.4 RAC (fixed in 11.2) where a LogMiner continuous mining session terminates due to a disabled
thread that we are discussing with Support.

There's no filtering of redo by the ad-hoc query, the SELECT has no WHERE. The business logic is outside
the database in the Informatica piece so that all redo records mined are forwarded to the external 3rd-party
listener. So in a busy source database there can be a considerable lag between the time of the commit of a relevant transaction to when it gets shipped to the target database.

My question(s) would be: is LogMiner alone onsidered sufficiently robust and reliable to provide near real-time CDC? Is it intended to be used in that fashion where the usage is simply an un-filtered ad-hoc select against
V$LOGMNR_CONTENTS in continuous mining mode and shipping the data outside to an external 3rd-party
tool?

Reading about LogMiner in the Oracle docs does not mention CDC per se, only identifying it as a tool for auditing and data analysis. If we were to use Streams which seems to be the recommended Oracle CDC mechanism and
that also uses LogMiner under the hood, would we see the same fundamental issues as we are currently
experiencing?

Thanks,
Jeff

--
http://www.freelists.org/webpage/oracle-l
Received on Mon Sep 29 2008 - 10:14:43 CDT

Original text of this message