I’m a big fan of the Oracle documentation, but sometimes things go astray. A recent question by Aman Sharm about SQL sharing critera highlighted this…
In the 8iR3 manual, the decision process for finding matching SQL is listed as:
- The text string of an issued statement is hashed. If the hash value is the same as a hash value for an existing SQL statement in the shared pool, then Oracle proceeds to Step 2.
- The text string of the issued statement, including case, blanks, and comments, is compared to all existing SQL statements that were identified in Step 1.
In the 9iR1 manual it was rewritten to include all the steps for identifying the match in a single bullet point:
- The text of the statement issued is compared to existing statements in the shared pool.
The text of the statement is hashed. If there is no matching hash value, then the SQL statement does not currently exist in the shared pool, and a hard parse is performed.
If there is a matching hash value for an existing SQL statement in the shared pool, then Oracle compares the text of the matched statement to the text of the statement hashed to see if they are identical.
So the first line is like a summary of the whole bullet point, which is then expanded.
In the 9iR2 manual, this was reverted back to individual bullet points, but the author/editor must have assumed the initial summary line was a separate point, so a new step was introduced into the documentation of the process:
- The text of the statement issued is compared to existing statements in the shared pool.
- The text of the statement is hashed. If there is no matching hash value, then the SQL statement does not currently exist in the shared pool, and a hard parse is performed.
- If there is a matching hash value for an existing SQL statement in the shared pool, then Oracle compares the text of the matched statement to the text of the statement hashed to see if they are identical.
And this is the way it stayed from 9iR2 to 11gR1. 🙁
I’ve raised a bug against the documentation, so it should get corrected now. 🙂
Cheers
Tim…
I’ve been wondering about links into the modern docs. They always seem to briefly show the intended page (like your sharing criteria link), then it gets replaced by some whole bunch of stuff and I have to search for what I was just in the middle of reading. Is it supposed to work like that? Or have I stupidly missed some browser setting?
I think it may just be a result of the page loading, which is messing up your view. If you wait for the page load to complete, then go back into the URL bar and hit return, does it take you back to the correct point in the document again?
Cheers
Tim…
The results don’t seem entirely consistent. At tahiti, if I hit the back and forward arrows, it winds up at the right place the second time. Here, it does that too, and sometimes works ok, and works ok if I open in a new window. But since it is inconsistent, I don’t know if that is an accurate description. I think tahiti never works right the first time for me unless the link doesn’t have a # identifier near the end. At least using IE6 through a proxy.
(and through some other configs I sometimes use).
It sounds very much like the page loading issue to me. The page hasn’t completed loading when it tries to jump to the correct bit of the document. It does this correctly, but them as pictures or more text load the page shunts down the screen and you are no longer looking at the correct text. Going to the URL bar and hitting return reloads the page, which is already cached, so you don’t get the problem the second time round.
I find this issue is more to do with the size of the page than the contents.
Cheers
Tim…