Re: Oracle8 ROWIDs - data file numbers

Thomas,
Thanks again. Picking up again where we left off and incorporating what you said about Oracle7 to Oracle8 migrations, my personal explanation for the new extended ROWID format follows. At the end of it is my question to you.

In Oracle8, the developers, at Oracle Corp., decided to increase the maximum number of datafiles per database from the old Oracle7 limit of 1022 to 65533 (two values are reserved for some unspecified special purpose, hence 2^10 - 2 = 1022 and 2^16 - 2 = 65533). This had a knock-on effect on the ROWID. In Oracle7, the ROWID was 6 bytes in length with 10 bits reserved for the datafile number. The limit 65533 requires a minimum of 16 bits. So the obvious solution of increasing the size of ROWID by giving it an extra 6 bits, (which would translate to 7 bytes when rounded-up), would have a couple of draw-backs. The size of all index entries would increase and hence all index segments would get bigger requiring more storage and reducing speed of access. This would be particularly apparent when upgrading an Oracle7 database to Oracle8. During conversion all the index segments would require the individual ROWIDs to be expanded in size. This would result, in many cases, in having to allocate more disk space to the datafiles. It is preferable not to alter the size of database files during an upgraded for fairly obvious reasons. Therefore increasing the size of the ROWID during an upgrade is not an option.

Hence in Oracle8 the notion of a restricted ROWID was introduced. This has the same format as an Oracle7 ROWID. Since it cannot specify the absolute data file number, it specifies the "relative to the tablespace" data file number. (Which is certainly a reason, if not the reason, why there is the limit of 1022 on the number of datafiles to a tablespace). This works for all index segments of non-partitioned tables, since all table rows must be in the same tablespace. It also works for indexes of patitioned tables where the index is locally partitioned. It does not work for global indexes of partitioned-tables. In these cases an extended ROWID is required since a partitioned table can span multiple tablespaces.

In the new Oracle8 extended ROWID format the ROWID has been expanded to 10 bytes. The file component has been expanded to somewhere between 13 and 18 bits in length (FFF in base64 allows for 18 bits).

Assuming 16 bits are used then this new ROWID format can handle absolute file numbers.

So do extended ROWIDs in Oracle8 contain the absolute data file number and restricted ROWIDs contain relative data file numbers?

Thanks, Ben

In article <89ltua$ifi$1_at_nnrp1.deja.com>,   Thomas J. Kyte <tkyte_at_us.oracle.com> wrote:
> 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
> >
>
> --
> 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. Received on Sun Mar 05 2000 - 00:00:00 CST