Thinking about it a bit, the individual blocks are unlikely to hold any
information about their tablespace or absolute file number, otherwise
a) for tablespace number - every block would have to be updated to avoid a
collision when you did a 'transport tablespace'
b) for absolute file number - every block would have to be updated when you
unplugged a PDB and plugged it in somewhere else.
Regards
Jonathan Lewis
On Wed, 6 Oct 2021 at 16:55, Seth Miller <sethmiller.sm@xxxxxxxxx> wrote:
Yes, I noticed this as well and it is pretty easy to identify the file as
a whole. Unfortunately, I am dealing with individual blocks. Specifically,
I need to identify each block that comes through an rman stream which means
I can have blocks from multiple datafiles in a single stream.
Seth
On Wed, Oct 6, 2021 at 10:37 AM Jonathan Lewis <jlewisoracle@xxxxxxxxx>
wrote:
Sorry,
I didn't intend my previous reply to go to the individual rather than the
group.
I've just done
od -o {filename} | head -64 on the system tablespace file for the root,
seed and pdb of a multi tenant database.
Then I've flagged each line of the file (changed the first space in each
line to a letter surrounded by spaces).
The sorted the three files together.
In v$datafile root system is file 1, seed system is file 5, and the pdb
system is file 11.
The following may be a coincidence (the first 6 digit number is the byte
number in the file, in Octal:
0020060 p 020000 000000 000011 000003 000000 000000 000000 000000
prod system = file# 9
0020060 r 020000 000000 000001 000003 000000 000000 000000 000000
root system = file# 1
0020060 s 020000 000000 000005 000003 000000 000000 000000 000000
Seed system = file# 5
Note the value of byte 002065
Regards
Jonathan Lewis
On Wed, 6 Oct 2021 at 10:03, Jonathan Lewis <jlewisoracle@xxxxxxxxx>
wrote:
Where are you starting from that gives you the RDBA ?
I don't think that there's anything in the block that identifies the
CON_ID/pdb id, but when Oracle is handling the block it has the relative
file number, tablespace number and absolute file number of the block in the
block handle structure (x$bh), and two of those three would have been
derived (or deduced) information. WIth the absolute file number you just
need to check v$datafile to identify the container. Bottom line - if you
can infer the tablespace number you're done.
Brute force method: check v$datafile for every absolute file# that
matches your relative file number (which isn't goint to eliminate many pdbs
if you're using bigfile tablespaces across the board), then dump the
matching block number from each file. (That's if you really want to find
out for the occasional special case, but probably too much of a nuisance in
general).
Regards
Jonathan Lewis
On Tue, 5 Oct 2021 at 20:29, Seth Miller <sethmiller.sm@xxxxxxxxx>
wrote:
I am attempting to isolate the identification attributes of an
individual block. Prior to multitenant, this was easy to do using the RDBA
to get the file and block. However, in a PDB, the RDBA does not tell me how
the root container identifies the block either by the file number at the
root level or by the container ID.
I've done a lot of digging and debugging and can't figure out how the
root container identifies a block or where it might be in the block header.
Any help would be appreciated.
Seth
