Re: Detailed oracle concepts...!!! ANy DBA can help

In our last gripping episode "Damian" <kndoneill_at_hotmail.com> wrote:
> For curiosity's sake, I'd like to see the source code (fat chance I
 know).
> Therefore, as an exercise in reverse engineering, how would one go
 about
> updating a dbf file?
>
> SELECT Scenario
> Selects, updates and deletes would first require a file seek
 function. I
> quess you'd have to do a string search first to find the rowid.
>

A wise move if the ROWID were actually stored in the datafile, which it is not. Every ROWID is a pseudo-column of derived data. As such you won't find it stored in any .dbf file.

> UPDATE Scenario
> Well I guess you'd open the dbf with file read, write flags set.
> Then you'd search thru the file sequentially, probably moving your
 file
> pointer every <block size> until you found your table from the table
 dir
> then row from row dir. Then delete <ROWID> from block, (then maybe)
 move all
> data in block after the deletion up to where the rowid before the
 deleted
> one ends. finally, write your updated row at the end of the last row
 in the
> block.
>

Again, using the ROWID is useless as it is a derived value.

> INSERT Scenario
> Say a new row is to be inserted into the table.Is it going to be
 inserted at
> the END of block (which?) assigned for the Table. What will happen
 if the
> Block is consumed and a new block is going to be created. Where the
 new
> block is going to be created and how it will effect the performance
 when the
> blocks are split across separated by different blocks.
>
> DELETE Scenario:
> Same as update without the write function at the end.
>
>

These are all perfectly good C/C++ methods for updating a flat file, or even a binary file, however they won't work as listed to update an ORACLE .dbf file since the reference structure you cite (ROWID) does not exist (as I stated earlier) in the file. There are other mechanisms (proprietary, no doubt) that ORACLE uses to insert, update, delete and select data, many based upon the ROWID but not because that value is found in the datafile itself. The database generates ROWID values from data block addresses, relative file numbers (in 8 and 8i) or absolute file numbers (in 7 and earlier) and hexadecimal row addresses then uses those derived values to reference and access data in the database. You're correct in presuming that the source code is "out of reach" -- proprietary systems and methodologies are not publicly available for scrutiny.

I don't believe that you will find the "mechanical" answer you seek, unless, of course, you can find a rather stupendous "de-assembler" to reconstruct, at least, the assembly language coding for the Oracle executable. Even then you're not likely to discern the nature of the C/C++ code as the executable is most likely "stripped" of any and all symbol table information.

--
David Fitzjarrell
Oracle Certified DBA


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