Subject | Re: [IB-Architect] Internal Database Image |
---|---|
Author | Ann W. Harrison |
Post date | 2001-10-29T19:59:07Z |
At 07:58 PM 10/29/2001 +0300, Alexey wrote:
The trick is that the system doesn't actually use the system tables to
build its internal image of the system tables. The system tables are
described in the code (relations.h & fields.h). During the design of
the database, there was an argument put forward for building in only the
"core" attributes (relation name, relation id, field name, domain name,
field id, domain data type, plus RDB$PAGES and RDB$FORMATS) and perhaps
some index info) and building all the froofrah from them. The argument
was not put forward with enough skill, so all of the system tables are
built-in.
When a database is created, subsystems (locking, cache management,
etc.) are initialized. The in-memory version of the system tables
is initialized (INI_init & INI_init2) Then the header page is
formatted - PAG_format_header(); The first WAL page is formatted
- (PAG_format_log(); And the first page information page (space
management page) is formatted - PAG_format_pip();
Finally INI_format stores the system table records that describe
the system tables using the normal system calls. There is some
special code in DPM_create_relation that recognizes the creation
of RDB$PAGES and stores the location of its first pointer page on
the database header page.
When InterBase opens a database, it begins by populating the in
memory version of the system tables, then reads the pointer
page of the RDB$PAGES relation and builds everything else from
there.
Regards,
Ann
www.ibphoenix.com
We have answers.
> I have read the article "The Interbase On-Disk structure" by Ann W.HarrisonRight...
> http://community.borland.com/article/0,1410,27151,00.html,.
> But I have some "theoretical" questions about building of "internal
>database image".
>
> Here is the sequence as I can imagine this:
>
> 1) Read the header page, find the number of 1st pointer page and go there.
> 2) While reading the 1st poiter page, build the RDB$Pages.
> 3) After that, read from RDB$Pages -> proceed with RDB$Relations and so
> on - i.e. building the system tables.
> I think that some "trick" here. The RDB$Pages creates the first, but if IAlso right.
> SELECT RDB$RELATION_NAME FROM RBD$RELATION, I can see it! And I can see
> RDB$Relations itself!
The trick is that the system doesn't actually use the system tables to
build its internal image of the system tables. The system tables are
described in the code (relations.h & fields.h). During the design of
the database, there was an argument put forward for building in only the
"core" attributes (relation name, relation id, field name, domain name,
field id, domain data type, plus RDB$PAGES and RDB$FORMATS) and perhaps
some index info) and building all the froofrah from them. The argument
was not put forward with enough skill, so all of the system tables are
built-in.
When a database is created, subsystems (locking, cache management,
etc.) are initialized. The in-memory version of the system tables
is initialized (INI_init & INI_init2) Then the header page is
formatted - PAG_format_header(); The first WAL page is formatted
- (PAG_format_log(); And the first page information page (space
management page) is formatted - PAG_format_pip();
Finally INI_format stores the system table records that describe
the system tables using the normal system calls. There is some
special code in DPM_create_relation that recognizes the creation
of RDB$PAGES and stores the location of its first pointer page on
the database header page.
When InterBase opens a database, it begins by populating the in
memory version of the system tables, then reads the pointer
page of the RDB$PAGES relation and builds everything else from
there.
Regards,
Ann
www.ibphoenix.com
We have answers.