Re: Excessive Logical and Physical I/O

Brian Peasland <dba_at_remove_spam.peasland.com> wrote in message news:<4061D450.ECB68731_at_remove_spam.peasland.com>...
> > > Building a read consistent image is on a block by block basis. If one
> > > user only needs 1MB of read consistent images, then they only rebuild
> > > the number of blocks to satisfy that request.
> > >
> > > HTH,
> > > Brian
> >
> > Does that mean that rollbacks that are allowed to overextend don't
> > have a negative impact on performance...? because everything I have
> > read points to the opposite...
>
> I'm having a hard time understanding how you went from my comments to
> your comments. I must have missed the logic somewhere along the lines
> there.
>
> And what do you mean by "overextend"? A rollback segment can extend, up
> to MAXEXTENTS. It can't extend past that. MAXEXTENTS is the maximum
> number of extents. How can you go over this amount?
>
> Any time an extent has to be allocated or deallocated, work has to be
> done. If your task requires an allocation or deallocation of an extent,
> then the time it takes to complete the task will be longer than if you
> were able to accomplish the same task without the
> allocation/deallocation of that extent. Will that have a negative impact
> on performance? It depends on many factors. I don't subscribe to the
> theory that just because something takes a little longer, it negatively
> impacts performance. To me, negative (or positive) performance impacts
> are measured by user pain (or joy) over the job that they are trying to
> accomplish. If the user doesn't notice anything, and therefore they are
> not experiencing any pain, then the allocation of extents is not causing
> a performance problem. If you stop the allocation of extents, and the
> user is happy with the results, because it is a noticable improvement,
> then there was a negative performance impact.
>
> HTH,
> Brian
>
>
> --
> ===================================================================
>
> Brian Peasland
> dba_at_remove_spam.peasland.com
>
> Remove the "remove_spam." from the email address to email me.
>
>
> "I can give it to you cheap, quick, and good. Now pick two out of
> the three"

I think what he is asking is, if there is 1M worth of blocks to be consistent in a 1G RBS, might Oracle have to look through the whole 1G to get that 1M. And I think the answer would be the rollback headers track where the info is by block, so it shouldn't be a problem. http://www.ixora.com.au/q+a/undo.htm might help clarify some. And as you said, extent allocation is the real problem, so I would add, size the extents so the transactions fit in them.

I somewhat agree with the pain/joy thing, but have to point out that habitually doing things "correctly" will put off the pain, since performance on a multiuser system is a summation of usage. The obvious pitfall is over-administrating, that is, spending lots of time trying to get the nth incremental bit of performance.

jg

--
@home.com is bogus.
Plug the ethernet into the electric socket. 
http://www.economist.com/displaystory.cfm?story_id=2476988