Re: new DirectX Oracle online monitor

"Howard J. Rogers" <hjr_at_dizwell.com> wrote in message news:<40693e5a$0$15063$afc38c87_at_news.optusnet.com.au>...
> "Boaz Laufer" <lauferb_at_adit-tec.com> wrote in message
> news:1bacd337.0403300005.5de44e21_at_posting.google.com...
> > joel-garry_at_home.com (Joel Garry) wrote in message
> news:<91884734.0403231611.28680743_at_posting.google.com>...
> > > lauferb_at_adit-tec.com (Boaz Laufer) wrote in message
> news:<1bacd337.0403220958.799a765f_at_posting.google.com>...
> > > > Hello DBA's,
> > > > I'd like to invite you to my site to try my new DirectX based oracle
> online monitor.
> > > > The name is 'SGAgent'.
> > > >
> > > > http://boazl.com
> > > >
> > > > Regards,
> > > > Boaz.
> > >
> > > Why would you want to compress extents? Why would you want to use
> > > something based on Direct X? What does this have that OEM doesn't?
> > > What is SGAgnet [sic]?
> > >
> > > jg
> >
> > Rebuilding database objects improve performance!
> > I checked it a lot of times and it improves performance a lot.
> > There are some reasons why this improves performance:
> > Rebuilding database Objects:
> > * Empties the Free-Lists.
>
> Which is not necessarily such a brilliant move if your table is about to be
> subjected to new inserts such that it has to re-acquire the space that your
> rebuild caused it to lose, but which it already originally had.
>
> > * Fix Chained rows
>
> Nothing can fix a chained row except for the re-creation of the database.
> You are talking about row *migration*, not row chaining.

I refered to 'Migrater rows',
Oracle treats both Migrated rows and chained rows as CHAINED ROWS.

>
> > * Compress the data inside the blocks (saves space and Cache-Memory)
>
> And increases the chances of user-collisions on a well-packed block and
> thereby increase your chance of getting buffer busy waits.

And SAVE SPACE in the Cache in case of tables that have 'select' statements
(more data is in less blocks)
To fix the problem that you're talking about b.t.w the way is to increase the freelists and not make a fragmented tables... (what are you talking about man??)

>
> > * Rebuild the indexes - makes them more balances
>
> Oh God. Indexes in Oracle are ALWAYS ALWAYS ALWAYS balanced. Automatically.
> In real time.

you have a mistake Mr.
you are refering to the Btree that is automatically balanced but what about the unused space inside the blocks? Unlike on a Table block, on Index blocks there's significant meaning to the place that the data sit do to the structure of the Btree, (that's why Indexes dont have PCT_USED parameter b.t.w because it doesn't make a difference)
so with time, if index is updated, there are more and more empty and unused spaces inside the blocks,
and that's why Rebuild of an index lowers its BLEVEL

>
> I don't mean to be unkind, but you appear to be lacking a little in the
> 'there's more to this than meets the eye' department. Sometimes an object

I never said that I know anything man
(unlike you I guess)

> re-organisation might be beneficial. And sometimes it will make no
> difference. But all times, there will be massive I/O costs and locking
> issues. So you have to weigh these things up carefully on a case by case
> basis, and you can't just blunder about with a sackfull of myths,
> half-truths and complete misunderstandings to see you on your way.

Reorganization almost almost (99.999%) of the times can improve the performance of the database (especially databases with a lot of transactions),
sometimes it makes no difference but it can almost almost never make the performance worst (unlike other ways of tunning like SQL's, parameters and so..)
I'm not saying that Reorg is the ultimate solution but this is a good thing to do (and plan the downtime for the Reorg of course!)

>
> Regards
> HJR
Take care
Boaz. Received on Tue Mar 30 2004 - 13:41:57 CST