Re: Single RBS for DS system
Date: 1995/04/25
Message-ID: <kjerniga-2504951830570001_at_slipkevinj.emergent.com>#1/1
In article <D7LnM8.807_at_eskimo.com>, lparsons_at_eskimo.com (Lee Parsons) wrote:
> Kevin Jernigan <kjerniga_at_emergent.com> wrote:
>
> >Data massaging done by SQL*Loader is usually done on the client side,
> >before the data is sent to the server side, and doesn't involve database
> >access, so it wouldn't require any rollbac segments.
>
> Most of the massaging we do is post load cleanup/Summary Calcs. Some of
> them are rather nasty.
>
Then you definitely need rollback segment space for those types of
calculations - too bad you can't get SQL*Loader to do this work for
you before you load the data...
> >Index creations
> >done by direct path SQL*Loader will require temp space within the database
>
> We're currently dropping indices/truncating tables/loading tables and
> recreating the indices. I dont know if allowing direct load to create
> the indices is a major win (which I consider to be a +25% perf increase)
> But I do know that having all my indices left in Direct Load state because
> loader burped on the last row is a major lose.
It's usually faster to have direct load do the index creations, but
you are right that it's a pain to have the indexes left in DLS late
in a load. One other option which is sure to be faster if you have
enough CPU and disk bandwidth is to use parallel index create to create
the indexes after loading with direct path. This will still require
rollback segments, but it should be faster than any other option.
>
> This is to some degree just bitching and moaning. I'm sure that I would be
> willing Direct load the indices once it is a bit more stable. I had enough
> problems with it during this conversion to make nervous. (V7.1.3 BTW)
I would recommend upgrading to at least 7.1.4 before trying the parallel index create stuff I mentioned above...
>
> Even so the issue still remains that if we use direct load for index creation
> we are running the risk of finding out about any fatal load problems much
> later in the process and cutting down on recovery time.
Definitely true...
Kevin J Received on Tue Apr 25 1995 - 00:00:00 CEST