This content has been marked as final. Show 26 replies
You really don't understand what you are posting aren't you?
The Schumacher drivel was based upon a select using index_ffs.
Index_ffs are pretty rare.
Both myself and Jonathan Lewis pointed out to you Schumachers approach is flawed. Even you finally admitted that.
You post the Schumacher example because it is printed in a book published by Rampant Press, your publishing company.
Yet another example of the Burleson Marketing Machine.
Senior Oracle DBA
Yes, understood what you're trying to say.
But i don't understand why you're recommeding index rebuild so many times in so many place. If you understand what you're saying, you should admit that "massive delete" is the only reason when index rebuild is helpful.
In my opinion, under normal situation, we have very rare chance to have massive delete, don't we? 1 out of 10,000 or something? Even in that case, "coalesce" is just a better option than index rebuild.
If so, why index rebuild is so important to you?
Shouldn't you say... "Index rebuild is helpful only under *very very* restrictive situation where your whole data is being deleted. So just be very careful..."
In addition, just because you're a decent consultant, you should be very careful when delivering what other say. Metalink doc is not an exception. If metalink doc has flawes, it your(or our) obligation to detect it and request Oracle to correct it. Don't you think so?
"It's written in metalink... So i have no fault" This attitude is only reasonable for beginners not for professionals like you.
Ah, but according to your mentors, only one "proof" case is necessary to infer how something works . . .
takes one example and comes up with generic recommendations, based on one isolated case.
And please don't insinuate that you are a competant DBA.
Please don't mistake exposure for quality.
But don't take my word for it, let's see what Jonathan says about you:
"Sybrand, Your manners and your lack of care leave much to be desired . . .
You quoted the first line, and commented "utter rubbish" - presumably having failed to bother to go on to the later lines of text. . .
You side-stepped the point, changed the question, and redefined the term DDL to mean 'the components', pointed out that you can save the DDL in a script, and said you didn't see the problem.
"I am allowed to give you the wrong answer because I don't see the problem and I'm not paying attention" is NOT a valid comment. . .
Next time you decide to be offensive, please wait 24 hours
before hitting the <Send> key.
It depends on the system!
under normal situation, we have very rare chance to have massive delete, don't we?
For example, consider the popular Clintrial software, a LIMS system that uses Oracle. In Clintrial, experimental results are initially stored as small rows. Later, as more data is collected, the VARCHAR columns expand, causing massive row chaining, and fragmenting the daylights out of secondary indexes, as key values are changed.
Sure, Metalink has errors, but it's still the "official" rules for what is allowed and what is not allowed. I've seen shops get de-supported for not following the advice on MetaLink. (e.g. advice not to use some 3rd party tools, etc.).
"It's written in metalink... So i have no fault"
But don't take my word for it, let's see whatDon,
Jonathan says about you:
"Sybrand, Your manners and your lack of care leave
much to be desired . . .
You quoted the first line, and commented "utter
rubbish" - presumably having failed to bother to go
on to the later lines of text. . .
You side-stepped the point, changed the question, and
redefined the term DDL to mean 'the components',
pointed out that you can save the DDL in a script,
and said you didn't see the problem.
"I am allowed to give you the wrong answer because I
don't see the problem and I'm not paying attention"
is NOT a valid comment. . .
Next time you decide to be offensive, please wait 24
before hitting the <Send> key.
I'm delighted to see that you approve of the way I criticise people for inaccurate or inappropriate responses.
You are doing it again. As soon as you are exposed a fraud, your only response is to flame the messenger and resorting to insults.
I don't need to insinuate I'm a competent DBA, because I am, and I don't need your flames.
Sadly your real knowledge is reciprocal to your ego.
You are always boasting here about your credentials, you are even boasting about a book you wrote yourself. You lack any sign of modesty.
Why don't you just admit you stand corrected?
Why do you boast about credentials no one can verify? Maybe you are an 'Adjunct Professor Emeritus', maybe you were kicked out after one term? Who can tell?
You have no right to make any assertions about me, because you don't know me.
Yet who you are is quite known: you are a pompous, arrogant man, with an ego as big as the Empire State Building, who really believes he is the best DBA in the world ('Savvy professional' you usually call it).
Sadly to say so, you are not. Referring to your 'Tuning Oracle with Statspack' none of the scripts you published will work when there are 'holes' in the snapshot id, or the database hase been shut down.
You are using 'Oracle Press Author' as a quality sign, tacitly leaving out 'Oracle Press' has nothing to do with Oracle, as is not published by Oracle.
Unfortunately there are too many newbies here who don't know this, and don't say you aren't using the label 'Oracle Press author' precisely because of this reason.
You have dishonesty inscribed all over you. You are constantly lying.
You know the advice you provide is incorrect, yet you go on over and over and over and over again to publish it here, everything linked to your own website.
This is because you misuse this forum as your primary marketing tool.
Actually you are just a troll
Senior Oracle DBA
It was quite shocking to learn from Jonathan Lewis that you really do exist. Shocking and mind-numbing: you really are employed by someone... I'm genuinely aghast.
You dislike Don. Fair enough: it's allowed. But to (a) have a go at him for linking to his sites, when others do likewise, without a murmur of reproval from you and (b) calling him a troll when many, many of your own postings are each a masterclass in nastiness and designed to offend, causes my vision to blur and small, multicoloured dots to dance before my eyes!
How can I tell if my Db indexes require rebuilding.. when should I rebuild.. ?HoLy_PiLgRiM
Just above the list of posts there is an Icon of a magnifying glass with the label "Search Forum". For general purpose questions it's always worth calling on this feature to see if it gets you any interesting material.
For your question, I simply typed "rebuild indexes" as the search requirements and left all other options to default. These were the first three threads in the result list:
Rebuild Multiple Indexes Rebuild multiple indexes...
When to rebuild indexese When to rebuild indexes
Script: Lists All Indexes that Benefit from a Rebuild Script: Lists All Indexes that Benefit from a Rebuild
MetaLink and the docs are the "official" word fromPoint though is Don, metalink documents can be erroneous and are being corrected all the time ...
Oracle, right? When I quote my notes, people
chastise me for NOT citing the docs! I can't win!
However, deletes are a different story. Physically,When a leaf page contains nothing but deleted entries, the leaf block is placed on the freelist and can be subsequently recycled. Therefore, if the insert rate approximates the delete rate and deletes "empty" leaf blocks, the index remains both physically and logically balanced ...
Oracle indexes are always balanced because empty
blocks stay inside the tree structure after a massive
delete. Logically, Oracle indexes are not
self-balancing because Oracle does not remove the
dead blocks as they become empty.
This type of “sparse” index is typical of an index onIt's actually very untypical because you don't appear to understand how deleted entries are cleaned out and blocks recycled by Oracle ...
highly-active tables with large-scale inserts,
deletes and updates. We may have thousands of empty
or near-empty index blocks, and several Oracle
execution plans will run longer on this type of
Excellent question. The benefits of large blocksizesIs that the same thread where you thought the example was based on the guys actual experience but he was simply quoting from our Russian mate on the Ask Tom website that had absolutely no technical merit and that you eventually agreed by stating "Yeah, I redacted that one. " in this thread
are demonstrated on this OTN thread where we see a
demo showing 3x faster performance using a larger
Re: Multiple block size advantages.
Well look, so it is ...
Also, Robin Schumacher has proved that indexes buildYou always, always always always, come back to poor Robin's example. The fact it's published in one of your books does rather explain a lot ...
differently in different blocksizes:
“As you can see, the amount of logical reads has been
reduced in half simply by using the new 16K
tablespace and accompanying 16K data cache.
Clearly, the benefits of properly using the new data
caches and multi-block tablespace feature of Oracle9i
and above are worth your investigation and trials in
your own database.“
Have you thought of a suitable response yet to Greg Rahn's example where he kinda blows this theory out of the water and where I also show you why it's all nonsensical:
Re: Index blocksize
Thought not ;)