Re: Block Identifiers in Multitenant Databases

From: Jonathan Lewis <jlewisoracle_at_gmail.com>
Date: Wed, 6 Oct 2021 18:15:37 +0100
Message-ID: <CAGtsp8=ufNMdZ==xfmNMXNd3ubxhVaC=OgQLT=Hc13cqzxk+cg_at_mail.gmail.com>



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_at_gmail.com> 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_at_gmail.com>
> 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_at_gmail.com>
>> 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_at_gmail.com>
>>> 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
>>>>
>>>

--
http://www.freelists.org/webpage/oracle-l
Received on Wed Oct 06 2021 - 19:15:37 CEST

Original text of this message