The following is not a question and I am not requesting a response but rather posting this for informational purposes as was requested by the docs team.
A few weeks back as the result of a thread I can not currently locate, questions were raised with respect to Oracle's documentation about LOBs and I stated that I would pursue it getting the docs fixed.
I now have the response and, with names removed, am posting the thread for anyone interested in the topic.
From: Janis ...@oracle.com <janis....@oracle.com>
Date: Tue, Jan 24, 2012 at 12:40 PM
Subject: Re: Oracle Docs Issue *** ADLOB forum issue: tablespace separate from table containing LOB
To: damorgan11g @ gmail.com
Cc: Eric ... <eric....@oracle.com>
Dan,
You have two somewhat related issues here and I have divided them up.
See inline notes
Best,
Janis
On 11/27/2011 10:54 PM, Daniel Morgan wrote:
Thanks Eric ... Hi Janis
Thank you for taking a look at this. The way modern SANs are configured, and so many of us using ASM it is my expectation that those "different" tablespaces
could be on the same disk whereas the two segments in the same tablespace might be miles of stripe away from each other. In short I can not conceive of
how it could matter.
I look forward to learning what you find out during your investigations.
Also, as you are rewriting the book, it would be great if you could bring together, in one place, the regular functions that now support LOBS
(for example LENGTH), the DBMS_LOB functionality, and far clearer explanations of CHUNK and NOCACHE and other bits of related functionality.
We don't so much need definitions as we need clarity as to when and how to use them.
Here's one example:
http://docs.oracle.com/cd/E11882_01/appdev.112/e10777/ch_dba.htm#IMURG11685
what, one might wonder, is the default if CHUNK is not specified?
Thank you.
--
Daniel A. Morgan
Oracle ACE Director
The Multimedia book will add a note to see the Packages guide, chapter on DBMS_LOB for specifics of various methods etc.
http://st-doc.us.oracle.com/11/112/appdev.112/e25788/d_lob.htm#autoId0
As far as CHUNK goes, it is a basic parameter defined (with default) in the SQL Reference Guide (SQLRF). In the context of the discussion,
it relates to create table.
The definition is found here:
http://st-doc.us.oracle.com/11/112/server.112/e26088/statements_7002.htm?term=Chunk#SQLRF54527
CHUNK integer Specify the number of bytes to be allocated for LOB manipulation. If integer is not a multiple of the database block size, then the
database rounds up in bytes to the next multiple. For example, if the database block size is 2048 and integer is 2050, then the database allocates
4096 bytes (2 blocks). The maximum value is 32768 (32K), which is the largest Oracle Database block size allowed. The default CHUNK size is one
Oracle Database block. The value of CHUNK must be less than or equal to the value of NEXT, either the default value or that specified in the
storage_clause. If CHUNK exceeds the value of NEXT, then the database returns an error. You cannot change the value of CHUNK once it is set.
As far as your suggestion for consolidation, yes, in some areas of the ADLOB book, this is true and I am working on it.
Continue below
On Sun, Nov 27, 2011 at 9:39 PM, Eric ... <eric....@oracle.com> wrote:
Hi Daniel,
Thanks for the detailed feedback.
Your timing is perfect. I've just assigned the LOBs book to Janis.
Janis: Can you please investigate and respond when you've got it sorted out.
Thanks,
-Eric
On 11/27/2011 8:34 PM, Daniel Morgan wrote:
The links in question are:
http://docs.oracle.com/cd/B28359_01/appdev.111/b28393/adlob_tables.htm
http://docs.oracle.com/cd/B19306_01/appdev.102/b14249/adlob_tables.htm#i1006434
What is of specific concern is this statement on both pages.
Best performance for LOBs can be achieved by specifying storage for LOBs in a tablespace different from the one used for the table that contains the LOB.
I personally don't believe it and my limited testing over the weekend seems to confirm my suspicion. The comment has the distinct feeling of having been
written by the same misguided sole that thought best performance could be had by putting tables and indexes into separate tablespaces. Today we all
know that was pure mythology but for a decade everyone quoted the Oracle 7.x docs as supporting the idea.
In a world of virtualized storage, striping, and multi-user systems the statement does not ring true. Please have the author either remove it or justify it then
post a clarification to this thread.10005220
Daniel, I have the following response from the development team, please convey this to the forum for us:
Choice of tablespaces for different objects is a complex issue that is not amenable to summarization. Every rule/statement on the topic (including the one
in the docs) has scenarios where it is justified, and scenarios
where it is not.
If the concern is about the seeming categorical nature of the current statement, just remove it [removed: doc team]. There is no way to make that
statement less categorical and simultaneously useful and actionable.
Per the developer's request, I am removing the paragraph from the SecureFiles and Large Objects Guide.
Best,
Janis