As an alternative to DBMS_ROWID, one could just
decode the ROWID from the query based on what is
known as the Extended Rowid Format Oracle uses.
The base-64 decomposition of 'AAAMfMAAEAAAAAgAAH'
works out to be the following.:
|
Data Object ID
|
Relative File No
|
Block Number
|
Row Slot(Number)
|
|
AAAMfM
|
AAE
|
AAAAAg
|
AAH
|
|
51148
|
4
|
32
|
7
|
Oracle uses a conversion table of A-Z being 0-25
in decimal form, and a-z being 26-51. Once one
has the decimal value, one can derive the binary
value and then string the binary strings
together to get the final value. For example,
the M and f components under the data object ID
are decimal values 12 and 31 whose binary values
are 001100 and 011111. AAAMfM is then
represented as:
000000 000000 000000 001100 011111 001100
The decimal value of this is then computed to be
51148 and matches what was shown earlier. Of
course, the DBA could also just query
DBA_OBJECTS to get the DATA_OBJECT_ID value of
the table.
Two other preliminary items need to be mentioned
at this point. The first concerns setting up a
UNIX environment. If one has the resources at
work, where resources implies a totally
throw-away database on a totally throw-away
ORACLE_HOME installation on a server that can be
down in case one has to reinstall Oracle, there
is already one made. All the DBA needs to do is
make the executable if not already done.
If the DBA does not have a UNIX server, how does
he get access to one, i.e. the DBA is doing this
on a home computer? One option is to buy a bare
bones PC and install Oracle Enterprise Linux on
it. Another is to install OEL on the current PC
and live with booting from multiple operating
systems. The boot from multiple systems on the
main home PC is not the best choice, but one can
make that happen with relatively little effort.
If one does not like having OEL or some other
brand of Linux on the PC, it can be removed
later and the disk space it partitioned can be
reclaimed.
The second is using a parameter file when
starting bbed. Nothing new about what a
parameter file is and does as it is just like
parameter files used elsewhere in Oracle (exp,
imp, sqlldr, etc.). What is new, however, are
the parameters and their values or options.
Enter
bbed help=y to see the list. In
this example, bbed is located in
$ORACLE_HOME/bin after having been compiled
elsewhere.
[oracle@oralinux ~]$ bbed
help=y
PASSWORD - Required
parameter
FILENAME - Database file
name
BLOCKSIZE - Database block
size
LISTFILE - List file name
MODE - [browse/edit]
SPOOL - Spool to logfile
[no/yes]
CMDFILE - BBED command
file name
LOGFILE - BBED log file
name
PARFILE - Parameter file
name
BIFILE - BBED before-image
file name
REVERT - Rollback changes
from BIFILE [no/yes]
SILENT - Hide banner
[no/yes]
HELP - Show all valid
parameters [no/yes]
Collect the file name information as shown
earlier. Identify the block size of the file(s),
and for the initial runs of using this tool, use
the browse mode. The contents of a parameter
file are shown below.
[oracle@oralinux bbed]$
more bbed.par
blocksize=8192
listfile=/home/oracle/bbed/orcl2files.txt
mode=browse