Re: Refresh Materialized view manually
From: joel garry <joel-garry_at_home.com>
Date: Wed, 3 Jun 2009 09:44:37 -0700 (PDT)
Message-ID: <8b311a92-44e0-4b6c-9109-8d9398278d34_at_g1g2000yqh.googlegroups.com>
On Jun 3, 8:34 am, ddf <orat..._at_msn.com> wrote:
> On Jun 3, 3:53 am, Randolf Geist <mah..._at_web.de> wrote:
>
>
>
> > > We refresh this view every 30 seconds automatically.
> > > Sometimes underlying tables will be updated by users and they want to
> > > generate a report right away with the updated data.
> > > They don't want to wait next 30 seconds, for the latest data. So want
> > > to provide a manually refresh so that latest data will updated in
> > > materialized view.
>
> > Naga,
>
> > although I second the doubts that this design is sound, if you really
> > have the need for "real-time" refreshes why not go for the ON COMMIT
> > refresh clause of the materialized view?
>
> > Regards,
> > Randolf
>
> > Oracle related stuff blog:http://oracle-randolf.blogspot.com/
>
> > SQLTools++ for Oracle (Open source Oracle GUI for Windows):http://www.sqltools-plusplus.org:7676/http://sourceforge.net/projects...
>
> Depending upon how long the refresh actually takes, using the ON
> COMMIT refresh option can increase the time required to complete the
> insert/update/delete transactions to the defining tables, which may be
> an unacceptable option especially if this is an OLTP system. Granted
> a 30-second refresh schedule is (in my mind) ridiculous, but using ON
> COMMIT may slow down transactions to an unacceptable level.
>
> Of course we know nothing of this system outside of the 30-second
> refresh schedule for a materialized view for which we have no
> definition.
Date: Wed, 3 Jun 2009 09:44:37 -0700 (PDT)
Message-ID: <8b311a92-44e0-4b6c-9109-8d9398278d34_at_g1g2000yqh.googlegroups.com>
On Jun 3, 8:34 am, ddf <orat..._at_msn.com> wrote:
> On Jun 3, 3:53 am, Randolf Geist <mah..._at_web.de> wrote:
>
>
>
> > > We refresh this view every 30 seconds automatically.
> > > Sometimes underlying tables will be updated by users and they want to
> > > generate a report right away with the updated data.
> > > They don't want to wait next 30 seconds, for the latest data. So want
> > > to provide a manually refresh so that latest data will updated in
> > > materialized view.
>
> > Naga,
>
> > although I second the doubts that this design is sound, if you really
> > have the need for "real-time" refreshes why not go for the ON COMMIT
> > refresh clause of the materialized view?
>
> > Regards,
> > Randolf
>
> > Oracle related stuff blog:http://oracle-randolf.blogspot.com/
>
> > SQLTools++ for Oracle (Open source Oracle GUI for Windows):http://www.sqltools-plusplus.org:7676/http://sourceforge.net/projects...
>
> Depending upon how long the refresh actually takes, using the ON
> COMMIT refresh option can increase the time required to complete the
> insert/update/delete transactions to the defining tables, which may be
> an unacceptable option especially if this is an OLTP system. Granted
> a 30-second refresh schedule is (in my mind) ridiculous, but using ON
> COMMIT may slow down transactions to an unacceptable level.
>
> Of course we know nothing of this system outside of the 30-second
> refresh schedule for a materialized view for which we have no
> definition.
But we can infer that the system is already fupped, I'd go further and speculate it already takes too long and that is why they want a cocaine-crazed-lab-rat-lever to pound on to "make it go faster."
Give them a "go faster" button to click on, that does an alter database go_faster with error redirection to the bit bucket.
I'd be wondering how long the refreshes and updates take now.
jg
-- _at_home.com is bogus. http://www3.signonsandiego.com/stories/2009/jun/03/1b3tivo214441-tivo-award-patent-case-gets-103-mill/?uniontribReceived on Wed Jun 03 2009 - 11:44:37 CDT