Question about Full Table Scans and Tablespaces

Question

Good evening (or morning),
I'm reading the Oracle Concepts (I'm new to Oracle) and it seems that, based on the way that Oracle allocates and manages storage the following premise would be true:
Premise: A table that is often accessed using a full table scan (for whatever reasons) would best reside in its own dedicated tablespace.
The main reason I came to this conclusion is that when doing a full table scan, Oracle does multiblock I/O, likely reading one extent at a time. If the Tablespace's datafile(s) only contain data for a single table then a serial read will not have to skip over segments that contain data for other tables (as would be the case if the tablespace is shared with other tables). The performance improvement is probably small but, it would seem that there is one nonetheless.
I'd like to have the thoughts of experienced DBAs regarding the above premise.
Thank you for your contribution,
John.

Answer 1

Good morning :) Aman,
>
A little correction! A segment(be it a table,index, cluster, temporary) , would stay always in its own tablespace. Segments can't span tablespaces!
>
Fortunately, I understood that from the beginning :)
You mentioned fragmentation, I understand that too. As rows get deleted small holes start existing in the segment and those holes are not easily reusable because of their limited size.
What I am referring to is different though.
Let's consider a tablespace that is the home of 2 or more tables, the tablespace in turn is represented by one or more OS datafiles, in that case the situation will be as shown in the following diagram (not a very good diagram but... best I can do here ;) ):
Tablespace TablespaceWithManyTables
  (segment 1 contents)
    TableA Extent 1
      TableA Block 1
      TableA Block 2
      Fragmentation may happen in these blocks or
      even across blocks because Oracle allows rows
      to span blocks
      TableA Block n
    End of TableA Extent 1
    more extents here all for TableA
  (end of segment 1 contents)
  (segment 2 contents)
    TableZ Extent 5
      blocks here
    End of TableZ Extent 5
    more extents here, all for tableZ
  (end of segment 2 contents)
    and so on
  (more segments belonging to various tables)
end of Tablespace TablespaceWithManyTablesOn the other hand, if the tablespace hosts only one table, the layout will be:
Tablespace TablespaceExclusiveForTableA
  (segment 1 contents)
    TableA Extent 1
      TableA Block 1
      TableA Block 2
      Fragmentation may happen in these blocks or
      even across blocks because Oracle allows rows
      to span blocks
      TableA Block n
    End of TableA Extent 1
    another extent for TableA
  (end of segment 1 contents)
  (segment 2 contents)
    TableA Extent 5
      blocks here
    End of TableA Extent 5
    more extents for TableA
  (end of segment 2 contents)
  and so on
  (more segments belonging to TableA)
end of Tablespace TablespaceExclusiveForTableAThe fragmentation you mentioned takes place in both cases. In the first case, regardless of fragmentation, some segments don't belong to the table that is being serially scanned, therefore they have to be skipped over at the OS level. In the second case, since all the extents belong to the same table, they can be read serially at the OS level. I realize that in that case the segments may not be read in the "right" sequence but they don't have to because they can be served to the client app in sequence.
It is because of this that, I thought that if a particular table is mostly read serially, there might be a performance benefit (and also less work for Oracle) to dedicate a tablespace to it.
I can't wait to see what you think of this :)
John.