Re: Interesting Oracle Data Load Scenario

"Matt" <mccmx_at_hotmail.com> wrote in message news:cfee5bcf.0405192331.4a4bfa4a_at_posting.google.com...
> > So while this is happening you cann't access the primary database. Also
you
> > can't make any changes in the primary database while it was copied over
to
> > the secondary for the data load. (otherwise you loose the data when you
> > restore the database 2ndary to primary)
> > >
>
> You are correct, during the copy of the secondary over the primary we
> would have Production shut down (probably 30-40 minutes). Also the
> initial build of the secondary would require some downtime...
>
> > >
> > > Matt
> >
> > You would be much better served RAC'ing the instance and not having 2
> > databases or buying sufficient hardware and spending time tuning the
> > application and data loads. My guess is if you use bind variables, and
tune
> > the application you should be able to do both things at the same time.
(The
> > administration and complexity of what you are trying to do is insane and
> > costly)
>
> I understand exactly where you are coming from and I totally agree,
> however the performance overhead of the data load is the lower
> priority of the 2 issues...
>
> Our main concern is that if the data load fails, we don't want to have
> to do a P.I.T recovery of the prodcution system. My preference would
> be to load the data into temporary staging tables (in the Production
> database) that were exact copies of the main destination tables...
> then once the data has been verified and tested, merge the 2 tables
> together with SQL.
>
> Matt

Then why not use priority scheduling or resource scheduling in Oracle? You could have the data load log in as a specific user and give them a much lower priority. (eg not to exceed 20% CPU) Then the load "user" would get no more than 20% of the CPU if all the CPU was being used. If no one was on the system then it would get all of it until somone else needed some. Jim Received on Thu May 20 2004 - 14:14:00 CDT