Re: RAC for Reporting...!

Matt wrote:
> Thanks for the feedback...
>
> I don't believe the queries actually reference any LONG columns which
> means that the Logical Standby approach may still be viable...
>
> I like your idea about setting up a logical standby which is dedicated
> to Reporting and is a subset of the schema. However won't the
> overhead of the log transport services from primary to standby be just
> as much as a localised MV log and fast refreshes at the primary site..
>
> It seems like an additional (unneccesary) step to first copy the
> changes to a remote standby and then build fast refresh MVs on these
> 2nd copies of the reporting tables.
>
> I will investigate the use of DBMS_MVIEW.EXPLAIN_REWRITE today to work
> out why the MV can't be used for rewrite...
>
> Thanks for you help.
>
> Matt
>
>
>

[...]

Yes, the overhead of maintaining the MV's will still be there, just as it would be in the primary database.

But the potential benefit would be in having a separate instance, with different tuning parameters and different hardware to run it, so that reporting queries don't impact transaction performance in the primary database. If you can build the MV's directly in your primary and run the reporting there, then you're right, there's no point.

--Mark Bole Received on Mon May 10 2004 - 09:07:14 CDT