Re: Oracle8 ROWIDs - data file numbers

In article <89k0ou$81r$1_at_nnrp1.deja.com>,   Ben Ryan <benryan_at_my-deja.com> wrote:
> In article <89j8i0$l0t$1_at_nnrp1.deja.com>,
> Thomas J. Kyte <tkyte_at_us.oracle.com> wrote:

[snip]

> Thanks for the response,
> I looked in the Oracle8.0 Server reference - Chapter 5: Database
> Limits - Table 5-2 Physical database limits - And it claims that
> the maximum number of database files per database is 65533 (i.e.
> less than 2 bytes). I also checked for 8.1.5 where it is also
> 65533.
>
> Now, I am guessing, that you are looking at one of the base tables
> of the system dictionary and hence you can see it is stored in a 4
> byte structure.
>
> So is this relative-to-tablespace data file number, something that
> is not used currently, but will be used? Or am I being slow on the
> uptake?
>

let me clarify (i really didn't give the whole story before). It is becase in a DBA (data block address) and in the rowid stored in an index ( a 6 byte field with the FILE/BLOCK/SLOT to find a row) we store the FILE# with 10 bits. We allowed for upto 2^10-2 (1022) files in Oracle7. In Oracle8, we allow for 1022 files per tablespace and a maximum of 64k files in a database. We still need to store the file# in the rowids and such in 10bits though (to avoid having to rewrite the entire database upon an upgrade). In order to do that -- the file#'s are now considered 'relative' to a tablespace and are still 10bits. the absolute file# is a 'regular' size and not limited to 10bits.

We keep the relative = absolute until we cannot anymore. If you migrate a v7 database -- relative = absolute since we know there is less then 1023 files. When you exceed this old limit, you'll start seeing relative <> abosolute.

Hope this clears it up. sorry for the confusion.

> Thanks, Ben
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>

--
Thomas Kyte                              tkyte_at_us.oracle.com
Oracle Service Industries
http://osi.oracle.com/~tkyte/index.html
--
Opinions are mine and do not necessarily reflect those of Oracle Corp


Sent via Deja.com http://www.deja.com/
Before you buy.