BD schreef:
> On Mar 27, 2:51 pm, Richard Piasecki <usen..._at_ogoent.com> wrote:
>> Is there any reason why you don't want to use a refresh group for these mviews?
>
> Historically (we're moving from an ODS export/import scenario),
> automation of the replication has been table-driven; the list of
> tables to be replicated were governed by a driving table, to which a
> record would be added for each table to be replicated.
>
> The requirement of maintaining a refresh group, and ensuring that new
> tables get included in it through the use of the ADD procedure, would
> likely require as much automation coding (if not more) than the code
> required to generate the script for the individual refresh
> statements... and since that process has already been done, the
> additional benefit that a refresh group would have to my situation is
> unclear: there's no need for me to ensure the point-in-time
> consistency that a refresh group allows for, and I only have 'the one
> group' - so there's no benefit of creating multiple groups for
> multiple schedules, etc.
>
> If there were a 'generic', schema-wide, single refresh procedure that
> didn't require the maintenance of the group, I'd probably go for it.
>
> In fact, there is a benefit of me being able to report on how long
> each of these mvs is taking to refresh - so doing them individually
> with TIMING set to ON is helpful for maintaining metrics on the volume
> of changes being made to the source tables.
>
>
>
Put the calls in a procedure.
--
Regards,
Frank van Bortel
Top-posting is one way to shut me up...
Received on Wed Mar 28 2007 - 13:53:32 CDT
