Re: IOTs, db_links from 8.0.4 to 7.3.3.5

Oracle8 introduced a new format for ROWIDs. This change is primarily driven by the introduction of partitioned objects and tablespace-relative data block addresses (DBAs).

Currently the ROWID is has the format 'BBBBBBBB.RRRR.FFFF' where BBBBBBBB is the block number, RRRR is the slot(row) number, and FFFF is a file number. For the sake of this document, this format will be called the restricted format. The new Oracle8 ROWID, will be 10 bytes long (compared to existing rowid of 6 bytes) and will contain the data object number, the DBA (data block
address) and the row number of the row (this format will be referred to as the extended format). Oracle will provide functions that return the file number, block number, etc.

NOTE: The 6 bytes vs 10 bytes required is only relevant to the ROWIDs stored
in a user column defined of ROWID type, which carries the binary representation
of rowid. It does not apply to host variables.

Compatibility Issues:

It will be possible for a pre-V8 client to access a V8 database and visa versa. Binary and character values of the pseudo column ROWID and of columns
of type ROWID that are returned by a pre-V8 database to a V8 database are always restricted because the pre-V8 system will not know about the extended rowid.

Most of the ROWID functionality works for accessing a pre-V8 server. A supplied package (DBMS_ROWID) can be used for interpreting ROWID contents. If an Oracle8 database is being accessed from a pre-V8 client, the server will return the ROWID in the extended format. Therefore, you will not be able to interpret the rowid contents or store ROWIDs in a user column of ROWID type without using the DBMS_ROWID package.

V7.0 snapshots store master rowids as type ROWID at the snapshot site. This means a V7.0 snapshot would not be able to have a V8.0 master. Therefore,
Oracle8 snapshot compatibility is restricted to 7.1.3 and higher. Furthermore,
when a master site is upgraded, the upgrade script will have to invalidate the logs so that snapshots are forced to do a complete refresh next time.

Migration Issues:

There are two migration issues related to the new ROWID format: application migration and data migration.

Applications which do not attempt to manually assemble or disassemble ROWIDs will not have to be changed or recompiled because the new ROWIDs will fit the
current storage requirements for host variables. Applications which attempt to manufacture ROWIDS, will have to use the new package DBMS_ROWID.

Data migration will have to be done for any columns which contain ROWID values
(either in ROWID or in character format) if these tables are to be migrated to
V8. Otherwise, it will not be possible to retrieve any rows using their stored values. However, if these ROWID values point to a pre-V8 table, migration is not needed, since the value points to an existing pre-v8 table that uses the restricted rowid. Column definitions will automatically adjust
during V7 to V8 dictionary migration.

A special utility will be provided to assist in migrating the data. The utility will read the (restricted) ROWID values and convert them to the extended format after verifying that the ROWID is actually valid for some table in the table list (provided by the user). The verification will be done
by checking the ROWID versus the extent maps of the tables in the table list without actually reading the row. This means that there may be no actual row
with this ROWID, but the ROWID is valid.

Jonathan Lewis <jonathan_at_jlcomp.demon.co.uk> wrote in message news:930591024.283.0.nnrp-02.9e984b29_at_news.demon.co.uk...
>
> Has anyone come across this -
>
> I can't contact Oracle support on it, because
> they've managed to expire my SAC (without
> stopping the bills coming, mind you), and I
> haven't found it on MetaLink 1.7
>
>
> HP-UX 10.20
> Oracle 8.0.4
> Database link to Oracle 7.3.3.5
>
> create an IOT table (
> list of columns and pk constraint
> )
> as
> select
> list of columns from table_at_D7335
> ;
>
> The process crashes, and about 30 seconds later
> the Oracle 8 instance crashes.
>
>
>
> Attempted work-around - create a local view of
> the remote table.
>
> create view ABC as select list of columns from table_at_D7335.
>
> Then try to create the table by selecting from the
> local view. Oracle 8 stays up, the process stays
> up, but reports
> ORA-02068 (severe error from remote database)
> ORA-00600 with parameter [],[],[],[],[],[],[],[]
>
> On the other hand, the 7.3.3.5 database is showing a trace
> file that says it parsed, executed and fetched - and got all
> the required rows - and then closed correctly !!
>
> --
>
> Jonathan Lewis
> Yet another Oracle-related web site: www.jlcomp.demon.co.uk
>
>
>
Received on Mon Jun 28 1999 - 22:35:37 CDT