Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Oracle internals.

Re: Oracle internals.

From: Jim Kennedy <kennedy-family_at_attbi.com>
Date: Sun, 09 Dec 2001 20:27:38 GMT
Message-ID: <_OPQ7.20640$wL4.36406@rwcrnsc51>


Howard is correct. You are asking more of a meta question with regards to the System tablespace. The system tablespace is a little special. One might ask how on Earth does Oracle know what files comprise the database? This information starts in the init.ora file.(version 8i and prior) In that file is an entry that says control_files=(...) This points to the files that hold the information about what files Oracle knows about and their state (e.g. SCN numbers ect..). Lose the control file and you have a bear of a time getting the whole thing running which is why one should have multiple copies of the control file on multiple disk devices and keep a backup. Anyway, I think the system tablespace is special and if you go hunting through the sql.bsq file you can see how it is set up and a features that are not documented and things you should not muck with. The sql.bsq file is executed when you create the database. It knows how to initially build the system catalogs so the whole thing can work. Which is probably why you can't have a locally managed tablespace for the system tablespace (at least not in 8i). Oracle puts some things in the system tablespace in some specific areas so it can bootstrap itself. I consider it an academic curiosity as to exactly how it works; interesting but I wouldn't muck around with it (e.g. try to read or change it directly).

Think of a header of the file in the system tablespace as being static pointers large enough to initialize the system. e.g. starting at block 5 to block 45 is the first block for the UET$ table etc. The system would just need a little bit of static information in known areas (probably the first x blocks in the system tablespace) to set the whole thing up for a more dynamic table driven system.

Again Howard is correct. Specifically, a database block belongs to one database object and it does not have multiple database objects. Jim

"Andrej" <andrej611_at_wp.pl> wrote in message news:9v0g9g$ji8$1_at_korweta.task.gda.pl...
> > > I am looking for the following info concering Oracle internals:
> > > - how does Oracle know what blocks are assigned to what tables ? does
is
> > > blindly scan throug all the blocks ?
> >
> > No, it holds that information in data dictionary tables. Specifically,
> UET$
> > records what extents exist, and who owns them. Tables such as OBJ$ and
> TAB$
> > also come into play. In locally managed tablespace, a bitmap at the
> header
> > of the tablespace indicates whether a block is reserved for use or not.
> > Data dictionary entries still say which object owns which block.
>
> But data dictionary is also a bunch of TABLE(s). So your asnwer produces
an
> infinite loop ... it knows where the table blocks are by querying a table.
>
> I am trying to find out how Oracle recognizes what tables ARE in a SYSTEM
> tablespace datafiles and how are blocks internaly linked with them - for
> example what blocks make UET$.
>
> > >So where is a
> > > glue that holds a blocks/extents of a segment toegether ?
> >
> > There is no such substance.
>
> There must be. Otherwise Oracle wouldn't work at all. A single block holds
a
> data about rowids in the header. But how is data distionary build so that
> Oracle knows where to look for rows making a single schema object ?
>
>
>
>
>
Received on Sun Dec 09 2001 - 14:27:38 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US